| 00:28.02 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 01:13.35 | *** join/#asterisk tsal (~tsal@87.122.234.79) |
| 01:15.56 | *** join/#asterisk Typhon (~Typhon@dslb-088-066-100-118.088.066.pools.vodafone-ip.de) |
| 01:33.28 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 01:48.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 01:48.34 | *** join/#asterisk tsal (~tsal@i59F5F574.versanet.de) |
| 02:14.36 | *** join/#asterisk Typhon (~Typhon@dslb-088-067-128-095.088.067.pools.vodafone-ip.de) |
| 02:41.42 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 02:43.40 | *** join/#asterisk NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 02:48.17 | *** join/#asterisk _Posterdati_ (~posterdat@host-79-36-198-96.retail.telecomitalia.it) |
| 02:49.28 | *** join/#asterisk tsal (~tsal@i59F4A272.versanet.de) |
| 03:15.11 | *** join/#asterisk Typhon (~Typhon@dslb-088-067-128-234.088.067.pools.vodafone-ip.de) |
| 03:21.22 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 03:42.41 | *** join/#asterisk electronic_eel (~quassel@213.240.182.236) |
| 04:34.08 | *** join/#asterisk jmordica_ (uid18332@gateway/web/irccloud.com/x-trceniekexmtgvbe) |
| 04:42.20 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 04:42.20 | *** join/#asterisk maximCH (~maximCH@mail.swill.org) |
| 04:42.20 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 04:42.20 | *** join/#asterisk sbingner (~sam@phathack/sbingner) |
| 04:42.20 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
| 04:48.41 | *** join/#asterisk tsal (~tsal@i59F4A272.versanet.de) |
| 05:18.05 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 05:48.46 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 06:30.41 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 07:15.25 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-wlbvtbzulywbudks) |
| 07:19.47 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 07:35.16 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 07:51.37 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 09:04.09 | *** join/#asterisk akp55 (~akp55@c-73-148-15-31.hsd1.va.comcast.net) |
| 09:16.56 | *** join/#asterisk defsdoor (~Andrew@cpc120650-sutt6-2-0-cust43.19-1.cable.virginm.net) |
| 09:30.00 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 12:10.37 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 12:15.16 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:01.28 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 14:06.43 | sibiria | is it a known quirk that haungup cause codes don't map symmetrically in both directions between two asterisk setups? |
| 14:07.18 | Samot | Pardon? |
| 14:08.46 | sibiria | in the context of using HANGUPCAUSE() to explain the disposition, i mean |
| 14:09.16 | Samot | You mean between two systems? |
| 14:09.30 | Samot | You want to know why A and B have different codes between? |
| 14:09.39 | sibiria | e.g. when we Hangup(20) ("Subscriber absent") Asterisk sends "480/Temp unavailable" and q.850 cause 20, but on the Asterisk instance receiving this response HANGUPCAUSE(,ast) reports this as "User alerting, no answer" |
| 14:10.15 | sibiria | which sounds like cause code 19, "No answer from user (user alerted)" |
| 14:10.27 | Samot | OK so PBX A makes a call out.. |
| 14:10.34 | Samot | The device making the call got a 480 reply |
| 14:10.46 | Samot | And PBX B actually sent back user alerted. |
| 14:10.57 | Samot | Is that what you are saying? |
| 14:11.49 | sibiria | asterisk A calls asterisk B, and receives 480 + Q.850 20 |
| 14:11.53 | Samot | Because 480 maps to Hangup Cause Code 19 |
| 14:12.04 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 14:12.55 | Samot | Asterisk is mapping the SIP Code not the Q.850 code |
| 14:12.57 | Samot | Because it's SIP |
| 14:12.59 | sibiria | but asterisk A using HANGUPCAUSE(,ast) determines that response as "User alerting, no answer" |
| 14:13.06 | Samot | Because that's a 480 |
| 14:13.18 | sibiria | asterisk A sees the correct cause code. it sees 20 |
| 14:13.26 | sibiria | but 480 seems to take priority |
| 14:13.29 | Samot | Show a call. |
| 14:13.43 | Samot | Again, one is a SIP code and one is a q.850 code |
| 14:13.46 | Samot | You're using SIP |
| 14:13.56 | Samot | Of course the SIP code is going to be checked first. |
| 14:14.35 | sibiria | it's not entirely a problem, as we can map the returned cause code to the larger cause code list. it's just that asterisk's internal mapping through HANGUPCAUSE(,ast) seems a bit off |
| 14:15.28 | Samot | Well I would need to see a call to see what is actually being done on all sides. |
| 14:15.35 | Samot | Since this is a B2BUA. |
| 14:16.09 | Samot | The channel making the call to PBX B may not be sending the same thing back to the channel of the device that requested it |
| 14:19.39 | sibiria | this is what we're seeing directly on the asterisks' ends when enumerating the channel's data |
| 14:20.19 | sibiria | seems it's only a case of HANGUPCAUSE(,ast) being quirky |
| 14:20.55 | Samot | Like I said, I can't say much without seeing what is actually happening. |
| 14:21.50 | Samot | I just replied to a thread in FreePBX about something like this and all the people missed one line output that had the "mystery cause code" no one could figure out what it was there |
| 14:30.07 | sibiria | https://pastebin.com/raw/BX4eqmst |
| 14:30.14 | Kobaz | Samot: hangup codes regularly get lost in translation |
| 14:30.25 | sibiria | i think it's just a case of HANGUPCAUSE(,ast) locking onto the SIP response code, rather than the cause code |
| 14:30.27 | Kobaz | sibiria: ^^ |
| 14:30.44 | Kobaz | Asterisk has to convert the q codes to SIP |
| 14:30.53 | Kobaz | which don't match exactly |
| 14:30.59 | Kobaz | I used to have this problem all the time |
| 14:31.07 | Samot | Because its f'in sip |
| 14:31.17 | Samot | I only said that twice |
| 14:31.19 | sibiria | i sort of assumed HANGUPCAUSE(,ast) would use the cause code when available |
| 14:31.26 | Kobaz | when available |
| 14:31.32 | sibiria | it is available |
| 14:31.38 | Kobaz | well your Q.850 code is only available on the other asterisk that got it |
| 14:31.42 | sibiria | HANGUPCAUSE() just doesn't care for it |
| 14:32.10 | Kobaz | When it goes SIP over the wire unless you do something special, all bets are off you'll get a mirror of the hangup cause |
| 14:32.36 | sibiria | B responds 20, A sees 20 and makes 20 available in the channel data |
| 14:32.58 | sibiria | HANGUPCAUSE(,ast) <- does not care for channel's cause code |
| 14:33.09 | Kobaz | On which asterisk? |
| 14:33.23 | Kobaz | The one with the Q code or the one receiving the sip call |
| 14:33.43 | sibiria | A receives the cause code, A has it in its channel data |
| 14:33.51 | Kobaz | Right |
| 14:34.08 | sibiria | 15:32 <sibiria> HANGUPCAUSE(,ast) <- does not care for its channel's cause code, only its SIP response code |
| 14:34.20 | Kobaz | Also on the A box? |
| 14:34.28 | sibiria | it's just the A box i'm concerned about here |
| 14:34.44 | Kobaz | Oh, why bring in the B box to the picture at all then |
| 14:34.58 | sibiria | someone wanted to know what it responded |
| 14:35.02 | Kobaz | ah |
| 14:35.02 | Kobaz | okay |
| 14:35.06 | Kobaz | well, i would ignore that |
| 14:35.22 | Kobaz | if stuff's not working on A, focus on A |
| 14:35.28 | sibiria | the SIP parts are just fine. it's all about HANGUPCAUSE() being quirky |
| 14:35.45 | Kobaz | and sorry, jumping in the middle here as usual |
| 14:35.54 | Kobaz | but.. what's your tech HANGUPCAUSE at the same time? |
| 14:36.13 | sibiria | the tech response has the actual SIP response |
| 14:36.36 | Kobaz | but you're missing the Q.850 |
| 14:36.39 | Kobaz | right? |
| 14:36.42 | sibiria | no, it's there |
| 14:36.50 | Kobaz | SO it's there in tech, but not in ast |
| 14:37.08 | sibiria | HANGUPCAUSE() ast response seems to be produced *only* from the SIP code response. the cause response appears to be ignored |
| 14:37.18 | sibiria | which i find confusing |
| 14:38.04 | Kobaz | that does seem odd |
| 14:38.06 | Kobaz | what version? |
| 14:38.10 | sibiria | 16.15.0 |
| 14:38.37 | sibiria | how HANGUPCAUSE(,ast) behaves isn't spelled-out black on white in the documentation |
| 14:38.45 | sibiria | but my assumption about it felt natural |
| 14:39.14 | sibiria | seems reasonable that it would go for the cause code first to produce the "ast" response |
| 14:39.33 | sibiria | and use the SIP response code as a fallback |
| 14:39.36 | Kobaz | documentation, sorry about that |
| 14:39.41 | Kobaz | It's lacking for sure |
| 14:39.56 | Kobaz | The bane of existance |
| 14:40.11 | Kobaz | So... Since 16 is a stable long term |
| 14:40.25 | Kobaz | Put in a bug report, for the odd HANGUPCAUSE mismatch |
| 14:40.30 | Kobaz | give lots of examples (issues.asterisk.org) |
| 14:40.41 | sibiria | i wonder if the behavior is perhaps intentional |
| 14:40.53 | sibiria | file and seanbright look like two dudes who might know |
| 14:41.06 | Samot | Can we see a call? |
| 14:41.06 | Kobaz | I doubt 16.x will get a fix like that, core response codes changing in minor point releases is frowned upon |
| 14:41.25 | Kobaz | but that could very well be a fix for 19. |
| 14:41.26 | sibiria | Samot: my pastebin above shows the invitation and response |
| 14:41.35 | Samot | Sorry missed it. Let me look. |
| 14:42.01 | Kobaz | sibiria: Hangup tracking has been a problem for many years |
| 14:42.08 | sibiria | it's indeed a bit "hairy" |
| 14:42.16 | Kobaz | oej's project, I think it was 'whohungup' was thousands of lines of changes |
| 14:42.24 | Kobaz | to track why and where a channel hung up |
| 14:43.07 | Samot | Oh wait. |
| 14:43.10 | Samot | That's a different header. |
| 14:43.11 | Kobaz | it never got merged |
| 14:43.26 | Samot | You want to pull from the Reason header. |
| 14:43.33 | Kobaz | sibiria: also don't use pastebin, it's got ads |
| 14:43.46 | Kobaz | sibiria: dpaste or a bajillion others are much sleeker |
| 14:44.03 | Samot | The q.850 code is in the Reason header |
| 14:44.09 | Samot | That's your problem. |
| 14:44.28 | sibiria | the hangup cause code is also available in the ${HANGUPCAUSE} channel variable |
| 14:44.39 | sibiria | no need to read out any of the headers |
| 14:44.46 | Kobaz | right |
| 14:44.55 | Kobaz | Samot: the issue is HANGUPCAUSE is fuzzy-matching here |
| 14:45.07 | Samot | When PBX B sends back the 480 reply |
| 14:45.11 | Kobaz | for the 'ast' option |
| 14:45.15 | Samot | PBX A isn't looking at the REASON header. |
| 14:45.20 | Samot | It's looking at the SIP code. |
| 14:45.33 | sibiria | yes it seems that's what HANGUPCAUSE(,ast) is doing |
| 14:45.34 | Samot | Which it then maps to something on its end. |
| 14:45.43 | Kobaz | ${HANGUPCAUSE} = 20, but HANGUPCAUSE(..ast) is showing 19 |
| 14:45.56 | Samot | Because it is irrelevant that the other side is Asterisk. |
| 14:45.59 | Kobaz | sibiria: that's your problem, right? |
| 14:46.10 | Samot | Or that there is a q.850 code being sent in the Reason header. |
| 14:46.28 | Samot | I think you're focusing on the wrong thing. |
| 14:46.46 | Samot | PBX A doesn't care that PBX B is 1) a PBX or 2) It's Asterisk. |
| 14:46.46 | sibiria | Kobaz: correct. my assumption was that HANGUPCAUSE(,ast) will interpret first from the hangup cause code, otherwise from the SIP response |
| 14:47.17 | Kobaz | Samot: Asterisk is mapping 19 for.... what reason? |
| 14:47.20 | sibiria | yes it's entirely irrelevant what PBX B is. i never stated this had any impact on anything |
| 14:47.24 | Samot | JFC. |
| 14:47.31 | Samot | Because 480 = Cause Code 19 |
| 14:47.32 | Kobaz | Samot: that's his question |
| 14:47.41 | Samot | So PBX A is getting a 480 and thus using Cause Code 19 |
| 14:47.53 | Samot | Despite the code 20 being in the Reason header sent back from PBX B. |
| 14:47.55 | Samot | That's why. |
| 14:48.09 | Samot | Ignore the q.850 code in the reply. |
| 14:48.16 | Samot | It's irrelevant for this. |
| 14:48.20 | sibiria | the confusion is why HANGUPCAUSE() is mapping from SIP response when it has a Q.850 hangup cause code right infront of it |
| 14:48.22 | Samot | Only the SIP code matters. |
| 14:48.30 | Samot | BECAUSE IT'S IN THE REASON HEADER |
| 14:48.42 | Samot | Asterisk isn't LOOKING THERE |
| 14:48.46 | Kobaz | Samot: it's just wack though |
| 14:48.53 | Samot | It's SIP |
| 14:49.00 | Samot | q.850 does not apply |
| 14:49.07 | Kobaz | Samot: Cause code 20 for HANGUPCAUSE. you would think would cascade down to HANGUPCAUSE,ast |
| 14:49.16 | Samot | This is like saying "Why is my PRI using 8.850 and not the SIP code?" |
| 14:49.22 | Kobaz | Samot: dude, it makes perfect sense that TECH is 480 |
| 14:49.25 | Samot | It's a DIFFERENT SYSTEM |
| 14:49.28 | Samot | FFS. |
| 14:49.29 | Kobaz | It's a tech specific cause code |
| 14:49.35 | file | hush all |
| 14:49.38 | Samot | PBX B is generating the code 20 on ITS side |
| 14:49.45 | Samot | Sending back a 480 SIP Code |
| 14:49.50 | Kobaz | Samot: stop talking about PBX B |
| 14:49.52 | Samot | That is what PBX A cares about. |
| 14:50.00 | Samot | Well that's where the cause code 20 is coming from |
| 14:50.06 | sibiria | file: save me |
| 14:50.09 | Samot | That is what generates it |
| 14:50.15 | sibiria | help/hilfe/hjälp etc. |
| 14:50.16 | Samot | Naw, you're fine. |
| 14:50.23 | Samot | I'm done repeating myself. |
| 14:50.28 | file | sibiria: https://github.com/asterisk/asterisk/blob/16/res/res_pjsip_rfc3326.c#L87 is where it is supposed to examine the Reason header in a response and apply it as the hangupcause on the channel itself |
| 14:50.40 | Kobaz | file: thank you |
| 14:50.59 | sibiria | so the behavior is intended after all |
| 14:50.59 | file | you can add a log message and see if it's executing, if it is then a later handler could be overwriting the mapping |
| 14:51.18 | Kobaz | sibiria: that's not what he said |
| 14:51.26 | Kobaz | sibiria: monkey up the code and see if it's working as intended |
| 14:51.28 | Samot | I think a later handler is overriding it. |
| 14:51.35 | file | the module is supposed to read the Reason header, extract the Q.850 cause code, and set it as the hangup cause |
| 14:51.50 | sibiria | which it does |
| 14:51.57 | Samot | Oh |
| 14:51.58 | Kobaz | it sets HANGUPCAUSE |
| 14:51.59 | Samot | BTW. |
| 14:52.07 | Samot | There's no SIP code for cause code 20 |
| 14:52.22 | Kobaz | which matches... but HANGUPCAUSE,ast... is set to 19... is the question |
| 14:52.26 | Samot | 18 or 19 would be the closest |
| 14:52.40 | file | oh that's the who hung up code |
| 14:52.44 | file | um |
| 14:52.53 | file | it uses a control thingy... let's see |
| 14:53.18 | Kobaz | where is seanbright to tell Samot to stop arguing with sibiria |
| 14:53.39 | seanbright | i know when to avoid a conversation |
| 14:53.44 | Kobaz | haha :) |
| 14:53.45 | sibiria | D"leave sibiria alone!!!!" |
| 14:53.56 | Samot | sibiria: There was a 100 Trying in all this, right? |
| 14:54.01 | Samot | Before the 480? |
| 14:54.10 | sibiria | Samot: yeah i omitted the obvious parts |
| 14:54.13 | Samot | Ahhh |
| 14:54.27 | Samot | 19 = user not answering after a provisional reply |
| 14:54.37 | Samot | 18 = user not answering no provisional reply |
| 14:54.43 | file | https://github.com/asterisk/asterisk/blob/16/channels/chan_pjsip.c#L3119 |
| 14:54.47 | file | there you go, likely due to that |
| 14:55.19 | file | depending on execution order changing the setting of ast_cause to use the hangupcause on session->channel might do something |
| 14:56.16 | Samot | So that little function sets it based on the SIP code, right? |
| 14:56.49 | file | for the querying of the information sibiria is referring to, yes |
| 14:57.07 | file | each dialed channel queues up the information (protocol and ast), in PJSIP that function does it |
| 14:57.32 | file | the information goes back to the caller who stores it away for later inspection using the dialplan functions |
| 14:57.59 | Samot | Which would cause the 19 then right? |
| 14:58.03 | file | yes |
| 14:58.05 | Samot | Since 480 maps to 19 |
| 14:58.05 | *** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy) |
| 14:58.23 | file | yes |
| 14:59.59 | sibiria | so i guess the documentation is ultimately at fault here, combined with my assumptions |
| 15:00.13 | sibiria | it does state "...or translated Asterisk cause code information..." |
| 15:00.40 | file | it is a reasonable expectation that the Reason header value would be present instead of using SIP mapping, as the Reason header value is used elsewhere |
| 15:00.57 | sibiria | in this case i'm calling HANGUPCAUSECODE(,ast) in an AGI script invoked by a hangup handler |
| 15:01.45 | sibiria | HANGUPCAUSE()* |
| 15:02.12 | Kobaz | hangup handlers! |
| 15:02.20 | Kobaz | oh how i love hangup handlers |
| 15:03.42 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-kuhedtwvbsakvqfy) |
| 15:03.42 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:17.46 | *** join/#asterisk Janos (~textual@201.204.94.76) |
| 15:17.59 | *** join/#asterisk mahafyi (2d7f2fb4@45.127.47.180) |
| 15:35.09 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-sujdrtgiuachspcr) |
| 15:35.09 | *** mode/#asterisk [+o bford] by ChanServ |
| 16:15.04 | *** join/#asterisk zgu (~steve@2603-7080-b744-4900-16ad-d120-de49-dc8b.res6.spectrum.com) |
| 16:32.22 | igcewieling | Kobaz: Hangup handlers are the best thing in Asterisk. |
| 16:38.41 | Kobaz | :) |
| 16:38.47 | Kobaz | Thanks, I wrote it |
| 16:39.18 | igcewieling | Really? |
| 16:39.26 | Kobaz | Yup |
| 17:16.26 | *** join/#asterisk ttys000 (~ttys000@50.92.215.114) |
| 17:28.15 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 17:42.39 | *** join/#asterisk sinaowolabi (~Sina@154.66.16.36) |
| 18:19.50 | Kobaz | I promise I will finish the rest of my addons too. So much going on, ugh, no time |
| 18:23.18 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda003836ac30b39637fa.dip0.t-ipconnect.de) |
| 18:32.26 | Samot | Cool, in another 10 years? |
| 18:32.31 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 18:39.34 | seanbright | harsh |
| 18:47.01 | igcewieling | hangup handlers are even more useful thanchan_local |
| 18:47.25 | *** join/#asterisk rwb (~Thunderbi@65.183.138.202) |
| 18:49.32 | seanbright | they certainly simplify a lot of things |
| 18:53.17 | igcewieling | I've been reworking my dialplan and AGIs so I've been dealing with them a lot recently. |
| 19:06.24 | Kobaz | Samot: yup |
| 19:06.33 | Kobaz | Samot: sounds about right |
| 19:07.05 | Samot | Just curious. The handlers have been around for about 10 years. |
| 19:07.16 | Kobaz | Yup |
| 19:07.27 | Kobaz | I wrote them for 1.6 |
| 19:07.52 | Kobaz | Got it comitted around that timeframe. Some digium folks reworked it a little bit and pushed it to mainline |
| 19:08.02 | Samot | Yeah, they didn't get added until 11. |
| 19:08.16 | Kobaz | It was in trunk for a while, yeah |
| 19:08.35 | Kobaz | I migrated it to 1.8, did some more testing and then got it in for 11 |
| 19:08.58 | Kobaz | It just didn't make sense that I had to do an 'h' for everywhere the channel might go |
| 19:09.04 | Kobaz | There just had to be a better way |
| 19:14.02 | Kobaz | i do feel bad i haven't finished my other work, letting all you guys down |
| 19:14.29 | Kobaz | Group Variables is one, and more improved group functions and searching, and also a metric crap ton of console logging improvements |
| 19:15.13 | Kobaz | now that we're (me) finally working on migrating to 16 and we'lll get a good solid amount of testing of all this stuff on 16 it will be a straighter shot to get this into trunk |
| 20:00.23 | *** join/#asterisk hfb (~hfb@45.152.182.240) |
| 20:12.09 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 20:13.35 | igcewieling | hanguphandlers is what convinced me to move to Asterisk 11 |
| 20:22.28 | Kobaz | nice |
| 20:23.34 | zgu | can i get the name of the channel being called from within a pre-dial (Dial(,b(...))) context? |
| 20:23.42 | Kobaz | yup |
| 20:23.52 | Kobaz | that's exactly what it's for |
| 20:24.12 | Kobaz | igcewieling: and speaking of patting myself on the back, i wrote that one too :) |
| 20:24.34 | Kobaz | zgu: it's literally in the example |
| 20:24.52 | Kobaz | zgu: https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers |
| 20:25.38 | Kobaz | Dial(SIP/bar&SIP/baz,,b(default^callee_handler^1)) <SIP/bar-124> In callee pre-dial handler! |
| 20:25.42 | zgu | oh i didn't see that page |
| 20:25.59 | Kobaz | When you're calling SIP/bar, and you want to know what channel name will be created... when SIP/bar calls the predial handler, now you have it |
| 20:26.10 | Kobaz | and all this happens *prior* to actually calling anyone in Dial() |
| 20:26.47 | Kobaz | predial handlers are also nice for adding SIP headers before the call goes out |
| 20:27.03 | zgu | but how do i get a value i can GotoIf() on? |
| 20:27.18 | Kobaz | share data with your parent channel |
| 20:27.30 | Kobaz | if you want your parent channel to have it |
| 20:28.01 | Kobaz | if you want to GotoIf... based on the channel name you just created... predial might not be the correct solution |
| 20:28.17 | Kobaz | You may want AMI or something like that, monitoring what's going on outside of asterisk |
| 20:28.46 | Kobaz | Once you're in Dial() you mostly lose control of what's going to happen. Dial() takes over |
| 20:28.55 | igcewieling | the pre dial handler runs on the outgoing channel. Using MASTER_CHANNEL(myvar) will allow you to get the channel variable value from the parent channe.. |
| 20:28.58 | zgu | can i just pass something as an argument to the pre dial handler? |
| 20:29.15 | Kobaz | set an inherited variable |
| 20:29.20 | Kobaz | Set(__foo=1234); |
| 20:29.27 | Kobaz | and then access ${foo} in your predial handler |
| 20:29.40 | Kobaz | do the set prior to the dial, and your callee channel will have it |
| 20:30.14 | Kobaz | or MASTER_CHANNEL, depends what you want to do |
| 20:30.39 | zgu | that seems to work with Set(__ |
| 20:31.09 | Kobaz | zgu: also, if you're doing a lot of GotoIf |
| 20:31.24 | Kobaz | you may want to look into AEL (https://wiki.asterisk.org/wiki/display/AST/Introduction+to+AEL) |
| 20:31.41 | Kobaz | It's a more structured version of extensions.conf, with actual If/Else blocks, and such |
| 20:32.12 | *** join/#asterisk scampbell (~scampbell@mail.scampbell.net) |
| 20:32.13 | zgu | actually what would really clean this up is if i could define a variable in the channel definition and look it up from the dialplan |
| 20:32.29 | Kobaz | you sure can |
| 20:33.04 | seanbright | do not use AEL |
| 20:33.07 | Kobaz | look at setvar |
| 20:33.21 | seanbright | as someone who uses AEL i encourage you to not use AEL |
| 20:33.24 | Kobaz | seanbright: there's nothing wrong with ael |
| 20:33.40 | zgu | or even better, access the SIP user agent registered to the extension |
| 20:33.50 | Kobaz | https://www.voip-info.org/asterisk-config-sipconf/ |
| 20:33.59 | Kobaz | setvar = variable=value : Channel variable to be set for all calls from this peer/user. (if you're using chan_sip) |
| 20:34.18 | Kobaz | set_var also works in pjsip as well, |
| 20:34.50 | Kobaz | seanbright: what would be your reason to not use ael? |
| 20:36.05 | seanbright | it is not good |
| 20:36.13 | Kobaz | define 'good' ? |
| 20:36.32 | seanbright | you need me to define 'good?' |
| 20:36.47 | seanbright | imo, ael is not good |
| 20:36.59 | Kobaz | I define good as, far superior visual structure |
| 20:37.24 | seanbright | so if a cake is good, it's because of it's superior visual structure? |
| 20:37.31 | seanbright | seems off |
| 20:37.31 | Kobaz | it's all of the benefits of a structured language with logical blocks, and none of the drawbacks of 1989 BASIC programming |
| 20:39.24 | seanbright | k |
| 20:40.58 | Kobaz | anecdotally I find it faster to teach ael than extensions.conf. It's easier to follow if (a) { dostuff }... then GotoIf(a=1?1:10) |
| 20:41.35 | Kobaz | even if you're using labels, to... it's all flat and hard to follow |
| 20:42.05 | *** join/#asterisk post-factum (~post-fact@vulcan.natalenko.name) |
| 20:43.07 | Kobaz | I've introduced a lot of long time users of extensions.conf to AEL and they are immediately blown away... "omg we can actually see what's going on now" |
| 20:48.08 | zgu | ah i need to say GotoIf($["${var}" = "value"] if value has something like / in it apparently |
| 20:48.27 | Kobaz | yeah $[] converts to a logical expression |
| 20:48.42 | Kobaz | where in ael, it does that for you |
| 20:48.54 | Kobaz | if ($"{var}" == "val") { dostuff } |
| 20:48.57 | zgu | but without the quotes it will parse and look like it's working, except it tries to interpret / as division |
| 20:49.07 | Kobaz | quotes are interesting in asterisk |
| 20:49.08 | zgu | so AEL has a grammar that actually makes sense? :P |
| 20:49.25 | Kobaz | quotes in modern asterisk are treated literally as characters |
| 20:49.37 | Kobaz | So, if you do Set(foo="bar") |
| 20:49.57 | Kobaz | You're actually setting the value of foo, to = "bar" ... it literally contains " characters |
| 20:50.31 | Kobaz | sorry zgu i wrote that totally wrong |
| 20:50.39 | Kobaz | if ("${var}" == "val") { dostuff } |
| 20:50.46 | zgu | yeah i had other things like $[${READEXTENSTATUS} = INVALID] that worked without quotes. and $[${var} = "PJSIP/foo"] which would be valid in sh or perl (with only one side quoted) didn't work |
| 20:50.56 | Kobaz | Correct |
| 20:51.07 | Kobaz | because you're comparing everything on the left, with everything on the right |
| 20:51.11 | Kobaz | there is no concept of quoting |
| 20:51.32 | zgu | i notice in the log messages it collapses to something like "GotoIf(1?label)" |
| 20:51.34 | Kobaz | You need: ${var} = PJSIP/foo or "${var}" = "PJSIP/foo" |
| 20:51.45 | Kobaz | or == |
| 20:52.25 | zgu | and PJSIP/foo with no quotes tries to divide PJSIP by foo? i was seeing "op_div: non numeric argument" |
| 20:52.25 | Kobaz | I like to use == because of the semantic meaning |
| 20:52.45 | Kobaz | Oh, right... it will since $[] convers it into basically a math expression |
| 20:52.50 | zgu | yeah i hate languages where = is both assignment and comparison |
| 20:52.55 | Kobaz | It's been a while since i had to use that stuff |
| 20:53.01 | Kobaz | since AEL does it for you |
| 20:53.19 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 20:53.44 | zgu | i'll have to try converting this to AEL when i have more time to mess with it |
| 20:59.36 | Kobaz | i'm one of the few who promotes AEL, so... let me know if you have an issue |
| 21:00.11 | igcewieling | I like AEL, but it makes debugging the dialplan hell. I've moved away from it. |
| 21:00.31 | Kobaz | it can if you don't know how it converts |
| 21:00.44 | seanbright | igcewieling: he just called you dumb |
| 21:00.47 | Kobaz | It does require knowing a little more about the internals |
| 21:01.03 | igcewieling | seanbright: happens all the time. |
| 21:01.13 | Kobaz | No, just saying more work is needed |
| 21:01.16 | Kobaz | It's not a smartness thing |
| 21:01.21 | seanbright | I KNOW |
| 21:01.22 | seanbright | CHRIST |
| 21:01.26 | Kobaz | : / |
| 21:03.50 | seanbright | good times |
| 21:05.56 | Kobaz | the phrase good times always reminds me of 'good times with weapons' https://i.ytimg.com/vi/Ux1lxqjoRHY/maxresdefault.jpg |
| 21:07.28 | seanbright | i got it from adam corolla of love line back in the day |
| 21:07.49 | seanbright | callers would call in with absolutely horrific stories and he would respond 'good times, good times...' |
| 21:07.51 | Samot | https://static.wikia.nocookie.net/goodtimes/images/c/c3/Good-Times-1.jpg |
| 21:08.11 | Samot | DYN-O-MITE! |
| 21:29.02 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 22:08.58 | *** join/#asterisk thansen (~thansen@192.74.130.86) |
| 22:10.13 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 22:17.44 | *** join/#asterisk jkroon (~jkroon@165.16.203.102) |
| 22:35.49 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 22:51.40 | *** join/#asterisk jkroon (~jkroon@165.16.203.102) |
