| 01:57.00 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 02:14.34 | *** join/#asterisk tsal (~tsal@i59F4A376.versanet.de) |
| 03:49.09 | *** join/#asterisk gschanuel (~gschanuel@201.89.125.40) |
| 03:50.12 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 03:51.02 | *** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |
| 03:51.16 | *** join/#asterisk ketas- (~ketas@0011-0000-0000-0000-d7dc-830e-07d0-2001.dyn.estpak.ee) |
| 03:51.58 | *** join/#asterisk rwb1 (~Thunderbi@65.183.138.202) |
| 03:52.07 | *** join/#asterisk Gugge_ (gugge@guggemand.dk) |
| 03:53.43 | *** join/#asterisk fling_ (~fling@fsf/member/fling) |
| 03:55.01 | *** join/#asterisk javi404_ (~quassel@unaffiliated/javi404) |
| 03:55.27 | *** join/#asterisk ashka (~postmaste@pdpc/supporter/active/ashka) |
| 03:57.03 | *** join/#asterisk electronic_eel_ (~quassel@electroniceel.org) |
| 03:58.40 | *** join/#asterisk dobson` (~dobson@static.38.6.217.95.clients.your-server.de) |
| 03:59.37 | *** join/#asterisk smkelly (~smkelly@mykonos.smkelly.org) |
| 04:00.47 | *** join/#asterisk tris (tristan@camel.ethereal.net) |
| 04:01.00 | *** join/#asterisk leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 04:01.01 | *** mode/#asterisk [+o leifmadsen] by ChanServ |
| 04:01.45 | *** join/#asterisk tsal (~tsal@i59F4A376.versanet.de) |
| 04:02.17 | *** join/#asterisk Posterdati (~posterdat@host-87-21-221-219.retail.telecomitalia.it) |
| 04:02.19 | *** join/#asterisk mrtnt (~martint@martint.data.ee) |
| 04:02.40 | *** join/#asterisk mmlj4 (~mmlj4@ip174-69-111-70.no.no.cox.net) |
| 04:04.41 | *** join/#asterisk TriJetScud (~TriJetScu@23.172.144.5) |
| 04:10.30 | *** join/#asterisk sibiria (~sibiria@c-774571d5.013-383-79736414.bbcust.telenor.se) |
| 05:05.31 | *** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
| 05:12.48 | *** join/#asterisk gschanuel (~gschanuel@201.89.125.40) |
| 05:21.39 | *** join/#asterisk gregf (~gregf@unaffiliated/gregf) |
| 05:23.50 | gregf | Hi, I switched my setup over to transport-tls tonight, and my client is connecting. I see my asterisk server is registered to my provider over tls. When i try to dial any extensions though I get the following error. 200: Couldn't negotiate stream 0:audio-0:audio:sendrecv (nothing) |
| 05:27.59 | gregf | well if I comment out media_encryption=sdes from my pjsip.conf it connects just fine, but there's no audio. |
| 05:32.53 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 05:37.50 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 05:52.18 | *** join/#asterisk maristo (~maristo@109.174.114.229) |
| 08:11.15 | *** join/#asterisk joako (~joako@opensuse/member/joak0) |
| 08:15.05 | *** join/#asterisk BakaKuna (~Thunderbi@2a02-a446-ae46-1-6632-418b-1ca9-b0f4.fixed6.kpn.net) |
| 08:36.59 | wyre | what's the proper location for en sounds? |
| 08:37.17 | wyre | I've got a clean install of asterisk and the folder is not in /var/lib/asterisk |
| 08:37.27 | wyre | but /usr/share/asterisk ð¤ |
| 08:49.31 | *** join/#asterisk mrtnt (~martint@martint.data.ee) |
| 08:57.29 | *** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com) |
| 09:05.22 | wyre | apparently the /var/lib/asterisk/sounds/en is not owned by the asterisk package in debian ð¤ |
| 09:05.40 | wyre | are those sounds generated in the first start of asterisk? |
| 09:12.55 | *** join/#asterisk stux|work (stux@endurance.xzibition.com) |
| 09:15.32 | *** join/#asterisk stux16777216Away (stux2@grid9.quadspeedi.net) |
| 10:11.22 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 11:37.37 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00d7dadc80b2148f9c.dip0.t-ipconnect.de) |
| 12:12.58 | *** join/#asterisk BakaKuna (~Thunderbi@86-89-65-191.fixed.kpn.net) |
| 13:19.34 | Kobaz | weird issue all of a sudden... yealink phones aren't trusting a godaddy starfield G2 cert provisioning server |
| 13:19.38 | Kobaz | and it's not expired |
| 13:38.15 | Samot | The certs aren't working for what reason? |
| 13:41.12 | *** join/#asterisk sibiria (~sibiria@unaffiliated/sibiria) |
| 13:44.20 | *** join/#asterisk retentiveboy (~retentive@c-24-125-16-104.hsd1.ga.comcast.net) |
| 13:46.11 | *** join/#asterisk kerouac[m] (kerouacmat@gateway/shell/matrix.org/x-wiqdgfzlobphtxwg) |
| 13:54.21 | *** join/#asterisk rwb (~Thunderbi@65.183.138.202) |
| 14:00.46 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:05.10 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:08.08 | nbjoerg | Kobaz: do you have any intermediate certs? |
| 14:17.08 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 14:27.59 | *** join/#asterisk craigify (craigify@iceland.sdf.org) |
| 14:30.45 | Kobaz | yeah |
| 14:30.57 | Kobaz | Samot: syslog on the yealink says like cert validation error, or something like that |
| 14:31.08 | Kobaz | i had to reboot my pc, i don't have the exact log entry but I can get that again |
| 14:31.17 | Kobaz | yeah i have all the certs in the chain server-side |
| 14:32.50 | Kobaz | nbjoerg: yes on intermediates |
| 14:33.02 | Kobaz | they all expire waaaay in the future too, and the phone has the correct time |
| 14:33.12 | Samot | Hold on |
| 14:33.17 | Kobaz | holds |
| 14:33.26 | Samot | Are these self gen? |
| 14:33.33 | Kobaz | nope, godaddy starfield g2 |
| 14:33.46 | Samot | What is waay in the future? |
| 14:33.58 | Kobaz | like uhh 2033 is the earliest expire |
| 14:34.03 | Samot | Uhhh |
| 14:34.11 | Samot | They changed rules |
| 14:34.13 | Kobaz | versus your normal like 1-2 year certs |
| 14:34.33 | Kobaz | these are signing key expirations |
| 14:35.02 | Kobaz | and I wouldn't think a yealink phone that's had the same firmware for... months, isn't going to suddenly follow new rules |
| 14:35.15 | Kobaz | maybe?... depends on implementation, but that would be odd |
| 14:35.33 | Kobaz | lemme dump you the cert chain |
| 14:36.53 | Samot | I was talking about TLS |
| 14:38.01 | Kobaz | right but, whatever firmware is in use, i would think has tls rules at the time it was written/build |
| 14:38.17 | Kobaz | but anyway, lemme get the chain real quick |
| 14:40.12 | Samot | What firmware? |
| 14:40.33 | Kobaz | good question |
| 14:43.11 | Kobaz | [Yealink SIP-T46G 28.81.0.110 |
| 14:43.42 | Kobaz | So it's definitely a bit old. It's been sitting around a while |
| 14:44.08 | Kobaz | I know older firmware might have trust issues... but I'm (pretty sure?) that this was working on this server |
| 14:45.15 | Samot | Well that's an EOL model these days. |
| 14:46.31 | Kobaz | for sure |
| 14:46.42 | Kobaz | one that's alive and well out in the real world, in plenty of places |
| 14:50.41 | Samot | OK. |
| 14:50.49 | Samot | So 28.81.0.110 is from 2017 |
| 14:50.51 | Kobaz | imma update the firmware and see |
| 14:50.53 | Kobaz | I know |
| 14:51.07 | Samot | Considering that TLS was overhauled in 2020, I'd say you might be out of date. |
| 14:51.09 | Kobaz | Just curious if anyone else has had similar issues with ssl certs going untrusted |
| 14:51.17 | Kobaz | Yeah, fair enough |
| 14:51.22 | Samot | So sure, the firmware supported TLS as it was in 2017. |
| 14:51.29 | Samot | Yes. |
| 14:51.42 | Samot | *A lot* did. In 2020. |
| 14:51.57 | Samot | For all the same reasons, the CA's didn't have the proper updates. |
| 14:52.09 | Samot | Old protocols like SSL and TLS 1.0 where removed. |
| 14:52.13 | Kobaz | right |
| 14:52.24 | Samot | Any CA's still supporting them got hit. |
| 14:52.53 | Samot | TLS certs are no longer being considered valid past 36 months. |
| 14:53.12 | Samot | So having 10 year certs isn't going to be a thing. |
| 14:53.31 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 14:53.35 | Kobaz | yeah makes sense |
| 14:54.17 | Samot | So the T-46G went EOL on 4/1/2020, it still gets one year of updates. |
| 14:55.31 | sibiria | the limit isn't even 36 months now. most browsers are now complaining on certs older than 13 months |
| 14:57.20 | sibiria | probably just a matter of time before various ssl/tls libraries tags along |
| 14:57.41 | Samot | Well there's no point in SSL anymore. |
| 14:57.58 | Samot | If you're still running things over SSL then you really don't care about security. |
| 15:00.49 | nbjoerg | sibiria: unlikely to be ever enforced by default on tls layer |
| 15:01.07 | nbjoerg | sibiria: since TLS is used in a lot of environments with completely different constraints than the web |
| 15:01.33 | sibiria | no but through the verification, e.g. when using libssl |
| 15:06.04 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-htoohyvnogqcnvwv) |
| 15:06.04 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:07.27 | nbjoerg | sibiria: it will at most be an option |
| 15:07.54 | nbjoerg | the existing moves are already harmful enough for embedded environments... |
| 15:08.35 | sibiria | it's a bit of a bitch for internal environments and agreements yes |
| 15:09.12 | Samot | No one will ever be satisified. |
| 15:09.43 | sibiria | bound to happen when one or two big orgs. make decisions for open standards that affect everyone |
| 15:09.45 | *** join/#asterisk igcewieling (~ewieling@199.27.202.86) |
| 15:10.01 | Samot | I'm not sure one or two big orgs made that decision. |
| 15:10.13 | Samot | It was also something that was pretty well communicated. |
| 15:10.19 | sibiria | apple and google were the largest driving forces behind it |
| 15:10.25 | sibiria | mozilla foundation tagging along as third |
| 15:10.43 | nbjoerg | well, yes. that's like 90% of the web browsers |
| 15:10.45 | Samot | My point still stands. |
| 15:10.56 | Samot | No one will ever be satisified. |
| 15:11.03 | Samot | Which I find amusing. |
| 15:13.25 | igcewieling | are they going to break web browsing or something? |
| 15:13.51 | nbjoerg | igcewieling: have you followed web browser development the last decade at all |
| 15:14.31 | Kobaz | Samot: what part of SSL shows someone doesn't care about security? |
| 15:14.35 | Kobaz | *citation needed |
| 15:15.09 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:15.22 | sibiria | igcewieling: they're making it more secure by limiting ssl/tls certificates' acceptable life span, with the risk that non web browsing also using ssl/tls may get some mud splashed on them |
| 15:15.24 | igcewieling | nbjoerg: not really. |
| 15:15.28 | Samot | Kobaz: SSL is dead. |
| 15:15.34 | igcewieling | Ah, that. |
| 15:15.41 | Samot | Kobaz: SSL was replaced with TLS. Nothing supports SSL or TLS 1.0 anymore. |
| 15:16.00 | Kobaz | Oh, you're just talking about the low level |
| 15:16.03 | igcewieling | If it breaks web sites, people will use something else. |
| 15:16.15 | seanbright | saying SSL is fine |
| 15:16.20 | seanbright | everyone knows that this is |
| 15:16.23 | nbjoerg | Samot: not true, but also not relevant |
| 15:16.24 | seanbright | stop it. |
| 15:16.46 | sibiria | ssl will be the colloquial term for many years more. just accept it :) |
| 15:16.48 | Kobaz | SSl/TLS you're just being needlessly pedantic |
| 15:16.49 | nbjoerg | "No current software uses SSLv3 or TLS 1.0 by default" |
| 15:17.17 | Kobaz | there's nothing wrong with TLS 1.3 in terms of security (that we know of). I' |
| 15:17.18 | nbjoerg | as usual, there are still valid cases for the legacy support in special cases |
| 15:17.25 | Kobaz | I'm sure the NSA has something to say about that |
| 15:17.37 | *** join/#asterisk gschanuel (~gschanuel@201.89.125.40) |
| 15:17.43 | Samot | OK. |
| 15:18.03 | nbjoerg | and no, the protocol deficits are not necessarily relevant for those cases either |
| 15:18.07 | Samot | So this all started because of something "weird" with certs not working anymore. |
| 15:18.11 | igcewieling | So, has anyone seen stir/shaken headers on calls arriving from carriers? |
| 15:18.29 | Samot | Turns out it's most likely due to the fact that the firemware is almost 4 years old and in the last 18 months changes have happened. |
| 15:18.40 | Samot | Such as SSL protocol being dead and using TLS |
| 15:18.45 | Samot | Because they are different. |
| 15:19.30 | seanbright | right, they are different |
| 15:19.48 | nbjoerg | try enabling TLSv1 |
| 15:19.57 | nbjoerg | that would be the easiest to test? |
| 15:24.55 | Samot | Kobaz: Did you update the firmware? |
| 15:25.57 | nbjoerg | I mean if the provisioning server no longer supports a common TLS version with the phone, that could happen without a firmware update |
| 15:26.06 | nbjoerg | and error reporting of phones often is depressing |
| 15:26.33 | Kobaz | not yet, working on adding buttons for a new hire in our office |
| 15:27.00 | Samot | nbjoerg: Yealink has also updated their default trusted CA list in their firmware in the last 4 years. |
| 15:27.20 | Samot | nbjoerg: This could be an issue with changes on one side and the phone lacking updates to support the changes on its side. |
| 15:27.38 | Kobaz | Right |
| 15:28.43 | nbjoerg | yeah |
| 15:29.09 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-ymwmfpcfsnmzeima) |
| 15:29.10 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:30.09 | sibiria | when using call files and hangup handlers i'm running into a little quirk when the other end isn't picking up and the call expires, i.e. when the call file's WaitTime is reached and asterisk gives up by sending a CANCEL |
| 15:30.40 | sibiria | normally this would send asterisk to the "failed" extension and set REASON to 3 (remote end ringing, or so) |
| 15:31.13 | sibiria | but with a hangup handler, REASON is never set, and i cannot find an easy way in the handler to find out that the call actually expired without pick-up |
| 15:31.39 | sibiria | the hangup handler happens *before* asterisk sends CANCEL and gets a response to that |
| 15:32.17 | sibiria | so asterisk considers the call "Normal Clearing" instead, with the last known SIP response for the channel being 18x ringing/progress/forwarded etc. |
| 15:33.48 | Kobaz | you need to put the hangup handler on the outgoing channel to get the cause code |
| 15:34.20 | sibiria | it is set on the outbound channel, from within the call file. the handler's context happens just fine |
| 15:34.23 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 15:34.37 | Kobaz | then you should be able to get the cause then |
| 15:34.40 | Kobaz | once that channel hangs up |
| 15:34.46 | Kobaz | https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause |
| 15:35.45 | sibiria | the cause for an outbound call that times out is always 0 |
| 15:36.03 | sibiria | and this can happen in more cases than just an expired call attempts |
| 15:36.12 | Kobaz | paste your log? |
| 15:36.30 | sibiria | yeah, hold on a minute |
| 15:37.00 | igcewieling | if all else fails you could put a wait, or even wait, check to see if hangupcause is set, if not ,wait some more, repeat. |
| 15:37.48 | igcewieling | When I did that with my call files, I realized I was setting the hangup handler on the wrong channel. |
| 15:37.52 | sibiria | the "failed" extension was handy for these particular cases, but i have to omit it because with a hangup handler in place the handler will happen first, then the "failed" extension afterwards. a bit messy |
| 15:38.00 | nbjoerg | btw, does someone here have a ticket account for snom by chance? |
| 15:38.21 | igcewieling | sibiria: try not using a hanguphandler and do it in the failed extension? |
| 15:38.59 | sibiria | igcewieling: this comes with its own share of problems. migrating towards hangup handler for good reasons |
| 15:39.08 | Kobaz | sibiria: so your issue is... on cancel, you don't know it's a cancel cause? |
| 15:39.13 | Kobaz | DIALSTATUS will tell you that |
| 15:39.27 | igcewieling | sibiria: hanguphandlers are good. call files are weird and don't always fit within the dialplan model you use. |
| 15:39.42 | Kobaz | you'll need to check DIALSTATUS on the original caller channel before checking the hangup cause |
| 15:40.10 | sibiria | Kobaz: correct. the call is sent to the handler *before* asterisk cancels it, so inside the handler asterisk still only knows cause 0 / Normal Clearing / 180 Ringing (or 183 Session Progress etc.) |
| 15:40.23 | Kobaz | ew |
| 15:40.36 | Kobaz | that doesn't seem right |
| 15:40.42 | sibiria | i would insist that it's better the handler is called *after* asterisk cancelled the call |
| 15:40.47 | igcewieling | Didn't Kobaz write hanguphandlers? Blame him. 8-| |
| 15:40.54 | Kobaz | i didn't write the final version |
| 15:41.02 | Samot | LOL |
| 15:41.09 | Kobaz | :P |
| 15:41.13 | sibiria | must be that sean bright guy, or that man with the crazy hats |
| 15:41.34 | file | I didn't touch 'em |
| 15:41.38 | Kobaz | It was redone to use autoservice so it can stay alive for more than one line of dialplan |
| 15:41.44 | Kobaz | and some other changes |
| 15:42.14 | Kobaz | sibiria: I can look into that |
| 15:42.58 | igcewieling | sibiria: are you calling the channel directly in your .call file or are you using dialplan on both legs of the call? |
| 15:43.09 | igcewieling | i.e. Local/ |
| 15:43.30 | Kobaz | Yeah you still didn't show you log |
| 15:43.40 | sibiria | Kobaz: this is a slightly older ast version, 16.15.0. still gathering the log |
| 15:43.54 | file | it wouldn't surprise me if it's because of the more asynchronous nature of PJSIP |
| 15:43.56 | sibiria | yes the call file contains the channel to call |
| 15:44.12 | sibiria | not jumping into a context which in turn calls Dial() |
| 15:47.13 | Kobaz | why does having a slightly older asterisk version make gathering the log take longer? |
| 16:07.46 | sibiria | juggling work tasks s'all, sorry for the delay |
| 16:09.17 | sibiria | Kobaz: http://paste.debian.net/hidden/e4d88450/ |
| 16:10.16 | sibiria | the interesting part is the channel variable dump on lines 110 to 130 or so |
| 16:12.54 | sibiria | "pbx_spool.c: Call failed to go through, reason (3) Remote end Ringing" |
| 16:12.59 | sibiria | this part is teasing |
| 16:13.13 | sibiria | this data is not available on the channel |
| 16:13.29 | sibiria | it is when using the "failed" extension |
| 16:13.37 | Samot | So this is a timeout? |
| 16:13.48 | Samot | The other end didnt answer? |
| 16:13.50 | sibiria | yes the outbound call expires since nothing is picking up |
| 16:14.26 | sibiria | hangup handler is invoked *before* asterisk tells the remote to CANCEL, so the handler hasn't got an accurate view of what actually happened |
| 16:14.46 | sibiria | or well, it has a partial view of it... |
| 16:14.54 | Samot | And what is the dialstatus? |
| 16:21.49 | sibiria | DIALSTATUS isn't available unless using Dial() - in my case the destination is set directly in the call file |
| 16:25.09 | igcewieling | Have you considered using Local/? |
| 16:26.22 | sibiria | for now i'm just looking at temporary work-arounds |
| 16:27.05 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda0057872916dc050a4f.dip0.t-ipconnect.de) |
| 16:29.31 | sibiria | i wonder if there's a potential risk for a race condition of sorts here. say that the handler is taking a very long time, and the channel is answered in the middle of it |
| 16:29.48 | sibiria | before asterisk gets going with CANCEL etc. |
| 16:31.01 | file | PJSIP would terminate the call |
| 16:31.53 | sibiria | but would it first pick up and bridge the channel? i.e. a prank call |
| 16:32.13 | sibiria | before hanging up once it's done with the hangup handler |
| 16:35.03 | file | no. |
| 16:35.57 | sibiria | so it ignores any SIP responses coming in during the handler |
| 16:36.13 | sibiria | or just instantly knee-jerks with something |
| 16:36.44 | Samot | So this is timing out because you set a timer right? |
| 16:37.15 | sibiria | yes, it uses WaitTime in the call file |
| 16:37.37 | file | I don't think it's exactly doing what you think it's doing |
| 16:37.44 | file | it is hanging up, but PJSIP is done asynchronously |
| 16:37.52 | file | it gets queued up as a task to do |
| 16:38.06 | file | (that's what I suspect) |
| 16:38.43 | sibiria | yes i figured that the log portions may also be dumped out of order, but nevertheless the handler has no idea that we've sent off CANCEL, and the last thing it knows is 183 Sess Prog |
| 16:38.53 | file | either way, it will be hung up |
| 16:39.02 | file | even if it got an answer in there, it would be hung up |
| 16:39.42 | sibiria | yeah, but what happens between getting an answer and exiting the handler? |
| 16:39.49 | sibiria | say the handler takes 6 seconds to finalize |
| 16:40.12 | sibiria | will pjsip reciprocate on SIP responses while asterisk is in the handler? |
| 16:40.14 | file | I haven't looked closely, either it would quickly get hung up, or the channel would stay up and then be hung up after 6 seconds |
| 16:40.15 | file | yes. |
| 16:41.28 | sibiria | ok. well, either way, i feel that the handler shouldn't definitely not happen until asterisk shot off CANCEL etc. |
| 16:41.33 | sibiria | should* |
| 16:41.42 | Kobaz | sibiria: k checking now |
| 16:42.31 | Kobaz | sibiria: the handler could take an hour, pjsip is done at that point |
| 16:42.59 | Kobaz | but the dialog could stay open until the handler is done |
| 16:43.28 | Kobaz | you can test that pretty easily, put a Wait(10) in the handler, Wait(20) and see if the cancel waits that long |
| 16:43.58 | file | it will, because according to le reading of the code the channel driver isn't told to hang up until after |
| 16:44.03 | sibiria | it does |
| 16:44.09 | sibiria | i already tested it |
| 16:44.28 | Kobaz | yeah based on the log, it does look like that |
| 16:44.35 | Kobaz | so you tested it for much longer intervals? |
| 16:44.41 | sibiria | several seconds |
| 17:06.45 | Kobaz | Hungup channel detected, running agi in dead mode. |
| 17:06.51 | Kobaz | pjsip CANCEL should be kicking off here |
| 17:07.20 | Kobaz | or even prior |
| 17:24.02 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 17:26.49 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 17:29.27 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda009ace00fc35072318.dip0.t-ipconnect.de) |
| 17:50.28 | *** join/#asterisk murdick (~murdick@noon.nas.net) |
| 17:54.31 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 18:06.44 | *** join/#asterisk driz (~driz@joinsg.net) |
| 18:34.37 | *** part/#asterisk SenseiSama (~whoa@ool-ad0244e9.dyn.optonline.net) |
| 18:44.48 | *** join/#asterisk BakaKuna (~Thunderbi@86-89-65-191.fixed.kpn.net) |
| 18:57.05 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 19:11.39 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda009ace00fc35072318.dip0.t-ipconnect.de) |
| 19:20.11 | *** join/#asterisk eXistenZ (~pectic@bzq-79-183-200-96.red.bezeqint.net) |
| 19:23.45 | sibiria | want me to try wrap that up in a bug report on the ol' jira? |
| 19:23.52 | sibiria | (the premature hangup handler thing) |
| 19:23.55 | Kobaz | yeah sure |
| 19:56.30 | Samot | Question: Does this happen with non-callfile generated calls? |
| 20:23.49 | sibiria | not sure, haven't tried it by originating calls over the console or so |
| 20:28.36 | Samot | That would probably be a helpful troubleshooting data point or two. |
| 20:28.51 | Samot | Does console do this? Does dialing from phone to phone do this? |
| 20:32.04 | Samot | Plus it is using the last reply received. Since you are canceling the call with a dialer timeout, there are not more replies. |
| 20:33.17 | sibiria | that's sort of the problem. the last response of a cancelled call should be 200 Canceling or 487 Request Terminated |
| 20:33.31 | Samot | Different request |
| 20:33.39 | Samot | A cancel is a new request |
| 20:35.05 | Samot | Then cancel will get back a 200 ACK |
| 20:35.23 | sibiria | same cseq = same request? |
| 20:36.14 | Samot | BYE and CANCEL are new SIP requests. |
| 20:36.24 | Samot | Separate of the INVITE |
| 20:37.08 | sibiria | ah ok, they are in the same cseq but different method |
| 20:37.16 | Samot | Right |
| 20:37.24 | Samot | They are related |
| 20:37.54 | Samot | So the Invite received a 183 as its last reply |
| 20:38.30 | Samot | If early media wasn't happening it would have been a 100 Trying |
| 20:39.05 | Samot | But you stopped the call. There is no reply needed to tell you the reason. |
| 20:39.55 | sibiria | asterisk stopped the call, but i cannot know why at this point |
| 20:40.02 | sibiria | because i can't see the last SIP response of the channel itself |
| 20:40.08 | Samot | Your time expired |
| 20:40.26 | Samot | How long is the wait? |
| 20:40.40 | sibiria | 25 seconds |
| 20:41.08 | Samot | And that is how long it takes for the cancel to happen? |
| 20:42.41 | sibiria | yes. the total time of the request can be used to infer what has happened, but ideally the channel should, at hangup, contain the last known SIP response of the channel, but this isn't the case here with hangup handlers |
| 20:43.14 | Samot | That is the last known response for the INVITE |
| 20:43.46 | sibiria | that's less relevant i think. the handler is tied to the channel, not the invitation |
| 20:44.03 | sibiria | in my case, the channel is still busy and conversing after the hangup handler has run its course |
| 20:44.06 | sibiria | it's premature |
| 20:44.31 | Samot | Right which means it doesn't care that it is PJSIP? |
| 20:44.37 | Samot | The channel hung up |
| 20:44.53 | Samot | If it was an IAX channel you hangup handler would run at the same point. |
| 20:45.05 | Samot | No SIP replies. |
| 20:45.26 | Samot | DAHDi, same thing. |
| 20:45.35 | sibiria | i would guess the same problem would happen with chan_sip, but i haven't tried |
| 20:45.46 | Samot | What about the others? |
| 20:45.52 | Samot | You're focused on a SIP reply |
| 20:46.08 | sibiria | this is an "app to phone" application. no handsets invovled |
| 20:46.21 | Samot | I understand that. |
| 20:46.26 | Samot | But a hangup is a hangup. |
| 20:46.34 | Samot | Thus hangup handlers are executed if set. |
| 20:46.47 | Samot | Doesn't matter if it's PJSIP, SIP, IAX, Local, etc. |
| 20:47.26 | Samot | It can't give you the reply to the CANCEL until the CANCEL is fired. |
| 20:47.30 | sibiria | the bigger point with this problem is that it's only possibly to try infer why the hangup handler was executed, since it has an incomplete view of the channel |
| 20:47.36 | Samot | The CANCEL can't be fired until the channel is hung up. |
| 20:47.58 | sibiria | failed/h extension has a complete view, because they happen last, after CANCEL |
| 20:48.14 | sibiria | no need to guess what happened, as the channel variables show the full picture |
| 20:48.38 | sibiria | they will contain the last known SIP response of the channel, the correct HANGUPCAUSE etc. etc. |
| 20:49.16 | sibiria | if the channel is answered and then hung up normally, the hangup handler will execute correctly at the end |
| 20:49.47 | sibiria | it's jsut this case, when the call file expires, where it seems to be invoked prematurely and end up presenting a half-baked set of channel variables |
| 20:50.27 | igcewieling | I suspect most people use Local/ channels |
| 20:52.18 | sibiria | at least in my view an unanswered call should be viewed as 487 / Q.850 = 19 or so |
| 20:52.52 | sibiria | not "Normal Call Clearing" |
| 21:03.06 | Samot | So what is this calling? |
| 21:03.11 | Samot | An actual phone? |
| 21:04.49 | Samot | Or more to the point, does the destination have its own timeout? |
| 21:05.48 | sibiria | it's calling a phone on the PSTN, a phone which can ring for much longer than 25s |
| 21:05.55 | Samot | OK |
| 21:05.59 | Samot | Does it have a timeout? |
| 21:06.14 | Samot | If I was to call it directly would it time out at 45s and hang up on me? |
| 21:06.19 | Samot | Or would it send me some place? |
| 21:07.00 | sibiria | it hangs up on the attempt, and that case won't shoot the hangup handler off prematurely |
| 21:07.12 | Samot | But you would get back a 408 reply. |
| 21:07.12 | sibiria | so far i've only been able to see this happen when the call file times out |
| 21:07.15 | Samot | User Timeout |
| 21:07.30 | sibiria | yes |
| 21:07.40 | Samot | OK so you're looking at this wrong. |
| 21:07.59 | Samot | In all the scenarios is which this works for you, the other side is telling you something. |
| 21:08.09 | Samot | You're looking for responses from them. |
| 21:08.32 | Samot | When it fails, it is because you told the other side "I'm done." |
| 21:08.58 | Samot | So now the other side is responding with "OK, we accept you're done" |
| 21:09.40 | sibiria | yes this is technically correct, but the disposition of this case would better be "NO ANSWER" instead of "FAILED" combined with "Normal Clearing". those two contradict eachother, and the latter is the opposite of the reality of the invitation |
| 21:09.40 | Samot | By telling the other side you are done, you triggered a CANCEL which will not give you a response back on your INVITE |
| 21:09.48 | Samot | Which is what 4XX replies do. |
| 21:09.54 | Samot | They are replying to the INVITE |
| 21:10.07 | Samot | No |
| 21:10.12 | Samot | It wouldn't be a NO ANSWER |
| 21:10.27 | Samot | You didn't give the other side the option of answering. |
| 21:11.43 | Samot | If I butt dial my mom and realize it 3 seconds in, I hangup. |
| 21:12.18 | Samot | She still could pick up that call before it was told to cancel. She'll get nothing because the call was terminated.. |
| 21:12.27 | Samot | That wasn't a case of NO ANSWER |
| 21:12.31 | Samot | That was a termination. |
| 21:12.42 | Samot | Which is a 487 and 4XX are failures. |
| 21:13.23 | Samot | Well users responses..but in this cause..it was a failure in the sense you made a bad call. |
| 21:13.38 | Samot | Or you terminated the call because it didn't answer fast enough. |
| 21:14.01 | Samot | Are you getting HANGUPCAUSE 0 on anything else? |
| 21:15.21 | sibiria | can't say off the top of my head, not at work right now so i can't access call logs to see specific cases where the cause is 0 |
| 21:15.57 | Samot | Based on the logging you showed it looks like channel.c is destroying the channel before the pjsip_sessions are doing the cleanup of the dialog. |
| 21:19.19 | Samot | Oh wait. I was looking at the 200 OK to the cancelling. |
| 21:20.56 | *** join/#asterisk hvxgr (~wl2v_usrn@n7s.org) |
| 21:24.03 | Samot | Are you mapping the sip response in your agi script? |
| 21:25.45 | sibiria | it's the unaltered "tech" response from HANGUPCAUSE() |
| 21:33.19 | *** join/#asterisk SSlater (~simon@203.214.65.15) |
| 21:36.28 | Samot | Yeah, the hangup handlers are being executed when the channel is hung up. |
| 21:38.37 | Samot | And at the time of the hangup that 183 Session Progress was the last SIP code reply on the channel. |
| 21:38.43 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda009ace00fc35072318.dip0.t-ipconnect.de) |
| 21:56.41 | *** join/#asterisk electronic_eel (~quassel@electroniceel.org) |
| 22:04.34 | Kobaz | yeah the hangup handler is running prior to complete teardown |
| 22:04.44 | Kobaz | and at this point you don't have the cause |
| 22:04.51 | Kobaz | As far as I gather, on this |
| 22:13.27 | Samot | Well, the cause is there. |
| 22:14.27 | Samot | Dial() stopped because 25 seconds elapsed before another response was received. |
| 22:14.52 | Samot | The last SIP Code is 1XX which is a provisional response. |
| 22:14.59 | Samot | Not an error. |
| 22:15.10 | Samot | Not a 408 timeout. |
| 22:15.54 | Samot | Not getting a 1XX response = other side not responding at all. |
| 22:16.51 | sibiria | there is no cause at all. it's just that asterisk produces an integral response, so it will be 0 rather than null/empty |
| 22:16.53 | Samot | So all the data provided at the end of the call points to no one answered in 25s but they were alerted. |
| 22:17.57 | Samot | In the world of hangup cause codes 0 is the null/empty |
| 22:18.14 | Samot | "Can't relate this to something, it's unknown" |
| 22:18.30 | Samot | Which is would null/empty would mean as well. |
| 22:18.35 | Samot | what* |
| 22:21.34 | Samot | The way I see is your call logic is looking for a non-1XX user response which the 25 second timer doesn't allow for because the destination takes longer to respond with a 408 or an answer. |
| 22:29.49 | sibiria | it assumes some amount of coherence. failed/h extensions will happen when the channel is finalized, and the "ast" hangup cause at that point will report what actually happened |
| 22:30.08 | sibiria | with a hangup handler, it happens before the channel is finalized, and the "ast" hangup cause will be "normal clearing" |
| 22:31.00 | sibiria | it's both inconsistent and erroneous |
| 22:53.54 | Samot | hangup handlers can happen before or have h |
| 22:54.00 | Samot | s/have/after/ |
| 22:54.50 | igcewieling | Which is why you shouldn't use both. |
| 23:03.04 | Samot | How are you setting the hangup handlers? |
| 23:10.12 | sibiria | directly in the call file, through Setvar |
| 23:10.54 | sibiria | i.e. Setvar: CHANNEL(hangup_handler_push)=etc |
| 23:44.40 | *** join/#asterisk Cyrillax (~Cyrillax@unaffiliated/cyrillax) |