| 00:53.27 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 01:22.21 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-98-191-184-213.ph.ph.cox.net) |
| 01:24.22 | *** join/#asterisk-dev `mc (~mc@c-71-235-50-162.hsd1.ct.comcast.net) |
| 02:02.11 | *** join/#asterisk-dev roderickm (~rod@cashmere.thecomplex.com) |
| 02:50.34 | *** join/#asterisk-dev ManxPower (~igcewieli@ip98-183-26-100.pn.at.cox.net) |
| 07:18.42 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 07:23.17 | *** join/#asterisk-dev Guest65603 (~jmls1@77.107.171.82) |
| 07:41.22 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 07:59.43 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 08:10.16 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:57.13 | *** join/#asterisk-dev spditner (~simon@75-119-245-54.dsl.teksavvy.com) |
| 10:05.36 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:05.37 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:57.24 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 10:58.07 | michael_work | hey ppl |
| 10:58.40 | michael_work | as i understand to register on jira i need to leave a message on it? "Not a member? To request an account, please contact your JIRA administrators" |
| 10:58.42 | michael_work | ? |
| 10:59.49 | file | to create an account visit https://signup.asterisk.org/ |
| 10:59.58 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 11:17.13 | *** join/#asterisk-dev oej (~Adium@196.203.216.130) |
| 11:17.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:37.33 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:13.59 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:14.45 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:29.48 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-krhwejfepixyvfpf) |
| 12:29.48 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:08.59 | file | wdoekes, thanks for looking over Kevin's WS client - I've looked at it enough that it turns my brain to mush |
| 13:10.32 | *** join/#asterisk-dev Victor_Yure (~victor_yu@unaffiliated/victoryure/x-837844) |
| 13:22.11 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 13:28.23 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-kdwhlsoegbmsneqv) |
| 13:28.23 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:36.30 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 13:36.30 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 13:55.23 | file | down south back roads dust clouds in the air! |
| 13:57.16 | pabelanger | I just seen it in passing, but it will allow asterisk to connect out to an ARI application, right? |
| 13:57.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uwpklwfnkjngyjet) |
| 13:58.54 | file | pabelanger, not presently no. |
| 14:02.07 | pabelanger | OIC |
| 14:03.29 | mjordan | it's the first step in that direction. Can't have ARI connect out to an application without a websocket client! |
| 14:05.24 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 14:05.24 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 14:06.23 | pabelanger | * Qwell (north@pdpc/sponsor/digium/Qwell) has joined #asterisk-dev |
| 14:06.30 | pabelanger | Qwell, need your tagline updated :) |
| 14:07.46 | file | mjordan, ARI tunneled over AMI! |
| 14:08.22 | mjordan | ew |
| 14:20.34 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 14:20.34 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 14:36.52 | *** join/#asterisk-dev X-Rob (sid14615@gateway/web/irccloud.com/x-tmcfbijhzhbvekvo) |
| 14:38.20 | *** join/#asterisk-dev wedhorn` (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 14:46.25 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 14:46.25 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:03.02 | wdoekes | file: I know the feeling. |
| 15:03.21 | file | I've got a feelinggggggg that today's gonna be a good day |
| 15:13.04 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 15:13.04 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 15:21.41 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-kzxzocomkdlgmyqu) |
| 15:28.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:28.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:37.15 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:39.37 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:39.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:14.16 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:17.16 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:17.55 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:25.56 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:28.58 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:34.23 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-59-195.user.veloxzone.com.br) |
| 17:35.04 | anonymouz666 | is it possible to specificy a URI option through Dial string? I mean, wanna add transport=TCP in SIP INVITE URI |
| 17:35.58 | file | for what channel driver? |
| 17:36.41 | anonymouz666 | SIP |
| 17:36.58 | file | chan_sip? |
| 17:37.01 | anonymouz666 | chan_sip, correct |
| 17:37.26 | anonymouz666 | . /* If custom URI options have been provided, append them */ |
| 17:39.24 | anonymouz666 | INVITE sip:Anonymous@frontend-itpv01.corp.local:5068 SIP/2.0. - wanna make like this: INVITE sip:Anonymous@frontend-itpv01.corp.local:5068;transport=XXX SIP/2.0. |
| 17:39.29 | anonymouz666 | using the sip_get_transport() |
| 17:39.33 | anonymouz666 | outgoing invite |
| 17:40.06 | anonymouz666 | I was reading the source and saw a URI custom option, maybe it is what I am looking for |
| 17:40.47 | mjordan | that doesn't mean that Asterisk will actually look at your request URI option and use it |
| 17:41.06 | mjordan | so you may be woefully disappointed in what actually occurs. |
| 17:41.10 | *** join/#asterisk-dev oej (~Adium@41.226.25.149) |
| 17:41.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:41.54 | anonymouz666 | yeah I know, it is just to make the other equipment happy |
| 17:42.19 | anonymouz666 | that talks with asterisk through SIP |
| 17:43.10 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip24-251-34-116.ph.ph.cox.net) |
| 17:51.01 | anonymouz666 | oej: do you know an easy way to add a param to SIP INVITE URI? like ;transport=XXX |
| 17:51.19 | anonymouz666 | I saw the user=phone example, but from what I understand it add the param to FROM or TO headers. |
| 17:51.58 | anonymouz666 | nice to know the ! in the dial string that allows you to specify some headers, it was hidden for me :-) |
| 17:52.24 | pabelanger | sounds like you need a proxy, if you want to manipulate the headers |
| 17:52.38 | anonymouz666 | trying to avoid that, is just a simple param |
| 17:53.22 | file | adding that does not change the actual transport itself |
| 17:53.29 | anonymouz666 | correct. |
| 17:53.40 | anonymouz666 | but is just to make the other end happy |
| 17:53.48 | file | doesn't mean it will work in the end... |
| 17:53.53 | Qwell | Why not just...use tcp? |
| 17:53.55 | mjordan | what if the other end replies to the INVITE over TCP? |
| 17:54.09 | anonymouz666 | tcp is being used |
| 17:55.12 | mjordan | in that case, have you tried SIP_URI_OPTIONS? |
| 17:55.38 | anonymouz666 | huhuhu how smart I am! I simple channel var! |
| 17:55.51 | anonymouz666 | that is what I am looking for! |
| 17:56.57 | anonymouz666 | thank you! |
| 17:57.28 | mjordan | np |
| 18:00.58 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 18:00.58 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:01.36 | oej | Hmm. Transport params are seldom sent in a rURI |
| 18:02.35 | oej | The question is what it means. It will not control chan_sip |
| 18:02.49 | oej | So you can easily have chan_sip send a message over UDP with ;transport=tls |
| 18:02.54 | oej | Which is confusing |
| 18:03.12 | oej | But hey, it's doable. |
| 18:46.11 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:04.21 | *** join/#asterisk-dev X-Rob (sid14615@unaffiliated/x-rob) |
| 19:04.21 | *** join/#asterisk-dev X-Rob (sid14615@gateway/web/irccloud.com/x-tmcfbijhzhbvekvo) |
| 19:27.58 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-bhhdkqhgcrzrrqsb) |
| 19:28.48 | *** join/#asterisk-dev kodomo (~gregor@92.63.174.119) |
| 19:30.25 | kodomo | hi folks - would anyone be willing to help me debug a weird TLS problem I've got when making calls with a SNOM M9 on asterisk 1.8.27.0 ? |
| 19:34.56 | leifmadsen | I researched TLS on Asterisk 1.8 and I ran away screaming from the open issues |
| 19:35.08 | leifmadsen | moved all that shizz to the proxy layer |
| 19:35.17 | leifmadsen | that doesn't help you here, but just thought I'd let you know :) |
| 19:36.24 | kodomo | leifmadsen: unfortunately I'm holding a chan_skype license which I'm not willing to throw away... so moving away from 1.8 is something I'd rather avoid :-| |
| 19:36.41 | leifmadsen | that still works? odd :) |
| 19:36.50 | leifmadsen | didn't say you had to move away from 1.8 |
| 19:36.55 | leifmadsen | just that we didn't put TLS on the Asterisk side of things |
| 19:37.13 | leifmadsen | there were too many open issues that looked scary |
| 19:37.27 | *** join/#asterisk-dev Alex_Bkash (cbdf5c49@gateway/web/freenode/ip.203.223.92.73) |
| 19:39.24 | kodomo | leifmadsen: No, I didn't move away from 1.8 |
| 19:39.34 | leifmadsen | I didn't ask if you did |
| 19:39.51 | leifmadsen | I'm also using 1.8 in like... 200 call servers |
| 19:40.54 | kodomo | w.r.t. chan_skype: it worked a few months ago before I had to switch servers... ever since I didn't get around to configure my VM with the 'licensed' eth devices (lack of time), but I haven't given up, yet... :P |
| 19:41.16 | kodomo | that's why I'm clinging to 1.8 |
| 19:41.37 | kodomo | Do I understand you correctly, and TLS is working much better in later versions? |
| 19:41.51 | mjordan | TLS in chan_sip is what it is |
| 19:42.12 | kodomo | It doesn't look to me as if noone dared touch the code... it changed quite a bit since 1.8.7 ... |
| 19:42.30 | mjordan | lots of things changed. There were several security vulnerabilities. |
| 19:42.58 | leifmadsen | I'm just saying, there were enough open issues that I dared not use TLS on the asterisk side |
| 19:43.01 | leifmadsen | I pushed it to the edge |
| 19:43.20 | leifmadsen | whether it is better in later versions? I did not research that much. |
| 19:43.44 | mjordan | leifmadsen: certificate chains now work |
| 19:43.46 | mjordan | that's about it |
| 19:43.54 | leifmadsen | better than nothing :) |
| 19:43.57 | Marquis42 | Indeed |
| 19:43.59 | mjordan | some bug fixes |
| 19:43.59 | leifmadsen | it was the stability I was more concerned with :) |
| 19:44.12 | leifmadsen | but honestly, certificate management is a bitch enough with border proxies |
| 19:44.15 | mjordan | the big one - that I'm aware of - is the large packet issue |
| 19:44.21 | mjordan | fixing that is ... a lot of work. |
| 19:44.25 | leifmadsen | aye |
| 19:44.36 | leifmadsen | I figure the less work I need to make asterisk do, the happier it'll be |
| 19:44.48 | mjordan | to whit: https://reviewboard.asterisk.org/r/2783/ |
| 19:45.23 | mjordan | FWIW, the example in the OpenSSL book about how to properly handle non-blocking I/O in OpenSSL is ~5 pages long. Complete insanity. |
| 19:45.46 | kodomo | ok... I never had stability issues with my TLS setup... but then again, it's a small scale (i.e., private use only) system... |
| 19:45.57 | mjordan | Equivalent roughly to charging up a hill into machine gun fire with nothing but a rusty fork |
| 19:46.08 | kodomo | anyway - I don't think my problem's related to the large-packet-issue |
| 19:46.15 | kodomo | for two reasons: |
| 19:46.37 | mjordan | komodo: possibly not, but if not, then I'm not aware of any other open issues that sound like yours that are TLS related. I could be wrong. But anything I'm doing is guess work |
| 19:47.05 | mjordan | So, if the workaround patches on those issues didn't solve anything (did you try them?) then you'll have to debug the code to find out why Asterisk is breaking the connection or otherwise misbehaving |
| 19:47.24 | kodomo | 1) I've enabled _only_ GSM and enabled the short message versions (so the packets should be sufficiently small) |
| 19:47.58 | kodomo | 2) the message exchanges for the first and second call look exactly the same (from the snom perspective) |
| 19:49.10 | kodomo | By now, I've also realized that (nondeterministically) some calls seem to go through when I try often enough |
| 19:49.47 | kodomo | The only call which always works - however - is the first one after SNOM restart (mind: not asterisk <- this is the thing confusing me the most) |
| 19:51.13 | kodomo | So in summary: 1st call goes through (everything looks fine), 2nd call looks the same msg-wise, but fails (asterisk cuts the connection after the ACK or 2nd INVITE - I can't really tell)... subsequent calls may or may not work... |
| 19:52.21 | kodomo | There's one thing I had to modify in order to get asterisk cooperate with the snom in the beginning... and maybe that's part of the problem (can't tell, since I don't have an overview over the TLS part) |
| 19:54.22 | kodomo | that is: I disabled the 'continue' in sdp_crypto.c in the if (lifetime) clause |
| 19:54.44 | kodomo | (I'm aware that this is a potential security issue) |
| 19:55.39 | kodomo | I didn't find any other source code parts relying on the lifetime variable, so I didn't assume that the system would get into an invalid state |
| 20:04.15 | *** join/#asterisk-dev oej (~Adium@41.226.25.149) |
| 20:04.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:11.32 | kodomo | ok... so I see that 'cleanup' is being called beause a sip_tls_read failed |
| 20:11.57 | kodomo | afterwards, I do get a SSL_shutdown() with error code 5 |
| 20:13.07 | kodomo | (again... this is odd... If I'm not mistaken, this means that the other side (snom) has terminated the connection... but tcpdump clearly shows the asterisk machine sending the FIN... not the other way around) |
| 20:16.09 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:19.45 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 20:22.49 | kodomo | darn! |
| 20:23.05 | kodomo | It must be a race condition of some sort |
| 20:23.22 | kodomo | I've isolated the spot where asterisk goes into cleanup |
| 20:23.46 | kodomo | I've inserted another attempt to read + a respective if-clause |
| 20:23.58 | kodomo | (thereby double-checking, so to say) |
| 20:24.03 | kodomo | and now it works... |
| 20:24.24 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:24.32 | kodomo | ...not the most satisfying way to solve things :-| |
| 20:40.19 | kodomo | mjordan: leifmadsen: race condition, it seems... |
| 20:46.05 | kodomo | ...indeed ... no more failed read attempts after adding uslee(100); before the sip_tls_read |
| 20:46.13 | kodomo | :-| |
| 20:46.32 | *** part/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-bhhdkqhgcrzrrqsb) |
| 20:57.29 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:00.06 | kodomo | if anyone cares: the issue was a race condition in sip_tls_read in line 3031 of channels/chan_sip.c of asterisk 1.8.27.0 :-| |
| 21:01.45 | mjordan | interesting |
| 21:01.50 | mjordan | a race between what two things? |
| 21:10.18 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:10.26 | kodomo | mjordan: to be honest: beats me... the TLS handling source code is not exactly straightforward, and I'm not familiar with the ssl library... I'd be willing to invest a couple of minutes trying to figure it out |
| 21:11.45 | mjordan | well, what made you think it was a race condition? |
| 21:12.29 | kodomo | mjordan: the fact that the problem disappeared after insertion of a usleep(100); in front of the sip_tls_read ? ;) |
| 21:12.54 | kodomo | ...so waiting solves the issue... usually that's a pretty sure sign of a race condition ;) |
| 21:18.12 | kodomo | mjordan: If I get this correctly, then the source codes uses non-blocking reads for TLS... and regularly polls if new data is available... I'd figure it takes some time preparing the data for reading while the flag that there's data available is already raised |
| 21:19.08 | kodomo | ...maybe some artifact from buffering? |
| 21:25.11 | kodomo | mjordan: the part is enclosed by an 'if (fds[0].revents...' ; revents is only reset to 0 in the asterisk source code... so I reckon it's set in an external library (guessing: the ssl library) when there's data |
| 21:25.59 | kodomo | mjordan: ...this is certainly done in a separate threat <- between this presumed thread and the sip_tcp_helper_thread |
| 21:29.28 | kodomo | actually it's not the ssl library... but above you'll find |
| 21:29.30 | kodomo | <PROTECTED> |
| 21:29.35 | kodomo | <PROTECTED> |
| 21:29.50 | kodomo | with (from /usr/include/bits/poll.h): |
| 21:29.57 | kodomo | #define POLLIN 0x001 /* There is data to read. */ |
| 21:29.57 | kodomo | #define POLLPRI 0x002 /* There is urgent data to read. */ |
| 21:32.24 | kodomo | anyhow... bailing out... I don't know why the author went for this approach to handle TLS traffic |
| 21:47.02 | wdoekes | kodomo: I don't think it's a matter of preparing data for reading. I suspect there was SSL data but no actual data, so a read turns up blank. |
| 21:47.14 | wdoekes | there have been reports of issues like that in the past. |
| 21:57.15 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:01.01 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:01.01 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:25.24 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:25.48 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:36.04 | kodomo | wdoekes: possible... although surprising that there's real data a 100ms later in all cases up to now... |
| 22:36.24 | kodomo | wdoekes: what would you have me do to check? |
| 22:37.43 | Tim_Toady | 100ms are enough to send 5 rtp packets with voice data (assuming the packetization is at 20ms as it usually is) |
| 22:38.06 | kodomo | Tim_Toady: the rtp packets don't go over the tls connection |
| 22:38.42 | Tim_Toady | ah crap, u re right, we are talking about sip :) |
| 22:54.21 | *** join/#asterisk-dev Alex_Bkash (cbdf5c49@gateway/web/freenode/ip.203.223.92.73) |
| 23:10.55 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-uwpklwfnkjngyjet) |
| 23:11.36 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |