00:01.03 | *** join/#asterisk Janos (~textual@201.204.94.76) |
00:51.37 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
01:13.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
02:19.07 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
02:30.11 | *** join/#asterisk tsal (~tsal@i59F52E63.versanet.de) |
03:00.51 | *** join/#asterisk Janos (~textual@201.204.94.76) |
04:09.53 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
05:16.38 | *** join/#asterisk electronic_eel_ (~quassel@213.240.182.67) |
05:25.19 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
07:29.20 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
07:53.46 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
09:14.57 | *** join/#asterisk sponji (~i5@172.58.139.130) |
09:17.39 | *** join/#asterisk electronic_eel (~quassel@213.240.182.62) |
09:36.32 | *** join/#asterisk detha (~detha@unaffiliated/detha) |
11:18.15 | *** join/#asterisk estragon (~gerard@lfbn-nic-1-96-192.w2-15.abo.wanadoo.fr) |
13:01.39 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00e9e0a080f0bbea7b.dip0.t-ipconnect.de) |
15:30.21 | *** join/#asterisk electronic_eel_ (~quassel@213.240.182.235) |
15:32.43 | *** join/#asterisk electronic_eel (~quassel@213.240.182.235) |
15:36.28 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00016769c4bfbc9852.dip0.t-ipconnect.de) |
16:00.47 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
16:19.07 | Kobaz | Samot: ah hah! |
16:19.12 | Kobaz | it *IS* asterisk-16 weirdness |
16:19.18 | Samot | What? |
16:19.31 | Kobaz | let me show you |
16:19.40 | Kobaz | the connected line updates sending 's' |
16:21.35 | Kobaz | ah crap, dpaste cleared my thing |
16:21.53 | Kobaz | i hit enter instead of clicking submit... |
16:22.14 | Samot | What are you referring to? |
16:22.35 | Kobaz | https://dpaste.com/DXH6QBTE8 |
16:22.51 | Kobaz | I'm doing a B2BUA from yesterday. Polycom -> Asterisk -> PJSIP -> Asterisk |
16:23.12 | Kobaz | Dial()... and then on Pickup, Asterisk sends PAI of 's' |
16:23.14 | Samot | And is it hitting a s extension at some point? |
16:23.25 | Kobaz | yes |
16:23.32 | Kobaz | the AGI call is inside a 's' extension |
16:23.33 | Samot | Did yoy adjust those settings? |
16:23.53 | Kobaz | if i put the AGI call in like, 1234@some_context, then PAI sets set to '1234' |
16:24.08 | Samot | Yes |
16:24.17 | Kobaz | there's a setting for that? |
16:24.23 | Samot | Did you adjust those settings? |
16:24.37 | Samot | I gave them to you yesterday |
16:24.39 | Kobaz | 'those settings'... meaning... send_connected_line/trust |
16:24.43 | Kobaz | yes, they are set correctly |
16:24.43 | Samot | Yes |
16:24.52 | Samot | So those a set to no? |
16:24.54 | Kobaz | i want asterisk to send connected line updates to the polycom |
16:24.57 | Kobaz | so it's enabled |
16:25.18 | Kobaz | I just don't want it to send an 's' if I'm in an 's' extension. I want it to respect CONNECTEDLINE(all) |
16:25.20 | Samot | So PBX B has those disabled? |
16:25.43 | Kobaz | Actually, interestingly enough, pbx b is completely out of the picture now in terms of PAI |
16:25.56 | Kobaz | it's off, so the PAI is completely originating from Asterisk A |
16:26.23 | Kobaz | and it's because dial_out is implemented as a gosub |
16:26.48 | Kobaz | GoSub(dial_out,s,1)... typically passed params like the dialed number, but in this case i'm simplifying |
16:27.08 | Kobaz | typically it would be like GoSub(dial_out,s,1(6993204)) yada yada |
16:27.12 | Samot | So the connectedline is sending back the extension details in the 200ok |
16:27.16 | Kobaz | yup |
16:27.19 | Samot | You need tonupdate that |
16:27.28 | Kobaz | asterisk-11 doesn't do that |
16:27.33 | Samot | Are you actually setting it? |
16:27.37 | Samot | Jfc |
16:27.39 | Kobaz | it could care less what your extension is |
16:27.48 | Samot | Welcome to pjsip |
16:27.52 | Kobaz | i've tried setting it... (not in that example) |
16:27.53 | Kobaz | right, yeah |
16:28.00 | Samot | No you just said it send la 1234 |
16:28.07 | Samot | If you set 1234@ |
16:28.09 | Kobaz | let me do some more base case experiments, well yeah, that was one test |
16:28.18 | Samot | Because that's the extension |
16:28.29 | Samot | Are you setting connectedline() |
16:28.33 | Samot | Or not? |
16:28.47 | Kobaz | now I am, same thing |
16:28.59 | Samot | Show me the dialplan |
16:29.01 | Kobaz | yup |
16:30.23 | Kobaz | https://dpaste.com/H836RFFVV |
16:31.12 | *** join/#asterisk Janos (~textual@201.204.94.76) |
16:31.34 | Samot | Ok I need a few. |
16:31.39 | Kobaz | https://dpaste.com/9ZA4PSJHG |
16:31.41 | Kobaz | yup no problem |
16:32.31 | Kobaz | aaaaaand |
16:35.17 | Kobaz | https://dpaste.com/DG6TL3BZ6 |
16:36.01 | Kobaz | so I thought this have been related to AGI, but it's not. straight up Dial() still replicates |
16:38.21 | Kobaz | https://dpaste.com/4VKAZKRV4 so there you go... completely simplified |
16:39.12 | Samot | So while the call is dialing it's all good the moment it answers it is bad? |
16:39.17 | Kobaz | correct |
16:39.22 | Kobaz | on answer you get the PAI in the OK |
16:39.27 | Samot | Yeah you have CONNECTEDLINE wrong. |
16:39.54 | Kobaz | oh |
16:40.02 | Kobaz | it's not a sub param like channel |
16:40.12 | Samot | CONNECTEDLINE(all,i) |
16:40.26 | Samot | You need to ignore the updates sent by the channel driver |
16:40.29 | Kobaz | oooh |
16:40.45 | Samot | So give that a go. |
16:41.11 | Kobaz | [C-0000003b] <PJSIP/2801-0000006f> Executing [6993204@_cos_internal+local+ld:2] Set("CONNECTEDLINE(all,i)=<1234>") |
16:41.13 | Kobaz | nup |
16:41.29 | Samot | So don't use all |
16:41.39 | Kobaz | i've tried num and all that, let me try with this test case though |
16:41.42 | Samot | Oh wait |
16:41.44 | Samot | Dude. |
16:41.53 | Samot | That's still wrong. |
16:41.56 | Kobaz | hehe |
16:42.11 | Samot | Oh no, my bad. |
16:42.13 | Samot | So try this |
16:42.32 | Samot | CONNECTEDLINE(name,i)=CNAM |
16:42.35 | Kobaz | Set("CONNECTEDLINE(num,i)=1234") nup |
16:42.58 | Samot | Show pjsip dump and verbose log of this call |
16:43.03 | Samot | Start to finish |
16:46.10 | Kobaz | https://dpaste.com/4M5AMX5AC |
16:49.27 | Kobaz | core set debug isn't really shedding any light |
16:50.01 | Kobaz | literally goes from [C-00000040] <PJSIP/2801-00000079> Executing [s@dial_out:2] Dial("PJSIP/6993204@trunk-bob") to: Transmitting SIP response...P-Asserted-Identity: <sip:s@192.168.125.118;user=phone> |
16:50.08 | Kobaz | with no mention of 's' anywhere in between |
16:50.48 | Samot | OK, so where did you set those connected line settings to no? |
16:50.51 | Kobaz | so it looks like it's 'stuck' on the extension you called, and it's completely ignoring any kind of connected line settings prior to sending |
16:50.52 | Samot | Where at? |
16:51.01 | Kobaz | yeah they are set on.. the endpoint for 2801 and trunk-bob |
16:51.12 | Samot | OK. |
16:51.15 | Samot | Why? |
16:51.19 | Kobaz | why not? |
16:51.21 | Samot | 2801 is fine. |
16:51.27 | Samot | trunk-bob, why? |
16:51.43 | Samot | Because if you set them to no they stop the endpoint FROM UPDATING IT |
16:51.49 | Kobaz | trunk-bob, i don't want to take in any connected line updates, i want to control them locally, so trust is a 'no' |
16:52.04 | Samot | So the two are set to no? |
16:52.12 | Kobaz | and trust from the polycom is no |
16:52.20 | Kobaz | send_connected_line is a yes for the polycom/2801 |
16:52.28 | Kobaz | since you know... i want it to know who its talking to |
16:52.28 | Samot | And for the trunk? |
16:52.34 | Kobaz | send is no, and trust is no |
16:52.39 | file | app_dial has code which falls back to dialplan extension if it can't determine callerid information for outgoing leg, either identify why that code is executing or set the 'I' option and see if that helps |
16:52.59 | Samot | Yes, that is next. |
16:53.02 | Kobaz | file: that seems like what is happening |
16:53.42 | Kobaz | Dial with 'I' does help |
16:53.54 | Kobaz | so based on what you wrote, it sounds like it's doing the fallback |
16:54.21 | Samot | I is the turn off connectedline updates for Dial() |
16:54.24 | Kobaz | question. so... shouldn't CONNECTEDLINE(num,i) also do that? |
16:54.28 | Kobaz | right |
16:54.45 | Kobaz | Dial is taking over connectedline, and it's not using CONNECTEDLINE, but instead using the local dialplan exten |
16:54.47 | file | no, because CONNECTEDLINE(num,i) sets the connected line information at the point it is executed but does not trigger an update |
16:54.55 | file | if the connected line subsequently changes, then it would change |
16:54.59 | Kobaz | no i mean, i don't expected it to update |
16:55.17 | Kobaz | i would expect it to then say, hey, don't do any more changes to connectedline, because i just told you to ignore them |
16:55.24 | file | that's not what the 'i' option does. |
16:55.32 | Kobaz | okay |
16:56.00 | Kobaz | i - If set, this will prevent the channel from sending out protocol messages because of the value being set |
16:56.08 | Samot | Sending. |
16:56.08 | Kobaz | So, that's not a protocol message then? |
16:56.13 | Samot | The channel isn't sending. |
16:56.17 | Samot | The other channel is |
16:56.23 | Kobaz | define the 'other' channel |
16:56.24 | file | is what a protocol message? |
16:56.32 | file | the option is if you are executing multiple CONNECTEDLINE sets |
16:56.33 | Samot | Well polycom dials, that's a channel |
16:56.37 | Samot | Then you dial() |
16:56.39 | file | you want to wait until the last one to actually send an update |
16:56.41 | Samot | That's another channel |
16:56.45 | Kobaz | the PAI that Dial() triggers... after setitng CONNECTEDLINE |
16:56.47 | Samot | The dial() channel is doing the update |
16:56.52 | Samot | Sending to the polycom channel |
16:57.04 | Samot | Therefore the polycom channel isn't sending, it's receiving. |
16:57.12 | Kobaz | perspective |
16:57.30 | Kobaz | the polycom phone is not sending updates to asterisk... asterisk is sending updates to the polycom, to be explicit |
16:57.45 | Samot | OK |
16:57.48 | Kobaz | the channel *to* the polycom, from asterisk, *is* sending the connected line update |
16:58.18 | Kobaz | that's why a generic statement like 'sending to the polycom channel' is not clear |
16:58.22 | Kobaz | need perspective |
16:59.08 | Kobaz | so yeah... 'I' for sure helps in this case, so it would be a nice exersize to see why app_dial is overriding/ignoring CONNECTEDLINE |
16:59.09 | Samot | The perspective is from within Asterisk |
16:59.26 | Samot | And the channels themselves. |
16:59.28 | Kobaz | then that statement is inaccurate, if the perspective is asterisk |
16:59.30 | file | because upon answer the channel was connected to something else. |
16:59.38 | file | which triggered a connected line update. |
16:59.42 | Kobaz | ah |
16:59.59 | file | that's how connected line update works, you get connected to something else then it updates, unless you tell it not to |
17:00.04 | Kobaz | right, true |
17:00.30 | Kobaz | but... i'm saying connected line updates from trunk-bob are untrusted |
17:00.36 | Kobaz | so anything there should not be passed through |
17:01.06 | Kobaz | and. the connected line that gets sent here based on my experiments, is entirel based on what dialplan context extension the Dial() is running fropm |
17:01.11 | file | oy |
17:01.15 | *** part/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
17:01.22 | Kobaz | which leads me to believe this is not related to a connected line update coming in and being passed to the phone |
17:01.29 | file | the option in the endpoint controls remotely provided connected line updates |
17:01.44 | file | the act of dialing a channel, even if they don't send you a connected line update, can still result in a connected line update |
17:01.48 | Kobaz | sure |
17:02.06 | Kobaz | and then, my question is now.. which i don't think anyone knows at this very moment |
17:02.16 | file | and because app_dial has fallback logic for callerid it is entirely possible that the connected information on the dialed channel is that of the dialplan position |
17:02.23 | file | thus upon answer a connected line update would occur to update to that |
17:02.31 | Kobaz | is... precisely why is the connected line update based on the dialplan extension that Dial() is exec'd from |
17:02.45 | Kobaz | yeah fallback logic, like you mentioned |
17:03.21 | Kobaz | so that's my next dive... look into the fallback logic and see why is it doing a fallback in the first place, and why can' |
17:03.30 | Kobaz | t it use CONNECTEDLINE that was just set |
17:03.37 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
17:03.50 | Samot | You're missing the UPDATE part. |
17:03.59 | Samot | It *did* use the CONNECTEDLINE you set. |
17:04.10 | Samot | Then the other side answered and updated it. |
17:04.11 | Kobaz | only if i tell Dial to ignore any future updates |
17:04.13 | file | if you want it to use the value you've set, then set the 'I' option so nothing can override it |
17:04.14 | Kobaz | no |
17:04.20 | Samot | No. |
17:04.24 | Samot | Stop. |
17:04.30 | Samot | Just stop. |
17:04.31 | Kobaz | Samot: you're missing the point where, it doesn't matter what happens at all on the 'other side' |
17:04.35 | Samot | Stop. |
17:04.48 | Kobaz | If i move the 'Dial' from 's' to 'y' or to '1234' extension, THAT is my connected line update |
17:04.54 | Kobaz | Samot: I have my answer from file |
17:04.54 | Samot | Just wait. |
17:05.10 | Samot | Yes, using I in Dial() |
17:05.10 | file | you could probably set a callerid value on the dialed leg in maybe the pre-dial handler, that might do something |
17:05.14 | Samot | To ignore updates. |
17:05.18 | Kobaz | file: tried that :( |
17:05.29 | file | what did you try explicitly? |
17:05.43 | Kobaz | predial callee handler, set CONNECTEDLINE |
17:05.49 | file | then shrug |
17:05.53 | Kobaz | what i didn't try is predialcaller handler |
17:05.58 | Kobaz | connectedline is really on the caller channel |
17:06.23 | file | connected line on the caller channel changes as a result of the called channel. |
17:06.33 | Kobaz | Samot, file: in the event, that sometime down the line i DO want to take in connected line updates (if there is one!), and pass them to the phone. I don't want the fallback to be the dialplan extension the Dial() is running in |
17:06.45 | Kobaz | correct, and then if there are no changes on the called channel... |
17:06.50 | Kobaz | nothing should happen in theory |
17:06.54 | file | there are changes on the called channel. |
17:06.55 | Samot | If you call from your Polycom and call Voicemail... |
17:07.00 | Kobaz | and it should use whatever connectedline it had before |
17:07.08 | Samot | You set CONNECTEDLINE before going to VoicemailAdmin |
17:07.16 | Samot | The voicemail system doesn't do updates |
17:07.20 | Kobaz | correct |
17:07.24 | file | it will be updated to be whatever it is connected to upon answer |
17:07.26 | Samot | So your phone's connected line details don't change. |
17:07.33 | Samot | They are whatever you set CONNECTEDLINE to |
17:07.37 | Kobaz | correct |
17:07.39 | Samot | Anything is like that |
17:07.41 | Samot | IVR, etc |
17:07.54 | Samot | Because it's Polcyom -> Asterisk. |
17:07.58 | Samot | It's one channel. |
17:08.17 | Samot | Once you introduce a second channel, and that answers it will update the *first* channel. |
17:08.21 | Samot | If allowed so. |
17:08.42 | Kobaz | let me ask this... i think it should be expected behavior, that if the dialed party does not provide a connected line update, that it should default to CONNECTEDLINE (if there is one) and not the dialplan extension you're in |
17:08.52 | Kobaz | Or... do we need an new option to Dial() to control the fallback behvior |
17:09.20 | Kobaz | no updates from the 'far-end' on a Dial(), fall back to CONNECTEDLINE |
17:09.32 | file | that is not a behavior that is going to change without an option |
17:09.39 | file | as it has existed for a SUBSTANTIAL amount of time |
17:09.43 | Kobaz | okay fair enough |
17:10.03 | file | and before even bringing up the idea of an option or behavior changes, truly understanding the scenario and what is going on is needed |
17:10.13 | Kobaz | yeah |
17:10.45 | Kobaz | my use case here is I have a quite a lot of code implementing a custom SLA solution that heavily makes use of CONNECTEDLINE and the current behavior in 16 would make a lot of it impossible without core code changes |
17:10.50 | Kobaz | (so far that I see) |
17:11.07 | Samot | I use this. |
17:11.09 | Kobaz | there still could be some ways around this, but yeah defintely would be some behavior differences |
17:11.18 | Samot | When a calls leaves the PBX to the PSTN, I don't do updates |
17:11.37 | Samot | I tell it what it should be and don't let it get updated by the other channel. |
17:11.42 | Kobaz | right |
17:11.57 | Samot | Local calls are different because all that is already set in places. |
17:11.57 | file | there are also hooks for controlling/manipulating connected line updates. |
17:12.00 | Samot | endpoints, etc |
17:12.09 | Kobaz | file: aah that may work |
17:12.27 | Kobaz | because, here's what happens for our SLA |
17:12.30 | Samot | I also think what might help here.... |
17:12.36 | Kobaz | someone 'picks up a line', and they are talking to.... someone on the pstn |
17:12.48 | Kobaz | so i CONNECTEDLINE update the phone to say, you're in with 2121231234 |
17:13.03 | Samot | You realize that "asterisk 16 weirdness" is really the fact you've jump 5 majors versions over which major changes where made. |
17:13.07 | Kobaz | haha |
17:13.08 | Kobaz | i know |
17:13.15 | Samot | ARe you sure? |
17:13.21 | Samot | I'm asking this seriously. |
17:13.35 | Kobaz | To me, it's weird behavior, for sure |
17:13.39 | Samot | Because yesterday with your goSub problem it was Asterisk 16 weirdness and you started going through app_stack code.... |
17:13.46 | Kobaz | Like, I wouldn't expect the connected line to set based on the extension |
17:13.54 | Samot | And the real issue was a lack of Return() in dialplan. |
17:14.02 | Kobaz | Samot: which i found, based on looking at app_stack |
17:14.09 | Samot | But that's standard |
17:14.12 | Samot | Not Asterisk 16 |
17:14.15 | Samot | That's just gosub. |
17:14.16 | Kobaz | sure |
17:14.46 | Kobaz | it wasn't something i really put much work into previously, and just noticed i had handling in my generator for doing that in asterisk-11+ but the versioning didn't catch 16 |
17:14.49 | Kobaz | so it didn't generate the return |
17:14.56 | Kobaz | So, chain of events... |
17:15.17 | Kobaz | This one place specifically checked for version = "11" so... that was the problem |
17:15.36 | Kobaz | but anyway, that's neither here nor there |
17:17.04 | Kobaz | so, where's seanbright to tell you to stop arging with me now :) |
17:17.20 | Samot | I'm not aruging. |
17:17.25 | Samot | arguing |
17:17.29 | Kobaz | [2021-02-27 12:04:30] <Samot> Just stop. |
17:17.49 | Samot | That was to get you to stop typing so I could have you follow what I was going to say |
17:17.54 | Samot | You know, pay attention. |
17:18.24 | Samot | I was not arguing in that case, I was telling you to shut up. :) |
17:18.27 | Kobaz | i was following you, it was just not what i needed. file got to the bottom of the thing i'm running into |
17:18.48 | Samot | Yes, because as soon as he commented my next comment was "Yup, that was the next thing" |
17:18.54 | Samot | It was like I was going in an order.. |
17:19.03 | Kobaz | heh |
17:19.39 | Kobaz | these more technical discussions just get... oddly heated |
17:19.52 | Samot | Well.. |
17:20.07 | Samot | You come at these with "asterisk 16 weirdness" |
17:20.16 | Kobaz | and it's weird! |
17:20.21 | Kobaz | but, i'll come to live with it |
17:20.28 | Samot | Then it's just general stuff that anything > 11 has. |
17:20.31 | Kobaz | i didn't say it's broken, just weird |
17:20.38 | Samot | It's not Asterisk 16 |
17:20.46 | Samot | It's the fact it's > 11 |
17:20.49 | Kobaz | okay i'll be more specific next time |
17:21.00 | Samot | That's my only point here. |
17:21.01 | Kobaz | I'll say, "wow this is weird post-asterisk-11 stuff going on right up in here" |
17:21.12 | Samot | Yeah, that could be it. |
17:21.57 | Kobaz | I'll make sure I prepend all my questions with that... just for you :) |
17:22.04 | Samot | Wait till you got to 18 with the new codec handling. |
17:22.12 | Kobaz | sounds fun |
17:23.33 | Samot | There is a reason that we are on even releases for TLS now. |
17:23.39 | Kobaz | yeah |
17:23.50 | Samot | Because what was introduced in 14 still was being worked through in 15. |
17:23.56 | Kobaz | yup |
17:24.08 | Samot | So 12 saw big updates. |
17:24.18 | Samot | 14 say big updates that rolled into 15 |
17:24.26 | Samot | 17 introduced stuff |
17:24.39 | Kobaz | yeah, even though i don't use the stuff in production yet, i follow the dev a bit |
17:25.48 | Samot | I had a learning curve with chan_pjsip too. I didn't jump to it right away... |
17:26.11 | Kobaz | yeah this has been a few months going, several actually.. since about october |
17:26.18 | Samot | However, the timeframe in which to flatten that learning curve for people without being caught in a mess is shortening. |
17:26.44 | Samot | Chan_SIP has to sword of Damocles hanging over it |
17:27.28 | Kobaz | chan_sip is buckets of fun |
17:28.12 | Kobaz | I remember the good old days of writing an AttendedTransfer event so i wouldn't have to process successive Link/Unlink/Masquerade/Rename/Bridge events to figure out if a transfer happened |
17:29.17 | Kobaz | and oddly enough the new generic AttendedTransferEvent is quite similar to my version, TransferTarget and stuff like that were all names I came up with independently back then |
17:31.54 | Kobaz | it's going to be buckets more fun when we get into video |
17:57.14 | igcewieling | Kobaz: I've found over and over again, things I did to work around limitations in Asterisk are not relevant in later versions. Sounds like you are seeing that too. |
17:57.44 | Kobaz | yeah |
17:57.49 | Kobaz | well, it's some of that, and some... new workarounds |
17:58.54 | Kobaz | Like, from the previous conversation: I really want connected line to be left alone unless there's an update from the far-end |
17:59.30 | Kobaz | but I have enough now to start to try and figure that out |
18:01.24 | Kobaz | and I also understand my use cases are like .001% of the population that does the stuff I do |
18:01.44 | Kobaz | So I appreciate all the feedback even if it gets toasty in here |
18:03.06 | igcewieling | My stuff is pretty basic. Route calls. That is pretty much it. I don't even have voicemail on my non-FreePBX boxes. |
18:04.25 | Kobaz | hehe |
18:04.56 | Kobaz | I miss oej. He always was working on the edgiest of edge cases |
18:06.09 | igcewieling | *nod* I think he got lost in some sort of SIP forwarding loop and was thrown into an adjacent universe. |
18:09.33 | Kobaz | too many forks |
18:11.12 | igcewieling | The older I get the less cutting edge appeals to me. |
18:13.22 | *** join/#asterisk TriJetScud (~TriJetScu@23.172.144.5) |
18:15.21 | Kobaz | i broke it |
18:15.22 | Kobaz | hmm |
18:15.43 | Samot | Broke what |
18:16.10 | Kobaz | attended transfer |
18:16.42 | Kobaz | I was doing a playback in a local channel and then transferred the call |
18:16.47 | Samot | The incall feature? |
18:16.54 | Kobaz | sip replaces, with two legs |
18:17.10 | Kobaz | gonna try and reproduce here in a moment |
18:17.31 | Kobaz | https://dpaste.com/8ULLL4Q76 |
18:18.09 | Kobaz | yup |
18:18.12 | Kobaz | 100% repproducable |
18:18.56 | Kobaz | https://dpaste.com/BTXP6XCYS |
18:20.04 | Kobaz | local channels don't like sip replaces in this situation |
18:26.05 | *** join/#asterisk mmlj4 (~mmlj4@ip174-69-111-70.no.no.cox.net) |
19:29.08 | igcewieling | Samot: when you disconnect TNs with Bandwidth.com, how long does it take to apply? |
19:30.37 | Samot | Not to long. Not sure the exact time frame. It's rare I release them back. |
19:36.59 | igcewieling | I signed up for a free trial to look at their GUI and APIs. |
19:52.22 | *** join/#asterisk rpifan (~rpifan@p200300d2671bda00dc4af35fc3f917cc.dip0.t-ipconnect.de) |
19:59.21 | igcewieling | I'm going to investigate moving our SIP toll frees to them. We have less than 75 TF numbers so it should be easily manageable. |
21:05.37 | Kobaz | Samot: my stuff broke it, not an asterisk bug |
21:17.58 | *** join/#asterisk GandalfCorvotemp (5d28d1ff@93-40-209-255.ip40.fastwebnet.it) |
21:18.07 | GandalfCorvotemp | Hi guys! |
21:19.08 | GandalfCorvotemp | best way to use an android mobile phone as SIP linphone (there is native SIP support in android) but *keep* the call on when switching from wifi to mobile connection ? |
21:21.01 | Kobaz | that's a good question. you would need to make the client reinvite using the wan ip on mobile |
21:23.00 | GandalfCorvotemp | but client should do this on it's own when detecting the network change ? Do you know any client able to do this ? |
21:23.52 | Kobaz | That I don't know |
21:24.04 | Kobaz | You would need to see if linphone supports that, otherwise ask for a feature request |
21:25.02 | Kobaz | belledonne does paid features/addons, if that's what you need... it's not cheap |
21:25.47 | GandalfCorvotemp | so, it's a client side issue, nothing to do with asterisk |
21:26.46 | Kobaz | correct |
21:27.09 | GandalfCorvotemp | but if the connection is closed during the switch , how can I send a reinvite on a closed session ? |
21:27.30 | Kobaz | You can't, it has to hook into the wifi going off event on the phone, and reinvite prior to losing connection |
21:28.23 | GandalfCorvotemp | i don't think would be possible. if you loose the wifi connection , the even is triggered when the connection is already lost. |
21:29.25 | Kobaz | If someone is interactively switching, that might be an an option |
21:29.40 | Kobaz | I don't do any mobile development, but i know some generic stuff about it |
21:30.04 | GandalfCorvotemp | sure, but not in my case. i need to keep the call on when user is moving outside wifi coverage |
21:30.52 | Samot | Then you need to spend money. |
21:31.06 | *** join/#asterisk sadsnork (~sadsnork@ns500513.ip-192-99-6.net) |
21:31.13 | GandalfCorvotemp | for what ? what's the solution ? |
21:31.14 | Samot | Native SIP in Android isn't going to cut it. |
21:31.50 | Kobaz | GandalfCorvotemp: it's going to involve some deep mobile development. I'm sure it's possible |
21:32.07 | Samot | It is |
21:32.30 | Kobaz | As long as you have mobile data prior to losing wifi, you can reinvite when the wifi signal drops to a threshold, before it's disconnected |
21:32.36 | Samot | But generally at the enterprise/provider level |
21:33.05 | Kobaz | It does help to have support from the provider |
21:33.16 | GandalfCorvotemp | AFAIK, mobile data are off when wifi is connected. and even an IP switch from the mobile carrier would drop the call |
21:33.17 | Samot | By provider i just mean a voice platform |
21:33.18 | Kobaz | Mobile providers do this with wifi calling -> mobile calling because they ARE the network |
21:33.49 | Samot | And because they have their own firmware |
21:33.54 | Kobaz | yup |
21:35.00 | Samot | But this is more than just SDP updates |
21:35.16 | Samot | The contact is going to change |
21:35.17 | Kobaz | Samot: this is really exciting stuff. I'm getting to remove quite a lot of asterisk-11 specific code that's not needed because -16 has it already |
21:36.29 | *** part/#asterisk estragon (~gerard@lfbn-nic-1-96-192.w2-15.abo.wanadoo.fr) |
21:36.49 | Kobaz | welcomes myself to Asterisk-2021 |
21:44.32 | GandalfCorvotemp | siproxyd could help ? |
21:44.51 | Kobaz | GandalfCorvotemp: no |
21:45.15 | GandalfCorvotemp | the call is made between asterisk and the proxy, thus the ip address is always fixed. the sipua would connect to the proxy and the proxy routes the call |
21:45.17 | Kobaz | GandalfCorvotemp: the *device* (ie: the phone) needs to support this behavior. no amount of nat or proxying or fancy load balaning will solve this |
21:45.27 | GandalfCorvotemp | ok |
21:45.36 | Kobaz | if the call is gone, the call is gone |
21:45.39 | *** join/#asterisk TriJetScud (~TriJetScu@23.172.144.5) |
21:45.54 | Kobaz | wifi has lost the call, it needs to be taken up on the mobile-data side, by the phone prior to switching |
21:46.21 | GandalfCorvotemp | clear |
21:48.01 | Kobaz | and if you want to use a sip proxy, use a commercial-grade one like kamailio/SER/OpenSIPS |
21:48.36 | GandalfCorvotemp | tnx for the clarification |
21:48.36 | Kobaz | siproxyd is someone's pet project with limited development... not saying that's bad, but I wouldn't use for business |
22:05.33 | Kobaz | now i gotta figure out how to get individual details out of bridge and channel snapshots and i'l golden |
22:17.44 | Kobaz | beautiful |
22:17.46 | Kobaz | [2021-02-27 17:16:46.089] -- <PJSIP/2802-00000001> Attended Transfer Success. PJSIP/trunk-bob-00000000 replaces PJSIP/2802-00000001. PJSIP/2802-00000003 will be hanging up |
22:18.12 | Kobaz | I <3 channel snapshots |
22:19.15 | igcewieling | that is a very useful message. |
22:19.28 | igcewieling | where is the logid? |
22:19.57 | Kobaz | i know :( |
22:20.12 | Kobaz | this is handled out of band from the channel thread, so it doesn't have the call-id |
22:20.18 | Kobaz | but i'm going to add that in |
22:20.27 | igcewieling | that is a problem for other parts of Asterisk stoo. |
22:20.31 | Kobaz | yup |
22:20.38 | Kobaz | igcewieling: yeah, i've had code for showing that message since asterisk-11 |
22:20.50 | Kobaz | I feel bad I didn't get that comitted sooner because it would have been already in 16 |
22:21.47 | Kobaz | I'm actually working on a bid for a project to do data analytics on transferred calls... because the current vendor doesn't track it. and says "it's not possible in asterisk" |
22:21.50 | Kobaz | uhh, not possible? haha |
22:22.39 | Kobaz | it was possible to track transferred calls in asterisk 1.4 (it was NOT easy at all) |
22:22.54 | igcewieling | I am very glad I don't have to deal with transferred calls. |
22:24.07 | igcewieling | Can't you track them using CEL events? |
22:24.29 | Kobaz | CEL wasn't always a thing |
22:24.34 | Kobaz | but yeah you could in theory |
22:27.03 | Kobaz | speaking of log id |
22:27.04 | igcewieling | I use CEL for "basic" logging. The call events part of this https://imgur.com/Gm0Dsry.png |
22:27.09 | Kobaz | feel free to test this |
22:27.32 | Kobaz | https://gerrit.asterisk.org/c/asterisk/+/15547 |
22:27.43 | Kobaz | I just pushed that up this morning |
22:30.12 | Kobaz | if you like call ids, you'll like that change |
22:36.48 | Kobaz | added some more logging |
22:36.59 | Kobaz | -- <PJSIP/2802-00000001> Attended Transfer Success. PJSIP/trunk-bob-00000000 replaces PJSIP/2802-00000001. PJSIP/2802-00000003 will be hanging up. Transfered to: App: Dia |
22:37.19 | Kobaz | that's if you're basically blind transferring via attended/replaces |
22:37.27 | Kobaz | the called channel is still in Dial() |
22:37.40 | Kobaz | and then if the called party answers, and THEN you transfer, you get |
22:37.49 | Kobaz | -- <PJSIP/2802-00000006> Attended Transfer Success. PJSIP/trunk-bob-00000005 replaces PJSIP/2802-00000006. PJSIP/2802-00000008 will be hanging up. Transfered to: Bridge: 65ad75a0-a842-43c7-bb67-be43ce0e24ec |
22:39.23 | Kobaz | the variable_data DestType field is going to be soooo helpful for my tracking system, previously I had a concept of a 'fast attended transfer' and a 'slow attended transfer'. Which was basically equating to the 'fast' being while you're still in dial and no one's answered, and then the 'slow' attended transfer being after pickup/answer |
22:39.27 | Kobaz | so cool |