| 02:09.15 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 02:56.29 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 02:56.55 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 03:04.37 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 03:05.08 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 03:06.40 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 04:48.15 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:52.57 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 06:24.44 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 06:33.21 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 07:07.43 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 07:26.12 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:26.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:02.21 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:15.52 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:19.08 | *** join/#asterisk-dev oej (~Adium@2.71.187.85.mobile.tre.se) |
| 09:19.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:34.59 | *** join/#asterisk-dev jamesc|2 (~kvirc@mail2.inetplc.com) |
| 09:38.14 | jamesc|2 | Hi I am writing a patch to allow the first leg of a call to bind the rtp on one interface and the next log to bind on a different network interface. I have noticed that this is not currently possible at the moment as call will have one way audio due to using the defaut route. binding avoid this. Where do I need to submit my first patch to ? |
| 09:57.31 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 09:57.32 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 10:25.33 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 11:57.04 | *** join/#asterisk-dev looserouting (~paolo@ip-62-143-36-139.hsi01.unitymediagroup.de) |
| 12:01.30 | looserouting | in main/tcptls.c when comparing common name of the certificate wildcards are not considered. Validation will fail for CN=*.example.org and hostname=sipsrv.example.org |
| 12:04.15 | looserouting | am I right ?`is this known ? should I create a bug ? |
| 12:04.55 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:08.33 | wdoekes | looserouting: I don't think that is known. please do file a bug |
| 12:27.36 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 13:03.49 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:03.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:04.01 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:12.59 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 13:12.59 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 13:15.35 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 13:15.35 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:15.35 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:15.35 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 13:15.35 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 13:15.35 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-boeazzlbzlokrgfu) |
| 13:15.35 | *** mode/#asterisk-dev [+o snuff-work] by sendak.freenode.net |
| 13:22.54 | *** join/#asterisk-dev spditner (~simon@69-165-129-190.dsl.teksavvy.com) |
| 13:30.50 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tbbzagurylffwaez) |
| 13:30.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:41.30 | looserouting | <PROTECTED> |
| 13:48.53 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-fmkvbzcdjxkohiky) |
| 13:48.58 | blitzrage | looserouting: and I've subsequently closed it :\ |
| 13:49.09 | blitzrage | sorry |
| 13:49.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:57.49 | *** join/#asterisk-dev dms1 (~dms1@c-50-168-154-89.hsd1.sc.comcast.net) |
| 13:59.58 | looserouting | leifmadsen, this is interesting. i didn't know that RFC. you are absolutly right. |
| 14:00.40 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gsfsbjybfiwroxnq) |
| 14:00.57 | pabelanger | leifmadsen is da bomb |
| 14:01.04 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-yomiwsxdjbgoqazz) |
| 14:01.04 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:01.41 | leifmadsen | is kind of a big deal |
| 14:01.49 | leifmadsen | actually, it was all Marquis42 and zerohalo :) |
| 14:01.59 | leifmadsen | they have been doing TLS for the last month |
| 14:02.06 | leifmadsen | we just got all our video working about 10 mins ago |
| 14:03.13 | zerohalo | and it was a long, drawn-out headache... but it now works |
| 14:03.26 | zerohalo | use SANs for any additional hostnames you want on a cert |
| 14:04.13 | pabelanger | Nice |
| 14:04.25 | pabelanger | Just got dtls-srtp working yesterday too |
| 14:04.31 | leifmadsen | nice |
| 14:04.41 | leifmadsen | yea, we're using a proxy in front because asterisk tls looks pretty shady in 1.8 :) |
| 14:05.44 | Marquis42 | s/in 1.8// |
| 14:05.46 | Marquis42 | :D |
| 14:05.56 | leifmadsen | exactly :) |
| 14:05.56 | Marquis42 | is not talking about chan_pjsip at all |
| 14:05.57 | zerohalo | hah - yeah |
| 14:11.35 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:11.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:16.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:16.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:19.02 | mjordan | opticron: did you also merge my presence state/device state/extension state list tests? |
| 14:19.23 | opticron | I did |
| 14:19.30 | opticron | with the corrections I suggested |
| 14:22.40 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:24.04 | mjordan | opticron: nifty, thanks |
| 14:24.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:24.52 | opticron | this probably needs another review as well: https://reviewboard.asterisk.org/r/3823/ |
| 14:25.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:26.14 | mjordan | opticron: yup, I'll hit that now |
| 14:28.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 14:30.31 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:33.11 | mjordan | opticron: soooo close |
| 14:33.15 | opticron | awww |
| 14:33.34 | *** join/#asterisk-dev XATRIX (~xatrix@77.88.209.171) |
| 14:33.46 | opticron | hah, I accidentally dropped that part of the patch |
| 14:33.54 | opticron | apparently |
| 14:35.38 | *** part/#asterisk-dev XATRIX (~xatrix@77.88.209.171) |
| 14:39.13 | mjordan | opticron: let me know when you've got it back up |
| 14:41.10 | opticron | as soon as it finishes compiling |
| 14:42.34 | mjordan | Qwell: think you might to get the findings on https://reviewboard.asterisk.org/r/3833/? I'd like to get that in for the beta release |
| 14:43.19 | Qwell | yes, will try for today |
| 14:43.43 | mjordan | cool, thanks |
| 14:43.55 | mjordan | opticron: did we have any more reviews up for the crazy attended transfer in Stasis shenanigans? |
| 14:45.00 | opticron | no, those are all committed to the staging branch for testing |
| 14:45.35 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-gywfphphqeczsfwt) |
| 14:47.00 | opticron | pushed up |
| 14:55.52 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-fmwkfwxlldggpdrm) |
| 15:18.36 | jamesc|2 | can someone show me how to go from a string to in_addr using ast_gethostbyname please |
| 15:18.58 | jamesc|2 | I am confused by the struct and how to use them |
| 15:19.12 | jamesc|2 | hp = ast_gethostbyname(str,&ahp); |
| 15:25.57 | *** join/#asterisk-dev stevePearPear_ (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 15:29.00 | mjordan | jamesc|2: I think a more specific question would be helpful. Do you have a specific question about its usage? If so, a pastebin of your code would also be helpful |
| 15:58.22 | mjordan | putnopvut: I'm looking at RLS reviews right now, although admittedly I'm mostly just finding nit picky off nominal stuff. I'm sort of deferring the nominal "does it work" to jrose's tests |
| 15:58.49 | putnopvut | mjordan: totally fine by me |
| 15:58.58 | putnopvut | And thanks for having a look :) |
| 16:29.12 | mjordan | file: on your outbound publish support - is there any reason why we are repurposing the ast_datastore structure, other than it has the elements we want? I'm a bit worried about the different API semantics |
| 16:29.42 | file | can you be specific? that usage originates from res_pjsip_pubsub itself |
| 16:30.14 | mjordan | specifically, "DO NOT call ast_datastore_free() on a datastore allocated in this" |
| 16:30.33 | file | ah, cause it's ao2 |
| 16:30.37 | mjordan | i.e., its lifetime is reference counted rather than explicit |
| 16:30.38 | mjordan | yeah |
| 16:30.50 | mjordan | If you're handed an ast_datastore, you don't know what you are supposed to do with it |
| 16:30.58 | file | putnopvut, ^^^ |
| 16:31.00 | mjordan | I mean, sure, hopefully you know where it came from :-) |
| 16:36.04 | putnopvut | Sorry, just got back in from picking up some lunch. /me catches up |
| 16:37.00 | putnopvut | No one gets "handed" an ast_datastore though. They specifically request it from a session/subscription/publication, and thus are bound by the rules that are documented on those APIs. |
| 16:38.04 | mjordan | Still, it feels prone to programmer error. Is there any way we could assert in the 'original' datastore code or in the destructor if someone disposes of it in an incorrect fashion? |
| 16:39.28 | putnopvut | Not anything that isn't super painful |
| 16:40.04 | mjordan | k, moving on then :-P |
| 17:15.54 | rmudgett | file: IAX2 compatibility bit elaboration posted |
| 17:16.01 | file | already responded |
| 17:16.19 | *** join/#asterisk-dev visnu (ThrashIRC@unaffiliated/visnu) |
| 17:18.35 | gtjoseph | who's the pbx.c ast_merge_contexts_and_delete and context_merge expert these days? |
| 17:20.58 | rmudgett | gtjoseph: You must be since you just looked at it. :) |
| 17:21.17 | gtjoseph | that's what I was afraid of. :) |
| 17:23.18 | rmudgett | file: Are you OK with eliminating the index gap instead? |
| 17:23.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:26.50 | mjordan | gtjoseph: I have looked at that code before, but only briefly. Wouldn't say I'm an expert by any stretch. |
| 17:27.15 | file | I would prefer we not break it between versions... |
| 17:27.29 | gtjoseph | I just need a quick check on a proposed fix... |
| 17:27.48 | mjordan | what are we fixing? :-) |
| 17:28.25 | gtjoseph | ASTERISK-23818 is back again and I think I now understand the root cause... |
| 17:29.28 | gtjoseph | look at the last lines of pbx.c context_merge... |
| 17:30.02 | mjordan | looks |
| 17:30.09 | gtjoseph | I believe context_merge_incls_swits_igps_other_registrars should be called outside that last if block so it's always executed. |
| 17:30.22 | rmudgett | file: ok. I'll put dire warning comments that won't be read there instead. |
| 17:30.36 | file | rmudgett, we'll never touch this stuff again |
| 17:31.04 | file | don't hold me to that. |
| 17:31.16 | gtjoseph | otherwise switches added by other modules aren't preserved. |
| 17:31.17 | mjordan | gtjoseph: How so, given that new is created just prior to that? |
| 17:31.37 | gtjoseph | it's not. look at the first line of the function. :) |
| 17:32.07 | gtjoseph | new is created at the top of the function if it already exists. just badly named. |
| 17:36.20 | gtjoseph | mjordan: what happens is pbx_lua creates the context with 1 switch statement (no extensions)... When pbx_config loads, it finds the context which means that if statment fails and the merge of the switch doesn't happen. |
| 17:47.33 | mjordan | gtjoseph: I think the behavior of having multiple dialplans provide a context is relatively undefined |
| 17:48.07 | gtjoseph | looks at the wiki |
| 17:48.16 | mjordan | oh, I'm sure there's an example of using a lua switch statement |
| 17:48.27 | mjordan | I'm just not sure anyone ever really thought through all the ramifications |
| 17:48.37 | mjordan | I'm not sure what would happen, for example, if you had the same extension provided by two dialplans. |
| 17:48.56 | gtjoseph | i'm just looking at the lua specific pages to see if any mention of context overlap. |
| 17:49.11 | gtjoseph | I (and others) always assumed you could. |
| 17:49.25 | sgriepentrog | mjordan: the first one loaded wins |
| 17:49.35 | gtjoseph | no it doesn't |
| 17:49.40 | gtjoseph | in this case |
| 17:49.43 | mjordan | heh |
| 17:50.02 | mjordan | I'd be happy if it was defined |
| 17:50.11 | gtjoseph | i'd be happy to. :) |
| 17:50.21 | mjordan | gtjoseph: only thing to be worried about here is breaking someone's existing dialplan |
| 17:50.32 | mjordan | granted, I think if you're loosening restrictions that's not that likely |
| 17:50.35 | sgriepentrog | There are mechanisms in freepbx that count on first wins, albeit only for custom override stuff. |
| 17:50.39 | file | or breaking the PBX core in general |
| 17:50.45 | mjordan | heh |
| 17:50.46 | file | this code falls like dominos... |
| 17:50.50 | mjordan | was just about to say there's dragons in that cod3e |
| 17:50.52 | mjordan | code as well |
| 17:50.58 | Qwell | sgriepentrog: That's not whole contexts though, just extensions in a context. |
| 17:51.09 | Qwell | and possibly only priorities, at that |
| 17:51.13 | gtjoseph | agreed. that's why i'm asking. it's a 1 line fix but... |
| 17:51.21 | mjordan | Qwell: And all of that *should* be provided by a single dialplan engine, right? |
| 17:51.30 | mjordan | if it is all pbx_config, no harm no foul |
| 17:51.30 | Qwell | mjordan: No comment. |
| 17:51.34 | mjordan | Qwell: good lord. |
| 17:52.16 | Qwell | as far as AEL goes, it should look like the parsed AEL stuffs is just further down in extensions.conf |
| 17:52.23 | Qwell | When you add LUA, all bets are off. |
| 17:52.23 | gtjoseph | i think merging in general is working OK. it's just switch and ignorepat that aren't merged correctly |
| 17:52.43 | mjordan | I'm curious what an svn blame says about that block. |
| 17:53.08 | sgriepentrog | we maybe should create a test for this so we know if it gets wacked |
| 17:53.34 | gtjoseph | ...and it only fails if the switch module is loaded BEFORE pbx_config. |
| 17:53.47 | mjordan | I'm not against a test; at the same time, this is one of those things that the side effects are going to be what hits you, not the obvious nominal cases. |
| 17:54.47 | mjordan | svn log -c 109169 if you're curious |
| 17:54.50 | sgriepentrog | which is why the test should make a good effort to cover as much abnominal as possible. |
| 17:55.28 | mjordan | gtjoseph: you might want to read that commit message, it is ... interesting. |
| 17:55.38 | gtjoseph | yeah, I'm reading now |
| 17:57.24 | Qwell | When murf punts on an issue related to AEL, you know you're screwed. |
| 17:58.33 | gtjoseph | hmmm. ael extensions are really merged into extsting contextx though whereas lua contexts are handled via a switch |
| 17:58.42 | mjordan | gtjoseph: here's the original issue - https://issues.asterisk.org/jira/browse/ASTERISK-11664 |
| 17:59.50 | gtjoseph | yep, that's the exact symptoms with lua |
| 18:00.58 | gtjoseph | lua is loaded very early because it has to export the global lua_symbols and that causes it to load before pbx_config. do a reload on lua and you're good. |
| 18:01.14 | mjordan | What part of that 'if' condition is failing for pbx_lua? |
| 18:01.30 | gtjoseph | !new |
| 18:01.44 | gtjoseph | pbx_lua created the context earlier. |
| 18:02.11 | mjordan | is first NULL then? |
| 18:02.22 | mjordan | I guess I'm curious why we don't get it in the main handling block earlier |
| 18:02.42 | mjordan | hm. Maybe because there are no priorities? |
| 18:03.02 | gtjoseph | the first line in context_merge looks for the context and sets new if it find it, which it should. |
| 18:03.46 | gtjoseph | the if causes the merge switch to happen only if it DIDN'T already exist. |
| 18:04.02 | mjordan | gtjoseph: which line are you referring to? |
| 18:04.08 | mjordan | 8770? |
| 18:04.37 | gtjoseph | 8770 is the if. 8699 is the set of new if the context already exists. |
| 18:04.42 | mjordan | I guess what I'm thinking is: that particular 'catch-all' at the bottom may not be the problem |
| 18:04.53 | mjordan | if the context already exists, then we should have added the switches in it prior to that anyway |
| 18:05.08 | mjordan | however, we don't. My guess is that there are no extensions/priorities in the context |
| 18:05.28 | gtjoseph | correct. lua doesn't add extensions. only the switch |
| 18:05.42 | mjordan | it may be that you need to add something like this |
| 18:05.45 | mjordan | (pb incoming) |
| 18:06.51 | mjordan | http://pastebin.com/70HYW0V6 |
| 18:07.17 | mjordan | probably not "correct", but it may be closer. Basically, even if we don't have extensions/priorities, merge the switches/stuff if we never did |
| 18:09.03 | gtjoseph | i think root-table is going to be empty at that point so that check won't happen. maybe just an else for the if (context->root_table)? |
| 18:10.02 | mjordan | heh, maybe. Now you're way past what I know in this part of the code :-) |
| 18:10.27 | file | DESTROY |
| 18:10.27 | gtjoseph | well, that's scary. :) |
| 18:10.29 | mjordan | but I'd feel (slightly) more comfortable doing something that targets how pbx_lua is working, and avoiding altering things that were done for AEL |
| 18:11.00 | gtjoseph | i'll play with it a bit and make sure I don't impact ael. |
| 18:20.16 | mjordan | heh. "Regular expressions are probably the world's most popular write-only language. " |
| 18:21.17 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-atkwvzhbhovnuojh) |
| 18:21.54 | Qwell | mjordan: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. |
| 18:22.01 | Qwell | and regex requires you to be pretty damn clever |
| 18:22.31 | mjordan | Qwell: that's one of my favorites |
| 19:05.12 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-ibbxutblvxdxtxxx) |
| 19:30.08 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.87.131.147) |
| 19:34.26 | gtjoseph | mjordan: here's my proposal for catching existing contexts with no extensions... http://pastebin.com/3QLQG6xg I'll be testing with AEL but it should be pretty safe. |
| 19:36.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:36.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:59.27 | mjordan | gtjoseph: Agreed; I don't _think_ that would cause harm :-) |
| 20:10.27 | pabelanger | famous last words |
| 20:11.15 | pabelanger | While developing webrtc and asterisk, did anybody run into issues with having to hold / unhold media to get it to establish in chrome correctly? |
| 20:22.59 | putnopvut | opticron: I just noticed that ari-greedy-atxfer had an automerge failure. If you're currently not working on resolving it, I'll take care of it. |
| 20:23.47 | mjordan | pabelanger: what client library are you using |
| 20:35.15 | pabelanger | mjordan, I was using sipml5 (latest) and chrome |
| 20:35.31 | pabelanger | But, it is not an asterisk issue |
| 20:35.37 | pabelanger | was more curious if anybody ever ran into it |
| 20:40.07 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:40.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:01.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:33.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:33.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:41.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 23:12.29 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:18.47 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-gsfsbjybfiwroxnq) |