| 01:03.49 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 01:56.34 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 02:19.12 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:19.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:43.20 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 04:37.59 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:55.59 | *** join/#asterisk-dev gokulnath (~gokulnath@115.111.177.122) |
| 06:08.08 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:19.01 | *** join/#asterisk-dev ccesario (~ccesario@187.17.166.162) |
| 07:01.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.76.71.96) |
| 07:18.25 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:02.03 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 09:57.39 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 09:57.45 | schmidts | good morning |
| 10:11.06 | wdoekes2 | morning. did you get your merge issues sorted out? (e.g. through svn revert and redoing the merge?) |
| 10:12.33 | schmidts | wdoekes2 rm -rf && svn co solves it ;) |
| 10:13.27 | wdoekes2 | ok :) |
| 10:13.32 | wdoekes2 | that's always safe |
| 10:13.40 | schmidts | and mostly faster ;) |
| 10:16.41 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:16.41 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:23.50 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 10:42.28 | schmidts | does anyone know the difference between prohib, prohib_not_screened, phohib_passed_screen depeding to sip? i know what it causes on isdn but imho there is not really a difference for sip, right? |
| 10:51.37 | wdoekes2 | well.. semantics are probably the same, and RPID has the screen=bool distinction |
| 10:51.54 | wdoekes2 | what does it do on ISDN? |
| 11:24.27 | schmidts | wdoekes2 sorry didnt say it exactly for the RPID and PAI header it sets the screen and privacy values but i meant for the from header |
| 11:25.11 | schmidts | on isdn the number will still be sent but this presence flag is also set, so on isdn you will still see the normal number if you look into the packet itself but its just flaged as hidden |
| 11:40.34 | *** join/#asterisk-dev tamiel (~tamiel@85-171-171-179.rev.numericable.fr) |
| 11:46.13 | wdoekes2 | schmidts: you mean that passed_screen will pass the number on and not_screened doesn't? |
| 11:46.53 | schmidts | no the number is allways passed to the pstn side, but it depends on your isdn connection if this number will be used or not |
| 11:48.26 | schmidts | for example if your carrier on the pstn side allows you to set your own user provided number you can set this to allowed_passed_screen which means its not a network provided number but you ensure that its a proper one |
| 11:48.58 | schmidts | if you set it to not_screened it depends on your carrier if they use this number or not and its nearly the same with failed_screen |
| 11:49.06 | *** join/#asterisk-dev merbanan (~benjamin@c-83-233-242-104.cust.bredband2.com) |
| 11:50.09 | schmidts | for example in austria and germany there is a common feature called "clip no screening" which normally means there are two callerid values in the isdn header, one is a network provided number and the other one is a user provided number with _not_screened set. normally you will see this user provided number on your cell phone or isdn line but not on pots lines |
| 11:50.19 | schmidts | and there are also some legal things about this |
| 12:08.31 | mvanbaak | http://blog.whiletrue.com/2012/01/visual-studio-achievements-now-a-reality/ |
| 12:08.34 | mvanbaak | ;-) |
| 12:11.20 | schmidts | ;) |
| 12:33.40 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:33.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:12.04 | *** join/#asterisk-dev ccesario (~ccesario@187.17.166.162) |
| 13:12.51 | *** join/#asterisk-dev anny__ (~chatzilla@77.42.241.114) |
| 13:13.05 | anny__ | is idefix source code still available somewhere in the archives? |
| 13:14.43 | kpfleming | umm... what? |
| 13:29.43 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:29.43 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:34.15 | schmidts | kpleming maybe this was only a joke ;) there is a france cartoon figure named asterix which has a dog called idefix |
| 13:34.49 | kpfleming | schmidts: ahh... yeah |
| 13:36.02 | russellb | lame joke |
| 13:36.37 | schmidts | it would be better if he had asked for idefisk ;) |
| 13:45.22 | kpfleming | or IDEF1X, which is a real thing |
| 13:45.42 | leifmadsen | is that your ham radio operator id |
| 13:45.48 | kpfleming | you wish |
| 13:46.06 | leifmadsen | I'm not sure why I do, but sure@! |
| 13:46.25 | leifmadsen | woah... fingers are not yet warmed up... |
| 13:46.30 | leifmadsen | (that's what she said) |
| 13:48.06 | kpfleming | leifmadsen: go back to bed, you clearly need more sleep |
| 13:48.25 | leifmadsen | kpfleming: or moar cawphayz! |
| 13:48.38 | leifmadsen | I actually slept in today... all the way till 7:30am! |
| 14:05.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yulqlapnqxswahot) |
| 14:18.53 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yughepvzswxheddq) |
| 14:18.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:35.02 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-tanaazpcmbjmockx) |
| 14:59.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:59.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:12.44 | *** join/#asterisk-dev bklang (~bklang@c-66-56-12-125.hsd1.ga.comcast.net) |
| 15:25.34 | *** join/#asterisk-dev thatjoshguy (4276453a@gateway/web/freenode/ip.66.118.69.58) |
| 15:25.49 | thatjoshguy | quick quetion about realtime in 1.8 if anyone is about? |
| 15:26.42 | thatjoshguy | was wondering if 'overrideswitch' was ever made a feature, or if there is a way to use dynamic contexts without switch statements for each in extensions.conf |
| 15:28.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:28.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:29.24 | thatjoshguy | anyone use realtime contexts in 1.8? |
| 15:38.00 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:41.21 | *** join/#asterisk-dev Corydon76-home (black@c-69-137-80-31.hsd1.tn.comcast.net) |
| 15:41.32 | *** join/#asterisk-dev Corydon76-home (black@c-69-137-80-31.hsd1.tn.comcast.net) |
| 15:41.32 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 15:47.08 | schmidts | could someone take a short look at https://reviewboard.asterisk.org/r/1677/ just about the parsing part for privacy and screen, its working but its very ugly :( |
| 15:55.20 | pabelanger | Still think for each new parser we add / change / update we also include a unit test. |
| 15:56.04 | Qwell | It's not new parsers - it's just making things use the stuff that already exists. |
| 15:56.46 | schmidts | but he is right i should add a unit test for RPID and PAI headers too |
| 15:58.22 | pabelanger | Qwell: even more a reason, not to break existing functionality |
| 16:02.17 | WIMPy | schmidts: As you mentioned it, have you ever seen a 'verified and faild' anywhere? |
| 16:02.51 | schmidts | WIMPy what do you mean? |
| 16:03.54 | WIMPy | Have you ever seen that value being used? |
| 16:04.03 | WIMPy | If so in what situation? |
| 16:04.18 | schmidts | WIMPy not on the sip side, but for pstn |
| 16:04.32 | WIMPy | Yes, on pstn. |
| 16:04.42 | WIMPy | I have never seen it. |
| 16:09.48 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:09.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:23.55 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:23.55 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 16:23.56 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 16:23.56 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 16:24.55 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:24.55 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 16:40.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@nat/digium/x-xvltdrzbjadbgura) |
| 16:46.24 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:07.33 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:07.33 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 17:15.58 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 17:19.01 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 17:19.01 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 17:57.40 | *** join/#asterisk-dev coreyf1513 (~cfarrell@2001:4830:117f:3:219:21ff:fe2f:26e3) |
| 19:15.41 | *** join/#asterisk-dev bklang (~bklang@c-66-56-12-125.hsd1.ga.comcast.net) |
| 19:16.42 | kpfleming | Corydon76-home: since I'm not an OSX user, can you update your comment on reviewboard to list the OpenSSL prototypes that don't match? |
| 19:16.55 | kpfleming | or restated... show me what they are in your copy of OpenSSL |
| 19:17.06 | Corydon76-home | kpfleming: the arguments lack the const qualifier |
| 19:17.13 | kpfleming | lovely |
| 19:17.54 | kpfleming | so if this patch is going to survive, i'll have to know which version of OpenSSL added the const qualifiers, and use #ifdef to construct the prototypes appropriately |
| 19:23.45 | Corydon76-home | paravoid's suggestion sounds a lot simpler |
| 19:24.20 | kpfleming | maybe. it requires that a *lot* of modules and their dependency libraries be investigated and dealt with, though. i'm not thrilled with that part. |
| 19:35.30 | tzafrir_laptop | I feel a bit uncomfortable with an unversioned lib in /usr/lib |
| 19:39.11 | Corydon76-home | And if we're using postgres with ssl via ODBC, there doesn't appear to be a way to tell that driver not to initialize openssl, short of linking Asterisk with the postgres libraries |
| 19:40.03 | Corydon76-home | and given that's what we're recommending for postgres connectivity going forward..... |
| 19:41.00 | Corydon76-home | kpfleming: I think there's a better way to save the patch, though: using a stub file that doesn't include the openssl headers |
| 19:41.21 | Corydon76-home | You could thus define the symbols without colliding with system headers |
| 19:42.45 | Corydon76-home | It relies on the same principle, though: symbols defined in the core override all symbols in libraries |
| 19:57.15 | kpfleming | yes, but that only helps if the differences in the prototypes are const qualifiers and such... if there are (heaven forbid) actual differences in the argument lists or return types, that's pretty bad |
| 19:57.23 | kpfleming | i have to head to a meeting, i'll be back in an hour or so |
| 19:57.29 | Corydon76-home | k |
| 19:58.08 | Corydon76-home | That's true, but that would be a pretty major departure from openssl's practices in the past |
| 19:58.42 | *** join/#asterisk-dev otherwiseguy_ (~otherwise@nat/digium/x-stvbdzblsflyegtt) |
| 19:58.49 | Corydon76-home | Other than qualifiers, if they wanted to add something, they deprecate the old interface and add a new one |
| 20:42.30 | Corydon76-home | kpfleming: if you take the libasteriskssl.so out of the Makefile, it links fine. |
| 21:07.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@nat/digium/x-ccghpiolrnjgltcb) |
| 22:05.26 | *** join/#asterisk-dev moy (~moy@216.172.42.74) |
| 22:09.45 | mjordan | so - under what conditions would we be entering learning mode. My understanding is it should only be occurring when the source of the RTP is expected to change |
| 22:10.02 | putnopvut | mjordan: that includes immediately when media starts flowing to Asterisk on a call. |
| 22:10.21 | file | Background: dtmf test is failing, could be strictrtp change that went in |
| 22:10.35 | mjordan | hm. So we bind to a socket, receive nothing, turn on media, and enter learning mode to learn that we need media from the socket we previously bound to? |
| 22:11.02 | kpfleming | Corydon76-home: what do you mean 'take libasteriskssl.so' out of the Makefile? |
| 22:11.03 | jrose_atDigium | Presumably it takes a handful of milliseconds for learning mode to switch sources and drops everything until then. |
| 22:11.22 | Corydon76-home | kpfleming: it appears to duplicate what's already in ssl.c |
| 22:11.25 | mjordan | jrose_atDigium: what I'm having a problem wrapping my head around is why we need to drop frames when we previously didn't have a destination |
| 22:11.34 | putnopvut | mjordan: I may be misunderstanding what you're saying. I think learning is not about knowing on what socket to receive RTP, it's about who we're receiving from. |
| 22:11.46 | mjordan | yes, I said that poorly. |
| 22:11.48 | putnopvut | So when a call starts, we have to learn where RTP will come from. |
| 22:11.50 | Corydon76-home | It will not link on Snow Leopard |
| 22:12.09 | putnopvut | Then we hone in on that destination since we're strict about where RTP comes from. |
| 22:12.23 | mjordan | putnopvut: but the point here is that if we aren't switching from Source A to Source B, but simply being receiving frames from Source A, why would we need to drop the frames? |
| 22:13.03 | mjordan | strictrtp was to prevent an attacker from interjecting themselves into the RTP stream, the learning mode is merely the solution for that where we pick a winner - but why do we need to learn to pick a winner when there's only one contestant? |
| 22:13.06 | putnopvut | Strictly from a code perspective, we don't distinguish between "learning our initial destination" and "learning a changed destination" |
| 22:13.29 | mjordan | right - so our implementation is causing tests to fail. |
| 22:14.40 | jrose_atDigium | Well, the alternative is to do what we did before in that case and not drop the frames while in learning mode. But that creates that dangerous situation where learning mode isn't really loud about what it's doing, so you could get a fight going that never ends. |
| 22:15.01 | kpfleming | Corydon76-home: the patch is supposed to remove ssl.c, and the notes on the review indicate that. if you pull from my branch, it should build for you. |
| 22:15.07 | mjordan | jrose_atDigium: not really. If you have never received a frame before, we shouldn't activate learning mode in the first place |
| 22:15.08 | putnopvut | There's also the possibility of doing something like mjordan suggests and not entering learning mode for initial media flow. |
| 22:15.17 | Corydon76-home | Oh, it is? |
| 22:15.28 | putnopvut | Just for changes from a previously established media source. |
| 22:15.33 | jrose_atDigium | We were using learning mode to start the calls before that patch went in. |
| 22:15.46 | putnopvut | Indeed, I know that you didn't change that. |
| 22:16.02 | mjordan | but, as putnopvut pointed out, we now drop a few frames |
| 22:16.10 | Corydon76-home | kpfleming: well, the added files are missing from the patch |
| 22:16.19 | putnopvut | The thing is, learning mode may have been wrong before too, it's just that since we're actually dropping frames, it is exposing that it may have been implemented incorrectly in the first place. |
| 22:16.30 | putnopvut | file: care to weigh in? |
| 22:16.33 | jrose_atDigium | Alrighty |
| 22:16.49 | file | in a moment, yes |
| 22:16.55 | file | I'm contemplating |
| 22:17.02 | kpfleming | Corydon76-home: yes, that's a reviewboard problem |
| 22:17.04 | jrose_atDigium | We could pretty easily determine if we had no previous source and just auto-learn on the first frame when that's the case. |
| 22:17.20 | kpfleming | no. i don't agree. |
| 22:17.31 | kpfleming | we should always learn, even on the initial media flow. |
| 22:17.44 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 22:17.52 | kpfleming | if that means that tests need to have 10 frames of silence at the beginning so that the probation code can lock onto the media stream, so be it. |
| 22:18.00 | jrose_atDigium | If that's the case, then the tests need to be changed. |
| 22:18.10 | jrose_atDigium | Slightly. |
| 22:18.30 | kpfleming | for the tests specifically, disabling strictrtp mode would be fine, because there's no concern about attackers injecting media. |
| 22:18.44 | file | yeah |
| 22:18.52 | kpfleming | but for general usage, strictrtp should continue to be the default, and we should learn even on the initial media flow |
| 22:19.07 | kpfleming | the only other solution to the problem that strictrtp is intended to address is ICE |
| 22:19.45 | jrose_atDigium | ICE is clearly too cold to consider implementing right now. |
| 22:19.54 | jrose_atDigium | *snark |
| 22:20.01 | file | doing both is also an option and adjusting the test to make it more... well... real worldish? |
| 22:20.30 | mjordan | file: for the rfc2833_dtmf_detect test maybe, but it means altering the pcaps |
| 22:20.42 | mjordan | not impossible, but not really necessary either. |
| 22:21.09 | file | is there any silence ahead of it or is it just straight rfc2833? |
| 22:22.34 | mjordan | straight rfc2833. First packet is a DTMF event. |
| 22:22.40 | mjordan | at least in the first random pcap I grabbed |
| 22:23.02 | file | oic |
| 22:23.16 | mjordan | well, my guess on the voicemail tests is that the SendDTMF app is going to also cause a problem |
| 22:23.29 | mjordan | changing that would be.... problematic |
| 22:23.33 | putnopvut | Yeah the rfc2833 tests were not designed to have to know about packets being purposely dropped. |
| 22:23.41 | putnopvut | It makes sense to just turn off strictrtp for the tests. |
| 22:24.19 | putnopvut | But it does raise the point about if there are real life scenarios where there are services out there that just answer and start blasting out DTMF without sending silence first. |
| 22:24.20 | kpfleming | agreed |
| 22:25.00 | mjordan | is it possible to send DTMF over early media? |
| 22:25.15 | file | possible? yes |
| 22:25.28 | file | is it always possible? no |
| 22:25.39 | jrose_atDigium | Well, it might be wrong to not enforce learning mode during the first few frames of the conversation, but what if we just didn't drop the packets during the first learning mode? |
| 22:25.49 | jrose_atDigium | Is there a problem with that? |
| 22:26.59 | jrose_atDigium | s/drop the packets/drop the frames |
| 22:27.05 | mjordan | no, unless you discover during learning mode (first or otherwise) that you have to reset. Then you'd need to drop the frames you had buffered. |
| 22:31.28 | file | just disable strictrtp mode for now on the tests, but adding a low priority item about it may be good |
| 22:31.40 | kpfleming | you can't buffer the frames. you either have to deliver them, or drop them. |
| 22:31.44 | file | imo having some silence at the beginning more accurately reflects the real world |
| 22:32.45 | kpfleming | yes |
| 22:33.15 | putnopvut | I was about to say what file just said. |
| 22:33.37 | putnopvut | So in other words, I don't think any strictrtp machination changes are necessary. |
| 22:33.45 | file | right |
| 22:44.07 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 22:55.23 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jokvonyvzhtlkima) |
| 23:03.03 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:03.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:37.22 | russellb | kpfleming: bye |
| 23:37.28 | russellb | i mean hi |
| 23:38.24 | snuff-work | lol |
| 23:38.46 | snuff-work | i see oVirt will be discussed at SCALE.. |
| 23:38.59 | russellb | that does not surprise me |
| 23:39.54 | snuff-work | so do u do work on that or on other stuff? |
| 23:45.30 | kpfleming | he works on EVERYTHING |
| 23:46.01 | russellb | snuff-work: other stuff |
| 23:47.18 | snuff-work | mm getting closer to rolling out my company on * again.. should be interesting |
| 23:47.25 | russellb | cool deal |
| 23:48.41 | snuff-work | which reminds me.. need to see if anyone showed love to my issue with extenpatternmatchnew and it fail prefering regex over standard numbers when 'included' |