IRC log for #asterisk-dev on 20160415

04:09.00*** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212)
06:26.35*** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net)
06:26.35*** mode/#asterisk-dev [+o tzafrir] by ChanServ
06:36.22jkroonhi all, i had a rather crazy idea last night.  in one of our scenarios we've got a LOT (couple thousand) being registered from one of a number of SBC type nodes.
06:36.39jkroonwe do use qualify=yes in all our configs and I'd prefer to keep using it.
06:37.35jkroonin chan_sip - how easy would it be to "merge" the qualifies for the same remote ip:port pairs?  ie, instead of sending one for every peer, use one for every unique ip:port combination.
06:48.15*** join/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es)
07:17.57*** join/#asterisk-dev pchero_work (~pchero@109.70.54.56)
07:26.08*** join/#asterisk-dev coreyf1513 (~coreyfarr@68-118-182-198.dhcp.asfd.ct.charter.com)
07:53.34*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
08:05.55*** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se)
08:05.56*** mode/#asterisk-dev [+o oej] by ChanServ
08:48.24*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
08:57.07*** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se)
08:57.08*** mode/#asterisk-dev [+o oej] by ChanServ
09:29.49*** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se)
09:29.49*** mode/#asterisk-dev [+o oej] by ChanServ
10:07.28*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
11:25.47*** join/#asterisk-dev oej (~oej@195.149.146.45)
11:25.47*** mode/#asterisk-dev [+o oej] by ChanServ
11:27.25*** join/#asterisk-dev acidfoo_ (~acidfoo@157-52-14-38.cpe.teksavvy.com)
11:50.02*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
12:12.25*** join/#asterisk-dev fornax (~fornax@85.183.43.221)
12:26.03*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
13:23.20*** join/#asterisk-dev [TK]D-Fender (~Joe@216-191-106-165.dedicated.allstream.net)
13:25.24gtjosephIt's not fair...  http://i.imgur.com/tBl0piY.png   It was 80°f here yesterday.
13:58.57*** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
13:58.58*** mode/#asterisk-dev [+o cresl1n] by ChanServ
14:04.25*** join/#asterisk-dev kharwell (kharwell@nat/digium/x-bvyaggvjpxqqnpde)
14:05.19*** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-fbxiwtggcoydotjg)
14:05.19*** mode/#asterisk-dev [+o newtonr] by ChanServ
14:14.06*** part/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es)
14:24.39*** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson)
14:24.39*** mode/#asterisk-dev [+o putnopvut] by ChanServ
14:26.05*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-nneeufygeccgfrxd)
14:37.22*** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca)
14:39.07hexanolhello, I just found a really minor issue, the option "registertrying" in chan_sip was removed in 2011 by commit 7f883ef495b57ae9182e47213d01d5e8009dbf3f but there's still a reference to the option in sip.conf.sample
14:39.37hexanolif I wasn't that lazy to learn how to use gerrit right now, I would push the modification but...
14:47.30*** join/#asterisk-dev oej (~oej@195.149.146.45)
14:47.31*** mode/#asterisk-dev [+o oej] by ChanServ
14:50.39wdoekeshexanol: you could file a ticket, that's marginally less work
14:51.37hexanolthis kind of issue really needs a ticket ? if you say so, I can do it
14:53.02fileideally everything should have a ticket, but any change to Asterisk goes through the same process - it's just you or someone else doing it in the end
14:59.59hexanolalright, there it goes: https://issues.asterisk.org/jira/browse/ASTERISK-25927
15:15.02*** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj)
15:18.58wdoekesthanks hexanol
15:20.04*** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file)
15:20.04*** mode/#asterisk-dev [+o file] by ChanServ
15:22.03*** join/#asterisk-dev danjenkins (danjenkins@gateway/shell/firrre/x-dnfypmkromzvocrd)
15:23.37*** join/#asterisk-dev coreyfarrell (~coreyfarr@68-118-182-198.dhcp.asfd.ct.charter.com)
15:24.38*** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-179-40-172.cust.bezeqint.net)
15:24.38*** mode/#asterisk-dev [+o tzafrir_] by ChanServ
15:26.29*** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson)
15:26.29*** mode/#asterisk-dev [+o putnopvut] by ChanServ
15:30.48*** join/#asterisk-dev anthm (~anthm@freeswitch-10.freeswitch.org)
15:30.48*** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26)
15:38.26*** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26)
15:52.07fileI felt bad -2ing that :( I had to up it to a -1
16:02.18gtjosephI wish alexei would join the -dev channel.
16:03.50*** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-ttknygbhynujeicq)
16:17.52filegtjoseph, I wish many things.
16:18.24gtjoseph:)
17:05.51*** join/#asterisk-dev oej (~oej@87.96.134.129)
17:05.51*** mode/#asterisk-dev [+o oej] by ChanServ
17:06.34*** join/#asterisk-dev opticron (~opticron@75.76.51.46)
17:06.34*** mode/#asterisk-dev [+o opticron] by ChanServ
17:32.43*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
17:35.25*** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-179-40-172.cust.bezeqint.net)
17:35.25*** mode/#asterisk-dev [+o tzafrir_] by ChanServ
17:36.55*** join/#asterisk-dev [TK]D-Fender (~Joe@216-191-106-165.dedicated.allstream.net)
17:37.48*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
17:37.48*** mode/#asterisk-dev [+o oej] by ChanServ
17:46.21*** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson)
17:46.21*** mode/#asterisk-dev [+o putnopvut] by ChanServ
17:49.28*** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212)
17:56.36*** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-isfjugkdqdeycaip)
18:08.29*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-chcodezcgrkcugsd)
18:34.40*** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-15.wall.uls.co.za)
18:57.14*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
18:57.14*** mode/#asterisk-dev [+o oej] by ChanServ
19:22.43*** join/#asterisk-dev tzafrir__ (~tzafrir@bzq-179-40-172.cust.bezeqint.net)
19:22.43*** mode/#asterisk-dev [+o tzafrir__] by ChanServ
19:26.57*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
20:00.27putnopvutfile: So I'm looking into this issue where we're validating URI length on a thread that's not registered with PJProject. I'm trying to find an alternative place to do URI length validation. I started eying ast_sip_location_retrieve_aor_contacts(), but I'm not sure if that's always called from a thread registered with PJLIB.
20:00.32putnopvutGot any ideas of your own?
20:00.44fileno :(
20:01.16cresl1nputnopvut: where are you doing it right now again?
20:01.32filein the config handler for permanent URI, which is called from anywhere
20:02.11cresl1ngoes to look at the patch instead :-)
20:04.26cresl1nis this the change in res/res_pjsip/location.c
20:04.27cresl1n?
20:04.46fileyes
20:06.52gtjosephmaybe just have ast_sip_validate_uri_length wrap a call to push_task_sync?
20:08.32fileyou can't
20:08.40gtjosephit's a little more overhead though
20:08.43gtjosephwhy/
20:08.44fileyou *can not* do that :D
20:09.06filebecause it can cause a deadlock when realtime is in use and there's limited PJSIP threads
20:09.55gtjosephyeah, true
20:10.44filea "git show f2725c8b77f6e6d6b70c12c4e57e26083530c3be" will provide the scenario
20:12.06cresl1nso let me understand this…
20:12.10gtjosephah
20:12.20cresl1nanytime you all a pjsip_* function it's gotta be from a registered pjsip thread?
20:12.26cresl1nany pjsip_* function?
20:12.41filecresl1n, any pj_* function basically yeah
20:12.55fileit should be done in a PJSIP thread - some may allow it otherwise
20:12.57fileand may tolerate it
20:13.07*** part/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca)
20:13.21cresl1nso where we call pjsip_endpt_create_pool, pjsip_parse_uri, pjsip_uri_get_uri, and pjsip_endpt_release_pool?
20:13.36filethe pool stuff throws a fit
20:13.37cresl1nok
20:13.40cresl1nAh....
20:13.41putnopvutyep
20:13.46cresl1nI can see that being a problem case
20:14.09cresl1nbut I'd hate having to remember which functions get angry and which ones don't
20:14.14cresl1nis it documented?
20:14.25putnopvutSo how feasible is it to push the uri validation to an async task so that we can retroactively remove the permanent URI if validation fails?
20:14.28fileno, which is why they should all be in PJSIP threads :P
20:14.47fileputnopvut, you can't remove a permanent URI - immutable
20:14.48gtjosephwhen i did ast_sip_validate_uri_length i looked in chan_sip for code to borrow but didn't find anything.  maybe it's time to create our own parser.
20:14.50putnopvutah
20:15.00putnopvuteek
20:15.22putnopvutSo the validation HAS to be done before the contact is added to the AOR
20:15.46putnopvutSo then make it an async test to handle the permanent URI?
20:15.52putnopvuts/test/task/
20:16.10filecan't modify the contact outside that scope - it's a sorcery object, immutable once passed back
20:16.26putnopvutSo you'd need to replace the sorcery object
20:16.35cresl1nCould you have a pool of pools managed by registered threads that can be borrowed from?
20:16.44cresl1non demand?
20:17.08cresl1nif it's just complaining about the pool allocation
20:17.10fileputnopvut, the sorcery object can be created when requested... may not remain in memory, you really need to block the caller...
20:17.11putnopvutI'm not sure that would help here since you'd still be performing pj_* tasks
20:17.21putnopvuturgh
20:18.20filewhere's the boundary where we need to care?
20:18.22putnopvutSo...
20:18.34putnopvutWhat if we just registered the thread with pjproject and call that the fix?
20:19.01filehrmph
20:19.07cresl1nlooks the other way
20:19.21filecan we last resort that? we've kept the boundary until now
20:19.32cresl1nyeah…
20:19.39cresl1nslippery slope and all that
20:19.48cresl1nI wanna understand why it's caring about registered threads so much
20:20.02gtjosephwe only need pjproject to validate the hostname length, not the uri length btw.
20:20.56gtjosephmaybe just use a simplistic parse, even regex, to get the hostname length
20:23.20fileif we could that'd be nice..
20:23.28putnopvutYeah, I'm thinking that's the best we can do
20:23.28gtjosephpre-compile the regex in the initialize
20:23.40*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-dqgkfdytqeccydbb)
20:23.48gtjosephit'd probably be cheaper that calling pjproject anyway
20:23.55gtjosephs/that/than/
20:26.03fileyeah
20:26.41cresl1n?desc
20:26.50cresl1ncrap
20:26.52cresl1nwrong window
20:29.07gtjosephTime to suggest the first use of AST_STRING_FIELD_EXTENDED. :)
20:30.25cresl1nyeah, it'd be so easy just to register the thread
20:30.34cresl1nit just creates a bit of thread local storage it looks like
20:31.37gtjosepha regex will do the trick though and we can remove the pjproject code altogether.  I probably should have done it that way to begin with.
20:31.40*** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net)
20:33.40putnopvutgtjoseph: I think you did and I pushed for using the PJSIP parser :(
20:33.52gtjosephreally?
20:33.55putnopvutI think
20:34.04putnopvutI think you removed old patches from the ASTERISK issue though.
20:34.17gtjosephprobably.  ah well. :)
20:34.55putnopvut"Does ast_sip_validate_uri_length() have to do its own parsing? Would it be acceptable to just call the built-in PJSIP function pjsip_parse_uri() instead? Or is pjsip_parse_uri() actually where the crash happens?"
20:35.11putnopvutThat's from the issue
20:39.53gtjosephif i had it right the first time, it was an accident. :)
20:45.52filewhilst talking about this I've been simultaneously doing my taxes - YAY!
20:46.01cresl1n#yolo
20:47.58fileI owe less than I thought so that's nice
20:48.05filedrinks won't be on me for a year, though
20:56.39cresl1nIs April 15th tax day in Canada too?
21:01.09fileno
21:01.10file30th
21:01.22fileand business GST/HST is due June 15
21:04.25putnopvutThis year it's the 18th in the US
21:05.03putnopvutBecause the third Friday in April is Emancipation day in DC, which is a holiday, so the deadline got pushed to the 18th.
21:05.51putnopvutOh, actually I'm mistaken. It's not the third Friday, it's straight up the 16th. But since the 16th is a Saturday this year, the observation happens on the day before.
21:29.51fileis anyone actively using gerrit?
21:30.20fileno? SOUNDS GOOD TO ME :d
21:30.21file:D
21:37.13filegtjoseph, well YOU are
21:37.23gtjoseph:)
21:37.28gtjosephlooking to bounce it?
21:37.35fileno
21:37.46fileI'm looking to garbage collect the Asterisk repo
21:37.46seanbrightany of your people a sipp expert?
21:37.51seanbrighterr, you people
21:38.02filebecause I think it desperately needs it
21:38.20gtjosephfile: go for it.  i'm done
21:38.25gtjosephseanbright: maybe
21:38.36fileI'm making a copy right now, I'll run the GC in it to see what happens...
21:38.44rmudgettWe're all those marshmallow peeps in here
21:38.44seanbrighti cannot make sipp send RTP
21:38.51seanbrighti've tried
21:38.54seanbrightso very hard
21:38.59seanbrightbut it just doesn't send
21:39.19filedid you build sipp with support for it?
21:39.41gtjosephSIPp v3.4.1-TLS-PCAP-RTPSTREAM
21:39.45gtjosephis what you need
21:39.55seanbrighti built it
21:40.13seanbrightand didn't specify the "--without-rtpstream" option
21:40.19seanbrightrtp stream appears to be the default
21:41.27seanbrightanything floating around in the testsuite i can reference?
21:42.23filenot... really? there's a few tests which use it
21:42.25filethat's it
21:42.50fileSIPp v3.5.0-rc1-RTPSTREAM built Jun  3 2015, 14:09:18.
21:42.52fileis what I'm using
21:43.42seanbrightSIPp v3.5.1-PCAP-RTPSTREAM built Apr 15 2016, 17:34:29.
21:43.44gtjosephlooks like tests/channels/SIP/rfc2833_dtmf_detect is the only test that plays audio
21:44.00filegtjoseph, I'll let you finish up the back/forth
21:44.05fileI really don't know what's going to happen when I do this
21:44.33rmudgettseanbright: http://sipp.sourceforge.net/doc/reference.html#action_exec
21:44.50fileoh
21:44.52fileI know what I'll do
21:45.24seanbrightrmudgett: yeah... i'm using the <exec rtp_stream="foo.wav"... syntax
21:45.28gtjosephfile: go ahead.  i'm not going to respond again in the short term.
21:45.52rmudgettseanbright: Maybe you should try the play_pcap_audio
21:46.28gtjosephseanbright: http://sipp.sourceforge.net/doc/uac_pcap.xml.html
21:46.41rmudgettI know wdoekes is up on sipp since he has contributed to that project
21:47.00seanbrightyeah, i'll give the pcap stuff a whirl
21:50.55seanbrightok, awesome. now it just segfaults.
21:51.03seanbrightanyway, thanks for the pointers.
21:52.24*** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net)
21:52.24*** mode/#asterisk-dev [+o oej] by ChanServ
22:03.30*** join/#asterisk-dev acidfoo_ (~acidfoo@157.52.14.38)
22:18.52*** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2)
22:33.54fileI may have fixed gerrit
22:58.19*** part/#asterisk-dev kharwell (kharwell@nat/digium/x-bvyaggvjpxqqnpde)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.