| 00:02.35 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:30a:2ef2:840:20c:29ff:fe4f:cac8) |
| 00:12.43 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:12.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:19.28 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:36.17 | *** join/#asterisk-dev maczor (6e8f08aa@gateway/web/cgi-irc/kiwiirc.com/ip.110.143.8.170) |
| 00:37.36 | maczor | Hi I was wondering if someone could point me in the direction of the best contact at Digium to discuss the code contribution licence that needs to be signed before submitting a patch? |
| 00:45.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:54.07 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:02.56 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 01:38.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:49.54 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:18.51 | *** part/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 02:24.10 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 04:24.59 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 04:46.35 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 04:57.28 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 04:57.28 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 05:00.42 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 05:05.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 05:05.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 06:07.15 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.81.110) |
| 06:31.00 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f1d4:c68a:a684:47a6) |
| 06:34.52 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:13.37 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.81.110) |
| 07:30.38 | coreyfarrell | wdoekes: thanks for the chan_sip patches/tests.. I'm busy the next few days but if nobody reviews them I will |
| 08:31.19 | wdoekes | nice |
| 11:24.11 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:24.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:38.31 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 11:50.53 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 11:51.58 | file | definitely a Thursday |
| 12:07.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:19.43 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:32.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:26.58 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:52.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:59.39 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bejcjmvkeypxwkuu) |
| 13:59.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.12 | *** join/#asterisk-dev bklang (~bklang@coquette.alkaloid.net) |
| 14:02.02 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-gfytwevmwuvrjopz) |
| 14:02.02 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:27.17 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jkhzdnyhrfqvuchq) |
| 14:29.36 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:40.39 | file | nods to skrusty |
| 14:44.57 | skrusty | afternoon |
| 14:44.59 | skrusty | :) |
| 14:47.50 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:51.41 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 14:51.42 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 14:53.33 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:53.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:06.53 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 15:11.42 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:17.35 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-mkhgqcmwcfmzsrdn) |
| 15:38.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 15:38.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:44.31 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c6f:94ba:1888:694a) |
| 15:56.43 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 16:02.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 16:08.34 | wdoekes | tzafrir: this seems stalled. http://anonscm.debian.org/cgit/pkg-voip/asterisk.git/tree/debian/patches/menuselect_weakref along with r1330 -- any updates? |
| 16:28.47 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-xvulynxnvldbnjea) |
| 16:31.39 | tzafrir | wdoekes, it seems that this patch was not actually used in the Debian package (not included in the series file) |
| 16:31.59 | tzafrir | There are some other gcc 4.6 fixes mentioned at around that time |
| 16:56.42 | wdoekes | ah, ok |
| 17:05.46 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 17:11.34 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-efgzkxwfqbihpkyt) |
| 17:14.43 | hexanol | hi |
| 17:14.55 | hexanol | we've upgraded from asterisk 11.12.1 to 11.13.0 recently |
| 17:15.09 | hexanol | and we just observed on behaviour change |
| 17:15.17 | hexanol | in caller ID parsing |
| 17:15.33 | hexanol | i.e. more precisely in the ast_callerid_parse function |
| 17:16.03 | hexanol | functionaly, what this means is that, using asterisk 11.12.1, we had |
| 17:16.10 | hexanol | buf: "*10" |
| 17:16.11 | hexanol | buf: |
| 17:16.11 | hexanol | name: *10 |
| 17:16.11 | hexanol | location: (null) |
| 17:16.26 | hexanol | and in asterisk 11.13.0, we now have |
| 17:16.31 | hexanol | buf: "*10" |
| 17:16.31 | hexanol | buf: "*10 |
| 17:16.31 | hexanol | name: (null) |
| 17:16.31 | hexanol | location: *10 |
| 17:16.57 | hexanol | i.e. now, the string "*10" is parsed as having no name and having a location *10 |
| 17:17.11 | hexanol | but before, the same string was parsed as having a name *10 and no location |
| 17:19.06 | hexanol | here's the example module I used to do my tests: https://github.com/elessard1/asterisk-lab/blob/ast_callerid_parse/lab.c |
| 17:20.42 | mjordan | opticron: sound like r422113 |
| 17:21.26 | hexanol | basically, we found the change because we have a test were we do an originate to an Aastra phone and then to the #25 extension |
| 17:21.37 | hexanol | and it was working in 11.12.1 |
| 17:21.51 | mjordan | hexanol: file an issue please. |
| 17:21.59 | hexanol | ok, I can do that |
| 17:22.13 | hexanol | and yes, I confirm that it is in 422113 |
| 17:23.14 | hexanol | that said, I found that the documentation of ast_callerid_parse function was rather vague as what was expected |
| 17:23.22 | hexanol | i.e. mjordan, you believe this is really a bug ? |
| 17:23.27 | hexanol | and not just an edge case |
| 17:23.29 | mjordan | I don't know. |
| 17:23.35 | hexanol | that was already an "undefined behaviour" |
| 17:23.36 | hexanol | k |
| 17:24.04 | mjordan | If you pass "*10" as the name field in the caller ID, that should be the name |
| 17:24.19 | hexanol | well, the whole string is "*10" |
| 17:24.23 | mjordan | If you pass "*10 -- without closing the quotation - you're in an off-nominal. |
| 17:24.25 | mjordan | Then yes. |
| 17:24.25 | hexanol | if I pass "*10" <> |
| 17:24.33 | mjordan | "*10" <> should result in *10 being the name. |
| 17:24.42 | hexanol | yes, in this case this is what is returned |
| 17:24.50 | hexanol | if you look at the link |
| 17:25.02 | hexanol | I gave |
| 17:25.17 | hexanol | buf is printed before calling ast_callerid_parse and also after |
| 17:25.23 | mjordan | er |
| 17:25.45 | mjordan | so you mean the bug is that the buffer being passed to ast_callerid_parse is not being modified? |
| 17:26.08 | hexanol | no |
| 17:26.18 | hexanol | sorry I might not be clear |
| 17:26.43 | mjordan | If you pass "*10" <>, then the name should be *10 and the location should be empty. |
| 17:26.49 | mjordan | If that isn't happening, then the parsing is messed up. |
| 17:27.22 | hexanol | for this value, the result is that same for asterisk 11.12 and asterisk 11.13 |
| 17:27.27 | hexanol | the value which is problematic |
| 17:27.35 | hexanol | is when you pass only "*10" |
| 17:27.42 | hexanol | without a <> part |
| 17:27.56 | hexanol | then the name is empty and the location is *10 |
| 17:28.00 | hexanol | in asterisk 11.13 |
| 17:28.12 | mjordan | k. It shouldn't have changed the behavior. I'd file a bug. |
| 17:28.18 | hexanol | but in asterisk 11.12, with the same value, the name is *10 and the location is null |
| 17:28.45 | hexanol | ok, I will |
| 17:46.46 | *** join/#asterisk-dev otherwiseguy (~otherwise@24.27.227.0) |
| 17:47.54 | opticron | looks |
| 18:00.56 | opticron | hexanol, do you have an issue number? I have a patch for you to try out (including an addition to the unit test) |
| 18:01.55 | hexanol | nope I did not create the issue yet, I was doing something else |
| 18:02.01 | hexanol | i.e. I plan on opening a ticket later today |
| 18:02.26 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 18:02.26 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 18:02.36 | opticron | gotca |
| 18:02.41 | opticron | +h |
| 18:18.04 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 18:18.07 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 18:21.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 18:24.32 | skrusty | evening |
| 18:26.06 | file | good evening |
| 18:27.26 | skrusty | think it's about time i grab a copy of 13 and give it a whirl |
| 18:36.00 | mjordan | file: consider a scenario where a UAC sends an INVITE request without an SDP and Asterisk responds with a 200 OK containing an SDP |
| 18:36.12 | mjordan | file: the UAC should then send the Answer to the Offer in the 200 OK in the ACK |
| 18:36.18 | file | oui |
| 18:36.22 | mjordan | file: what should be called in res_pjsip_session to negotiate the media? |
| 18:36.31 | mjordan | I think we might not be calling anything in that scenario |
| 18:36.47 | file | some stuff the PJSIP INVITE session calls |
| 18:37.03 | file | which trickles down into our calls |
| 18:37.30 | file | so off the top of my head I can't say exactly what |
| 18:37.44 | mjordan | hm. kk - I didn't see handle_incoming_sdp get called, nor handle_negotiated_sdp_session_media |
| 18:37.49 | mjordan | I shall continue investigating |
| 18:39.55 | mjordan | ah |
| 18:40.20 | hexanol | opticron, mjordan: I've opened an issue: https://issues.asterisk.org/jira/browse/ASTERISK-24406 |
| 18:40.22 | mjordan | I have a suspicion that we only call registered session supplements on the ACKs. The 'special' handling only kicks in for INVITE requests |
| 18:40.22 | gtjoseph | mjordan: oops, sorry about the load failure. i caught that this morning but didn't commit the correct patch. |
| 18:40.26 | hexanol | hoping it's clearer than my explanation here :) |
| 18:40.29 | mjordan | gtjoseph: no worries ;-) |
| 18:40.39 | mjordan | the bamboo test run should be suitably explosive |
| 18:40.55 | file | I'm not even sure if ACKs reach us... |
| 18:40.55 | gtjoseph | are you going top push that to trunk? |
| 18:41.16 | mjordan | gtjoseph: yup, building now |
| 18:41.28 | mjordan | file: hm. That would be unfortunate. |
| 18:41.51 | mjordan | file: Pretty sure it does, since I see it getting hit by the boilerplate debug in res_pjsip_session |
| 18:43.27 | opticron | hexanol, patch attached |
| 18:43.37 | hexanol | alright |
| 18:54.56 | hexanol | opticron: I've added a comment saying that the patch does fix my use cases |
| 18:55.44 | opticron | cool, I'll post it up to reviewboard |
| 19:10.40 | Qwell | sgriepentrog: ping! is your email sgriepentrog@? |
| 19:10.48 | sgriepentrog | yup |
| 19:15.47 | mjordan | file: Hm. I'm starting to think that pjproject isn't calling the UA level callbacks when an ACK has the SDP Answer |
| 19:17.41 | mjordan | hrm. Except that the documentation implies taht they're cool with it. |
| 19:17.44 | mjordan | looks deeper |
| 19:17.58 | leifmadsen | documentation has never been wrong! |
| 19:18.55 | file | mjordan, as we have recently learned... the documentation can lie |
| 19:19.06 | mjordan | truth |
| 19:26.47 | mjordan | it does callback into us, just not when I expected. |
| 19:28.11 | jsmith | mjordan: What does it do, wait until the BYE? |
| 19:28.13 | jsmith | ducks and hides |
| 19:35.17 | mjordan | jsmith: that'd be sub-optimal :-) |
| 19:37.22 | jsmith | mjordan: Sounds like it's already sub-optimal :-) |
| 19:37.33 | jsmith | mjordan: I was just suggesting that it could be worse... |
| 20:00.18 | gtjoseph | opticron: does r4062 actually work? I tried something similar with phoneprov but the module load failed before even checking because the symbol table failed to load. |
| 20:00.53 | opticron | it works in the case that I've reproduced |
| 20:01.09 | gtjoseph | hmmm |
| 20:01.41 | opticron | but I probably have a different failure than you do from the sound of it |
| 20:02.08 | opticron | in this case, res_pjsip started to load, but then failed |
| 20:02.25 | opticron | so the symbols were available, but res_pjsip had declined its load |
| 20:02.33 | opticron | and wasn't setup at all |
| 20:02.36 | gtjoseph | ah, that makes sense now |
| 20:02.38 | opticron | which made other thigns go crashy |
| 20:11.25 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:13.46 | ipengineer | Does anyone know if something was put in place between 12.5 and 13b2 that would aid in endpoints with SIP ALG? I have several devices, on different networks with SIP ALG that would not work on 12.5 but work great on 13.. Very odd |
| 20:14.39 | leifmadsen | that is odd |
| 20:14.49 | file | nope |
| 20:15.12 | leifmadsen | http://i.imgur.com/0CwIvYt.png |
| 20:15.30 | Marquis42 | +INF |
| 20:15.52 | ipengineer | leifmadsen: Thats about the truth right there.. Just very strange. These routers dont allow you to turn ALG off.. They are crap |
| 20:16.00 | Marquis42 | Ugh |
| 20:16.07 | Marquis42 | That's awful. |
| 20:16.26 | leifmadsen | ipengineer: I have used this on support engineers and it solves the problem :) |
| 20:18.35 | ipengineer | On our GUI that shows registered devices it shows yellow if they have ALG on them. I dont want to hear anyone if thats the case |
| 20:19.14 | ipengineer | **Except in this scenario** seeing as so many of these routers are out there. AND upgrading seemed to fix the problem across three different networks.. |
| 20:20.06 | mjordan | hm. |
| 20:20.27 | mjordan | chan_sip, right?' |
| 20:20.34 | ipengineer | pjsip |
| 20:22.21 | mjordan | in both cases? Weird. |
| 20:22.38 | mjordan | There really hasn't been substantial changes in the stack. Do you have traces of the messages going through both? |
| 20:22.50 | ipengineer | I have another box with 12.5 so I am going to update it and see if the same thing happens there |
| 20:27.35 | gtjoseph | mjordan: could you give a quick look at https://reviewboard.asterisk.org/r/4065/ ? I updated it with the changes you suggested from the other testsuite review |
| 20:28.04 | mjordan | looks |
| 20:28.27 | mjordan | Ship It! :-) |
| 20:28.38 | gtjoseph | cool, thanks |
| 20:28.49 | mjordan | thanks for writing tests :-) |
| 20:28.55 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:29.05 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:29.20 | gtjoseph | it's not as scary as I thought it was. :) |
| 20:35.13 | mjordan | that's good to hear |
| 20:35.23 | mjordan | we've spent a good chunk of time trying to make it easier to write tests for things |
| 20:37.50 | gtjoseph | yeah, once you figure out not to trust the documentation or examples. :) |
| 20:40.26 | mjordan | er |
| 20:40.28 | mjordan | sorry bout that |
| 20:40.29 | mjordan | :-) |
| 20:41.21 | gtjoseph | no worries. actually, i'll update it this weekend. |
| 21:04.11 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:36.39 | file | gtjoseph, you haz broken 13 |
| 21:38.26 | rmudgett | file: as in no compily? |
| 21:39.04 | file | yes |
| 21:40.18 | rmudgett | something to do with converting an ao2 container to a vector when going from 12 to 13? |
| 21:40.43 | file | methinks so |
| 21:41.05 | rmudgett | Yup It broke for me tooooooo. |
| 21:41.24 | file | not quite sure what to do with it |
| 21:42.58 | file | but I do know I'm going to have a Pepsi Next |
| 22:10.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bejcjmvkeypxwkuu) |
| 23:01.54 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 23:01.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:10.04 | gtjoseph | file: What did I do? |
| 23:24.55 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jkhzdnyhrfqvuchq) |
| 23:25.17 | gtjoseph | oh, yeah. i had a separate patch for 13 just for that then promptly forgot to use it. |
| 23:38.01 | gtjoseph | file: fixed in 13 and trunk. Sorry. |
| 23:52.31 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
