| 00:57.12 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 00:57.12 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 01:19.34 | *** join/#asterisk-dev suneye (~atcmmi@116.25.194.34) |
| 02:32.24 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:32.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:04.02 | coreyf1513 | i'm writing a testsuite using PluggableModules.Originator similar to tests/channels/SIP/path, does anyone know of a way to control how many times it originates or which scenarios it applies to? |
| 05:50.00 | *** join/#asterisk-dev suneye (~atcmmi@119.139.61.138) |
| 06:47.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 07:02.10 | *** join/#asterisk-dev phillcz (~fjenicek@kwf.kerio.cz) |
| 07:02.53 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c169:5a93:a33:769) |
| 07:05.31 | phillcz | Hi everyone, |
| 07:05.31 | phillcz | I was wondering in chan_sip, when parsing the Contact header in a reply to SIP REGISTER, why it is expected, that the header expires= has a semicolon at the end? |
| 07:05.31 | phillcz | The code: |
| 07:05.31 | phillcz | tmptmp = strcasestr(contact, "expires="); |
| 07:05.31 | phillcz | if (tmptmp) { |
| 07:05.32 | phillcz | if (sscanf(tmptmp + 8, "%30d;", &expires) != 1) |
| 07:05.32 | phillcz | expires = 0; |
| 07:05.33 | phillcz | } |
| 07:05.33 | phillcz | I am experiencing issues with several providers, which send "Contact: <sip:123456@178.33.22.11:5060;transport=UDP>;expires=1198". The value 1198 doesn't get parsed and the default is used instead. |
| 07:05.34 | phillcz | Is it a bug or am I missing something? |
| 07:06.54 | wdoekes | phillcz: at a quick glance, I'd say bug |
| 07:13.08 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 07:13.29 | wdoekes | quickest way to get that fixed is to put up a patch on reviewboard |
| 07:13.43 | phillcz | Yep, I'll file a report. Thanks |
| 07:35.02 | *** join/#asterisk-dev danjenkins (~danjenkin@62.254.236.250) |
| 07:41.21 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 07:49.08 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:55.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 07:55.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 07:58.47 | *** join/#asterisk-dev spditner (~simon@206-248-134-225.dsl.teksavvy.com) |
| 07:58.57 | *** part/#asterisk-dev phillcz (~fjenicek@kwf.kerio.cz) |
| 08:03.36 | *** join/#asterisk-dev phillcz (~fjenicek@kwf.kerio.cz) |
| 08:17.39 | *** join/#asterisk-dev atcmmi (~atcmmi@116.25.194.34) |
| 08:28.21 | *** join/#asterisk-dev danjenkins (~danjenkin@62.254.236.250) |
| 08:37.41 | *** part/#asterisk-dev phillcz (~fjenicek@kwf.kerio.cz) |
| 08:54.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 08:55.28 | *** join/#asterisk-dev danjenkins (~danjenkin@62.254.236.250) |
| 09:11.39 | *** join/#asterisk-dev danjenkins_ (~danjenkin@62.254.236.250) |
| 09:23.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 09:25.56 | *** join/#asterisk-dev danjenkins_ (~danjenkin@62.254.236.250) |
| 09:47.57 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:47.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:56.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 10:09.38 | *** join/#asterisk-dev danjenkins (~danjenkin@62.254.236.250) |
| 10:24.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 10:51.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.60.234) |
| 10:52.34 | *** join/#asterisk-dev Greenlight (wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 11:22.03 | *** join/#asterisk-dev oej (~Adium@67.217.137.66) |
| 11:22.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:41.05 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:42.03 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 11:42.47 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:02.33 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 12:03.59 | *** join/#asterisk-dev danjenkins_ (~danjenkin@213.106.234.250) |
| 12:12.10 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:12.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:49.56 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 13:00.19 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 13:08.34 | mjordan | coreyf1513: off to work so I'll answer when I get there - but Originator currently just does a single origination. It has several mechanisms to control how it gets triggered: on AMI connection; on a SIPp scenario start; or on a particular AMI event. If you need it to originate multiple times, you could configure an Originator instance to trigger off of an AMI event (such as a UserEvent) - each reception of that event will cause another call to be spawn |
| 13:09.17 | mjordan | coreyf1513: you can also use a pluggable module more than once - so you can have one configuration of an Originator (foo) that spawns a call to foo on AMI connection; another one (bar?) that spawns a call based on an event, etc. |
| 13:09.32 | mjordan | heh, should have said "answer more" |
| 13:09.37 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:12.54 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 13:15.28 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 13:37.52 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yoluhrwcjuaqfwjq) |
| 13:37.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:48.06 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-uajfahyrfwkabapp) |
| 13:48.06 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:53.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:53.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:53.06 | coreyf1513 | mjordan: thanks, I actually figured out to use the pluggable module twice, and added trigger: 'ami_connect' so each originate run's once for the test instead of per scenario. it seems to work, though i'm not sure if ami_connect happens before or after sipp scenario's start |
| 14:04.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lpmfrvdlspofyues) |
| 14:04.26 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qnijilucakiaeosp) |
| 14:06.17 | mjordan | coreyf1513: it will happen before |
| 14:07.50 | mjordan | coreyf1513: hm. Actually I'm wrong. Had to go double check - but AMI connect also triggers the start of the SIPp scenarios |
| 14:08.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.55.54) |
| 14:08.47 | mjordan | so the order will be based on the order of registered event handlers, which means the order will be SIPp scenario processes are spawned, then the pluggable modules will get called. |
| 14:16.21 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-etatdgpkmialcyvr) |
| 14:23.06 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 14:23.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.55.54) |
| 14:39.38 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.116.90) |
| 14:42.09 | *** join/#asterisk-dev danjenkins_ (~danjenkin@213.106.234.250) |
| 15:31.56 | opticron | file, regarding outbound registration: the second REGISTER with the authentication response to the 401 has different values for the "response" attribute on subsequent runs of the test |
| 15:32.08 | opticron | but the information contained in the 401 is static |
| 15:32.19 | opticron | across test runs |
| 15:32.20 | file | interestin' |
| 15:33.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.55.54) |
| 15:34.13 | opticron | double checks what actually goes into the nonce |
| 15:34.33 | opticron | user, realm, password for HA1 |
| 15:34.40 | opticron | method, digest UR for HA2 |
| 15:34.57 | opticron | and HA1, nonce, HA2 for the response |
| 15:35.01 | opticron | *URI |
| 15:35.43 | file | unless cnonce/qop are present. |
| 15:36.10 | opticron | right |
| 15:36.43 | opticron | in any case, this exact same SIPp scenario run against chan_sip produces a static response (not changing across test runs) |
| 15:37.15 | opticron | so all I'm really going after here is that they behave differently |
| 15:37.30 | opticron | and trying to verify if one of them is wrong to do so |
| 15:37.42 | file | pastebin the signaling |
| 15:39.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.55.54) |
| 15:41.13 | opticron | http://pastebin.com/WhJKAVkc |
| 15:43.01 | file | aye certainly looks fine |
| 15:44.24 | putnopvut | opticron: is PJSIP receiving the REGISTER or sending the REGISTER? |
| 15:44.34 | file | sending it |
| 15:45.13 | putnopvut | ah, well ne'ermind. I was going to say that when we are the challenger of authentication credentials, part of our nonce calculation involves the current system time. |
| 15:45.26 | file | aye |
| 15:45.33 | file | runs off briefly |
| 15:47.49 | opticron | putnopvut, all the information provided in the 401 is static |
| 15:47.57 | opticron | as provided by a SIPp scenario file |
| 15:53.35 | putnopvut | opticron: is it just the response that changes between tests or do other fields in the re-REGISTER change? |
| 15:59.57 | opticron | branch, tags, call ID, seqno all vary |
| 16:00.12 | opticron | everything else is static |
| 16:00.36 | tzafrir | Any idea what's the origin of formats/msgsm.h ? |
| 16:01.18 | tzafrir | I see it is practically unchanged since 0.1.1 . I just wonder if it is covered by the GPL license of Asterisk |
| 16:02.33 | putnopvut | opticron: if you're willing to recompile PJSIP, you can go to pjsip/src/pjsip/sip_auth_client.c, and redefine AUTH_TRACE_ at the top of the file to actually route the message to the PJ_LOG. If you have res_pjsip_log_forwarder.so loaded in Asterisk, then that should show up as a debug level 3 message. |
| 16:03.00 | putnopvut | That way, you'll have some insight into what PJSIP is calculating for various values when creating its Authorization header. |
| 16:05.42 | opticron | can do |
| 16:05.56 | opticron | I've already recompiled a few times to add debugging |
| 16:07.24 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 16:07.48 | mjordan | tzafrir: no idea where that came from, other than the e-mail address on the top. |
| 16:10.18 | *** part/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 16:18.24 | file | MOAR DEBUGGING |
| 16:23.21 | *** join/#asterisk-dev danjenkins (~danjenkin@213.106.234.250) |
| 16:29.15 | tzafrir | slightly off-topic: what would it take to get some prompts currently in the -extra set into the -core set (specifically: ones used by FreePBX)? |
| 16:30.56 | tzafrir | We'll probably be recording them on our own anyway, but getting them included in the core set would probably be slightly more proper |
| 16:35.31 | mjordan | tzafrir: very little effort. Just make a list and let us know. We can take a look at them and evaluate. |
| 16:38.24 | rmeyerriecks | tzafrir: Are you going to Astricon this year? |
| 16:38.31 | tzafrir | rmeyerriecks, yes |
| 16:40.01 | rmeyerriecks | tzafrir: yay! sruffell /\ |
| 16:40.13 | sruffell | sweet |
| 16:40.40 | rmeyerriecks | We need to make some dahdi shirts or something |
| 16:40.55 | tm1000 | rmeyerriecks: Ill take one |
| 16:43.42 | mjordan | Uncle Russ wants you: Team DAHDI |
| 16:45.14 | file | DAHDI Task Force |
| 16:50.50 | mjordan | http://www.cafepress.com/cp/customize/product2.aspx?from=CustomDesigner&number=968711621 |
| 16:52.57 | tm1000 | The DAHDis |
| 16:53.27 | tm1000 | mjordan: lol |
| 17:01.00 | rmeyerriecks | mjordan: hahaha |
| 17:25.58 | *** join/#asterisk-dev danjenkins_ (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 17:39.59 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 17:59.21 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qphsclcqyuvnnoyd) |
| 18:05.14 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:07.29 | tzafrir | As part of the license check I also verified with Mark Roberts (the author of markdsp, used in e.g. frame.[ch]), that his code had no issues. |
| 18:07.45 | tzafrir | He wrote back and told me that there were no issues. |
| 18:08.06 | tzafrir | Today he wrote back and reported non-free code, though |
| 18:08.28 | seanbright | ruh roh |
| 18:08.58 | tzafrir | Specifically, he was concerned about the premature exit in utils/stereorize.c |
| 18:09.12 | tzafrir | So there you have it: free as in malloc |
| 18:10.15 | mjordan | heh. |
| 18:11.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.42) |
| 18:13.56 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:14.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.42) |
| 18:16.35 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:19.29 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:22.56 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 18:38.29 | *** join/#asterisk-dev otherwiseguy (~otherwise@63.92.246.169) |
| 19:18.47 | mjordan | jrose_atDigium: you hit one of the CDR assertions when parking a call with a local channel, right? |
| 19:22.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.220) |
| 20:01.44 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 20:22.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.60) |
| 20:25.15 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.60) |
| 20:26.06 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.60) |
| 20:28.38 | jrose_atDigium | mjordan: Yes |
| 20:28.54 | jrose_atDigium | Let me grab what it was real quick |
| 20:30.20 | jrose_atDigium | Ok, it works like this... |
| 20:30.54 | jrose_atDigium | If I originate a parking extension to a SIP channel and then forward that call to another channel, base_process_bridge_leave has a failed assertion at line 1351 |
| 20:30.59 | jrose_atDigium | mjordan: ^ |
| 20:31.03 | jrose_atDigium | cdr.c |
| 20:31.28 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:31.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:36.56 | mjordan | got it. Richard showed me the assertion. |
| 20:36.56 | mjordan | thanks |
| 21:08.49 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:59.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.60) |
| 22:22.08 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-yoluhrwcjuaqfwjq) |
| 23:47.24 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |