IRC log for #asterisk on 20210227

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.07KobazSamot: ah hah!
16:19.12Kobazit *IS* asterisk-16 weirdness
16:19.18SamotWhat?
16:19.31Kobazlet me show you
16:19.40Kobazthe connected line updates sending 's'
16:21.35Kobazah crap, dpaste cleared my thing
16:21.53Kobazi hit enter instead of clicking submit...
16:22.14SamotWhat are you referring to?
16:22.35Kobazhttps://dpaste.com/DXH6QBTE8
16:22.51KobazI'm doing a B2BUA from yesterday.  Polycom -> Asterisk -> PJSIP -> Asterisk
16:23.12KobazDial()... and then on Pickup, Asterisk sends PAI of 's'
16:23.14SamotAnd is it hitting a s extension at some point?
16:23.25Kobazyes
16:23.32Kobazthe AGI call is inside a 's' extension
16:23.33SamotDid yoy adjust those settings?
16:23.53Kobazif i put the AGI call in like, 1234@some_context, then PAI sets set to '1234'
16:24.08SamotYes
16:24.17Kobazthere's a setting for that?
16:24.23SamotDid you adjust those settings?
16:24.37SamotI gave them to you yesterday
16:24.39Kobaz'those settings'... meaning... send_connected_line/trust
16:24.43Kobazyes, they are set correctly
16:24.43SamotYes
16:24.52SamotSo those a set to no?
16:24.54Kobazi want asterisk to send connected line updates to the polycom
16:24.57Kobazso it's enabled
16:25.18KobazI 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.20SamotSo PBX B has those disabled?
16:25.43KobazActually, interestingly enough, pbx b is completely out of the picture now in terms of PAI
16:25.56Kobazit's off, so the PAI is completely originating from Asterisk A
16:26.23Kobazand it's because dial_out is implemented as a gosub
16:26.48KobazGoSub(dial_out,s,1)... typically passed params like the dialed number, but in this case i'm simplifying
16:27.08Kobaztypically it would be like GoSub(dial_out,s,1(6993204)) yada yada
16:27.12SamotSo the connectedline is sending back the extension details in the 200ok
16:27.16Kobazyup
16:27.19SamotYou need tonupdate that
16:27.28Kobazasterisk-11 doesn't do that
16:27.33SamotAre you actually setting it?
16:27.37SamotJfc
16:27.39Kobazit could care less what your extension is
16:27.48SamotWelcome to pjsip
16:27.52Kobazi've tried setting it... (not in that example)
16:27.53Kobazright, yeah
16:28.00SamotNo you just said it send la 1234
16:28.07SamotIf you set 1234@
16:28.09Kobazlet me do some more base case experiments, well yeah, that was one test
16:28.18SamotBecause that's the extension
16:28.29SamotAre you setting connectedline()
16:28.33SamotOr not?
16:28.47Kobaznow I am, same thing
16:28.59SamotShow me the dialplan
16:29.01Kobazyup
16:30.23Kobazhttps://dpaste.com/H836RFFVV
16:31.12*** join/#asterisk Janos (~textual@201.204.94.76)
16:31.34SamotOk I need a few.
16:31.39Kobazhttps://dpaste.com/9ZA4PSJHG
16:31.41Kobazyup no problem
16:32.31Kobazaaaaaand
16:35.17Kobazhttps://dpaste.com/DG6TL3BZ6
16:36.01Kobazso I thought this have been related to AGI, but it's not.  straight up Dial() still replicates
16:38.21Kobazhttps://dpaste.com/4VKAZKRV4 so there you go... completely simplified
16:39.12SamotSo while the call is dialing it's all good the moment it answers it is bad?
16:39.17Kobazcorrect
16:39.22Kobazon answer you get the PAI in the OK
16:39.27SamotYeah you have CONNECTEDLINE wrong.
16:39.54Kobazoh
16:40.02Kobazit's not a sub param like channel
16:40.12SamotCONNECTEDLINE(all,i)
16:40.26SamotYou need to ignore the updates sent by the channel driver
16:40.29Kobazoooh
16:40.45SamotSo give that a go.
16:41.11Kobaz[C-0000003b] <PJSIP/2801-0000006f> Executing [6993204@_cos_internal+local+ld:2] Set("CONNECTEDLINE(all,i)=<1234>")
16:41.13Kobaznup
16:41.29SamotSo don't use all
16:41.39Kobazi've tried num and all that, let me try with this test case though
16:41.42SamotOh wait
16:41.44SamotDude.
16:41.53SamotThat's still wrong.
16:41.56Kobazhehe
16:42.11SamotOh no, my bad.
16:42.13SamotSo try this
16:42.32SamotCONNECTEDLINE(name,i)=CNAM
16:42.35KobazSet("CONNECTEDLINE(num,i)=1234")  nup
16:42.58SamotShow pjsip dump and verbose log of this call
16:43.03SamotStart to finish
16:46.10Kobazhttps://dpaste.com/4M5AMX5AC
16:49.27Kobazcore set debug isn't really shedding any light
16:50.01Kobazliterally 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.08Kobazwith no mention of 's' anywhere in between
16:50.48SamotOK, so where did you set those connected line settings to no?
16:50.51Kobazso 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.52SamotWhere at?
16:51.01Kobazyeah they are set on.. the endpoint for 2801 and trunk-bob
16:51.12SamotOK.
16:51.15SamotWhy?
16:51.19Kobazwhy not?
16:51.21Samot2801 is fine.
16:51.27Samottrunk-bob, why?
16:51.43SamotBecause if you set them to no they stop the endpoint FROM UPDATING IT
16:51.49Kobaztrunk-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.04SamotSo the two are set to no?
16:52.12Kobazand trust from the polycom is no
16:52.20Kobazsend_connected_line is a yes for the polycom/2801
16:52.28Kobazsince you know... i want it to know who its talking to
16:52.28SamotAnd for the trunk?
16:52.34Kobazsend is no, and trust is no
16:52.39fileapp_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.59SamotYes, that is next.
16:53.02Kobazfile: that seems like what is happening
16:53.42KobazDial with 'I' does help
16:53.54Kobazso based on what you wrote, it sounds like it's doing the fallback
16:54.21SamotI is the turn off connectedline updates for Dial()
16:54.24Kobazquestion. so... shouldn't CONNECTEDLINE(num,i) also do that?
16:54.28Kobazright
16:54.45KobazDial is taking over connectedline, and it's not using CONNECTEDLINE, but instead using the local dialplan exten
16:54.47fileno, because CONNECTEDLINE(num,i) sets the connected line information at the point it is executed but does not trigger an update
16:54.55fileif the connected line subsequently changes, then it would change
16:54.59Kobazno i mean, i don't expected it to update
16:55.17Kobazi 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.24filethat's not what the 'i' option does.
16:55.32Kobazokay
16:56.00Kobazi - If set, this will prevent the channel from sending out protocol messages because of the value being set
16:56.08SamotSending.
16:56.08KobazSo, that's not a protocol message then?
16:56.13SamotThe channel isn't sending.
16:56.17SamotThe other channel is
16:56.23Kobazdefine the 'other' channel
16:56.24fileis what a protocol message?
16:56.32filethe option is if you are executing multiple CONNECTEDLINE sets
16:56.33SamotWell polycom dials, that's a channel
16:56.37SamotThen you dial()
16:56.39fileyou want to wait until the last one to actually send an update
16:56.41SamotThat's another channel
16:56.45Kobazthe PAI that Dial() triggers... after setitng CONNECTEDLINE
16:56.47SamotThe dial() channel is doing the update
16:56.52SamotSending to the polycom channel
16:57.04SamotTherefore the polycom channel isn't sending, it's receiving.
16:57.12Kobazperspective
16:57.30Kobazthe polycom phone is not sending updates to asterisk... asterisk is sending updates to the polycom, to be explicit
16:57.45SamotOK
16:57.48Kobazthe channel *to* the polycom, from asterisk, *is* sending the connected line update
16:58.18Kobazthat's why a generic statement like 'sending to the polycom channel' is not clear
16:58.22Kobazneed perspective
16:59.08Kobazso 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.09SamotThe perspective is from within Asterisk
16:59.26SamotAnd the channels themselves.
16:59.28Kobazthen that statement is inaccurate, if the perspective is asterisk
16:59.30filebecause upon answer the channel was connected to something else.
16:59.38filewhich triggered a connected line update.
16:59.42Kobazah
16:59.59filethat's how connected line update works, you get connected to something else then it updates, unless you tell it not to
17:00.04Kobazright, true
17:00.30Kobazbut... i'm saying connected line updates from trunk-bob are untrusted
17:00.36Kobazso anything there should not be passed through
17:01.06Kobazand. 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.11fileoy
17:01.15*** part/#asterisk sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com)
17:01.22Kobazwhich leads me to believe this is not related to a connected line update coming in and being passed to the phone
17:01.29filethe option in the endpoint controls remotely provided connected line updates
17:01.44filethe 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.48Kobazsure
17:02.06Kobazand then, my question is now.. which i don't think anyone knows at this very moment
17:02.16fileand 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.23filethus upon answer a connected line update would occur to update to that
17:02.31Kobazis... precisely why is the connected line update based on the dialplan extension that Dial() is exec'd from
17:02.45Kobazyeah fallback logic, like you mentioned
17:03.21Kobazso 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.30Kobazt it use CONNECTEDLINE that was just set
17:03.37*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
17:03.50SamotYou're missing the UPDATE part.
17:03.59SamotIt *did* use the CONNECTEDLINE you set.
17:04.10SamotThen the other side answered and updated it.
17:04.11Kobazonly if i tell Dial to ignore any future updates
17:04.13fileif you want it to use the value you've set, then set the 'I' option so nothing can override it
17:04.14Kobazno
17:04.20SamotNo.
17:04.24SamotStop.
17:04.30SamotJust stop.
17:04.31KobazSamot: you're missing the point where, it doesn't matter what happens at all on the 'other side'
17:04.35SamotStop.
17:04.48KobazIf i move the 'Dial' from 's' to 'y' or to '1234' extension, THAT is my connected line update
17:04.54KobazSamot: I have my answer from file
17:04.54SamotJust wait.
17:05.10SamotYes, using I in Dial()
17:05.10fileyou could probably set a callerid value on the dialed leg in maybe the pre-dial handler, that might do something
17:05.14SamotTo ignore updates.
17:05.18Kobazfile: tried that :(
17:05.29filewhat did you try explicitly?
17:05.43Kobazpredial callee handler, set CONNECTEDLINE
17:05.49filethen shrug
17:05.53Kobazwhat i didn't try is predialcaller handler
17:05.58Kobazconnectedline is really on the caller channel
17:06.23fileconnected line on the caller channel changes as a result of the called channel.
17:06.33KobazSamot, 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.45Kobazcorrect, and then if there are no changes on the called channel...
17:06.50Kobaznothing should happen in theory
17:06.54filethere are changes on the called channel.
17:06.55SamotIf you call from your Polycom and call Voicemail...
17:07.00Kobazand it should use whatever connectedline it had before
17:07.08SamotYou set CONNECTEDLINE before going to VoicemailAdmin
17:07.16SamotThe voicemail system doesn't do updates
17:07.20Kobazcorrect
17:07.24fileit will be updated to be whatever it is connected to upon answer
17:07.26SamotSo your phone's connected line details don't change.
17:07.33SamotThey are whatever you set CONNECTEDLINE to
17:07.37Kobazcorrect
17:07.39SamotAnything is like that
17:07.41SamotIVR, etc
17:07.54SamotBecause it's Polcyom -> Asterisk.
17:07.58SamotIt's one channel.
17:08.17SamotOnce you introduce a second channel, and that answers it will update the *first* channel.
17:08.21SamotIf allowed so.
17:08.42Kobazlet 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.52KobazOr... do we need an new option to Dial() to control the fallback behvior
17:09.20Kobazno updates from the 'far-end' on a Dial(), fall back to CONNECTEDLINE
17:09.32filethat is not a behavior that is going to change without an option
17:09.39fileas it has existed for a SUBSTANTIAL amount of time
17:09.43Kobazokay fair enough
17:10.03fileand 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.13Kobazyeah
17:10.45Kobazmy 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.50Kobaz(so far that I see)
17:11.07SamotI use this.
17:11.09Kobazthere still could be some ways around this, but yeah defintely would be some behavior differences
17:11.18SamotWhen a calls leaves the PBX to the PSTN, I don't do updates
17:11.37SamotI tell it what it should be and don't let it get updated by the other channel.
17:11.42Kobazright
17:11.57SamotLocal calls are different because all that is already set in places.
17:11.57filethere are also hooks for controlling/manipulating connected line updates.
17:12.00Samotendpoints, etc
17:12.09Kobazfile: aah that may work
17:12.27Kobazbecause, here's what happens for our SLA
17:12.30SamotI also think what might help here....
17:12.36Kobazsomeone 'picks up a line', and they are talking to.... someone on the pstn
17:12.48Kobazso i CONNECTEDLINE update the phone to say, you're in with 2121231234
17:13.03SamotYou realize that "asterisk 16 weirdness" is really the fact you've jump 5 majors versions over which major changes where made.
17:13.07Kobazhaha
17:13.08Kobazi know
17:13.15SamotARe you sure?
17:13.21SamotI'm asking this seriously.
17:13.35KobazTo me, it's weird behavior, for sure
17:13.39SamotBecause yesterday with your goSub problem it was Asterisk 16 weirdness and you started going through app_stack code....
17:13.46KobazLike, I wouldn't expect the connected line to set based on the extension
17:13.54SamotAnd the real issue was a lack of Return() in dialplan.
17:14.02KobazSamot: which i found, based on looking at app_stack
17:14.09SamotBut that's standard
17:14.12SamotNot Asterisk 16
17:14.15SamotThat's just gosub.
17:14.16Kobazsure
17:14.46Kobazit 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.49Kobazso it didn't generate the return
17:14.56KobazSo, chain of events...
17:15.17KobazThis one place specifically checked for version = "11" so... that was the problem
17:15.36Kobazbut anyway, that's neither here nor there
17:17.04Kobazso, where's seanbright to tell you to stop arging with me now :)
17:17.20SamotI'm not aruging.
17:17.25Samotarguing
17:17.29Kobaz[2021-02-27 12:04:30] <Samot> Just stop.
17:17.49SamotThat was to get you to stop typing so I could have you follow what I was going to say
17:17.54SamotYou know, pay attention.
17:18.24SamotI was not arguing in that case, I was telling you to shut up. :)
17:18.27Kobazi was following you, it was just not what i needed.   file got to the bottom of the thing i'm running into
17:18.48SamotYes, because as soon as he commented my next comment was "Yup, that was the next thing"
17:18.54SamotIt was like I was going in an order..
17:19.03Kobazheh
17:19.39Kobazthese more technical discussions just get... oddly heated
17:19.52SamotWell..
17:20.07SamotYou come at these with "asterisk 16 weirdness"
17:20.16Kobazand it's weird!
17:20.21Kobazbut, i'll come to live with it
17:20.28SamotThen it's just general stuff that anything > 11 has.
17:20.31Kobazi didn't say it's broken, just weird
17:20.38SamotIt's not Asterisk 16
17:20.46SamotIt's the fact it's > 11
17:20.49Kobazokay i'll be more specific next time
17:21.00SamotThat's my only point here.
17:21.01KobazI'll say, "wow this is weird post-asterisk-11 stuff going on right up in here"
17:21.12SamotYeah, that could be it.
17:21.57KobazI'll make sure I prepend all my questions with that... just for you :)
17:22.04SamotWait till you got to 18 with the new codec handling.
17:22.12Kobazsounds fun
17:23.33SamotThere is a reason that we are on even releases for TLS now.
17:23.39Kobazyeah
17:23.50SamotBecause what was introduced in 14 still was being worked through in 15.
17:23.56Kobazyup
17:24.08SamotSo 12 saw big updates.
17:24.18Samot14 say big updates that rolled into 15
17:24.26Samot17 introduced stuff
17:24.39Kobazyeah, even though i don't use the stuff in production yet, i follow the dev a bit
17:25.48SamotI had a learning curve with chan_pjsip too. I didn't jump to it right away...
17:26.11Kobazyeah this has been a few months going, several actually.. since about october
17:26.18SamotHowever, the timeframe in which to flatten that learning curve for people without being caught in a mess is shortening.
17:26.44SamotChan_SIP has to sword of Damocles hanging over it
17:27.28Kobazchan_sip is buckets of fun
17:28.12KobazI 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.17Kobazand 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.54Kobazit's going to be buckets more fun when we get into video
17:57.14igcewielingKobaz: 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.44Kobazyeah
17:57.49Kobazwell, it's some of that, and some... new workarounds
17:58.54KobazLike, from the previous conversation: I really want connected line to be left alone unless there's an update from the far-end
17:59.30Kobazbut I have enough now to start to try and figure that out
18:01.24Kobazand I also understand my use cases are like .001% of the population that does the stuff I do
18:01.44KobazSo I appreciate all the feedback even if it gets toasty in here
18:03.06igcewielingMy stuff is pretty basic.   Route calls.  That is pretty much it.   I don't even have voicemail on my non-FreePBX boxes.
18:04.25Kobazhehe
18:04.56KobazI miss oej.  He always was working on the edgiest of edge cases
18:06.09igcewieling*nod*  I think he got lost in some sort of SIP forwarding loop and was thrown into an adjacent universe.
18:09.33Kobaztoo many forks
18:11.12igcewielingThe older I get the less cutting edge appeals to me.
18:13.22*** join/#asterisk TriJetScud (~TriJetScu@23.172.144.5)
18:15.21Kobazi broke it
18:15.22Kobazhmm
18:15.43SamotBroke what
18:16.10Kobazattended transfer
18:16.42KobazI was doing a playback in a local channel and then transferred the call
18:16.47SamotThe incall feature?
18:16.54Kobazsip replaces, with two legs
18:17.10Kobazgonna try and reproduce here in a moment
18:17.31Kobazhttps://dpaste.com/8ULLL4Q76
18:18.09Kobazyup
18:18.12Kobaz100% repproducable
18:18.56Kobazhttps://dpaste.com/BTXP6XCYS
18:20.04Kobazlocal 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.08igcewielingSamot: when you disconnect TNs with Bandwidth.com, how long does it take to apply?
19:30.37SamotNot to long. Not sure the exact time frame. It's rare I release them back.
19:36.59igcewielingI 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.21igcewielingI'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.37KobazSamot: my stuff broke it, not an asterisk bug
21:17.58*** join/#asterisk GandalfCorvotemp (5d28d1ff@93-40-209-255.ip40.fastwebnet.it)
21:18.07GandalfCorvotempHi guys!
21:19.08GandalfCorvotempbest 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.01Kobazthat's a good question.  you would need to make the client reinvite using the wan ip on mobile
21:23.00GandalfCorvotempbut client should do this on it's own when detecting the network change ? Do you know any client able to do this ?
21:23.52KobazThat I don't know
21:24.04KobazYou would need to see if linphone supports that, otherwise ask for a feature request
21:25.02Kobazbelledonne does paid features/addons, if that's what you need... it's not cheap
21:25.47GandalfCorvotempso, it's a client side issue, nothing to do with asterisk
21:26.46Kobazcorrect
21:27.09GandalfCorvotempbut if the connection is closed during the switch , how can I send a reinvite on a closed session ?
21:27.30KobazYou can't, it has to hook into the wifi going off event on the phone, and reinvite prior to losing connection
21:28.23GandalfCorvotempi don't think would be possible. if you loose the wifi connection , the even is triggered when the connection is already lost.
21:29.25KobazIf someone is interactively switching, that might be an an option
21:29.40KobazI don't do any mobile development, but i know some generic stuff about it
21:30.04GandalfCorvotempsure, but not in my case. i need to keep the call on when user is moving outside wifi coverage
21:30.52SamotThen you need to spend money.
21:31.06*** join/#asterisk sadsnork (~sadsnork@ns500513.ip-192-99-6.net)
21:31.13GandalfCorvotempfor what ? what's the solution ?
21:31.14SamotNative SIP in Android isn't going to cut it.
21:31.50KobazGandalfCorvotemp: it's going to involve some deep mobile development.  I'm sure it's possible
21:32.07SamotIt is
21:32.30KobazAs 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.36SamotBut generally at the enterprise/provider level
21:33.05KobazIt does help to have support from the provider
21:33.16GandalfCorvotempAFAIK, mobile data are off when wifi is connected. and even an IP switch from the mobile carrier would drop the call
21:33.17SamotBy provider i just mean a voice platform
21:33.18KobazMobile providers do this with wifi calling -> mobile calling because they ARE the network
21:33.49SamotAnd because they have their own firmware
21:33.54Kobazyup
21:35.00SamotBut this is more than just SDP updates
21:35.16SamotThe contact is going to change
21:35.17KobazSamot: 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.49Kobazwelcomes myself to Asterisk-2021
21:44.32GandalfCorvotempsiproxyd could help ?
21:44.51KobazGandalfCorvotemp: no
21:45.15GandalfCorvotempthe 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.17KobazGandalfCorvotemp: 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.27GandalfCorvotempok
21:45.36Kobazif the call is gone, the call is gone
21:45.39*** join/#asterisk TriJetScud (~TriJetScu@23.172.144.5)
21:45.54Kobazwifi has lost the call, it needs to be taken up on the mobile-data side, by the phone prior to switching
21:46.21GandalfCorvotempclear
21:48.01Kobazand if you want to use a sip proxy, use a commercial-grade one like kamailio/SER/OpenSIPS
21:48.36GandalfCorvotemptnx for the clarification
21:48.36Kobazsiproxyd is someone's pet project with limited development... not saying that's bad, but I wouldn't use for business
22:05.33Kobaznow i gotta figure out how to get individual details out of bridge and channel snapshots and i'l golden
22:17.44Kobazbeautiful
22:17.46Kobaz[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.12KobazI <3 channel snapshots
22:19.15igcewielingthat is a very useful message.
22:19.28igcewielingwhere is the logid?
22:19.57Kobazi know :(
22:20.12Kobazthis is handled out of band from the channel thread, so it doesn't have the call-id
22:20.18Kobazbut i'm going to add that in
22:20.27igcewielingthat is a problem for other parts of Asterisk stoo.
22:20.31Kobazyup
22:20.38Kobazigcewieling: yeah, i've had code for showing that message since asterisk-11
22:20.50KobazI feel bad I didn't get that comitted sooner because it would have been already in 16
22:21.47KobazI'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.50Kobazuhh, not possible?  haha
22:22.39Kobazit was possible to track transferred calls in asterisk 1.4 (it was NOT easy at all)
22:22.54igcewielingI am very glad I don't have to deal with transferred calls.
22:24.07igcewielingCan't you track them using CEL events?
22:24.29KobazCEL wasn't always a thing
22:24.34Kobazbut yeah you could in theory
22:27.03Kobazspeaking of log id
22:27.04igcewielingI use CEL for "basic" logging.  The call events part of this https://imgur.com/Gm0Dsry.png
22:27.09Kobazfeel free to test this
22:27.32Kobazhttps://gerrit.asterisk.org/c/asterisk/+/15547
22:27.43KobazI just pushed that up this morning
22:30.12Kobazif you like call ids, you'll like that change
22:36.48Kobazadded some more logging
22:36.59Kobaz-- <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.19Kobazthat's if you're basically blind transferring via attended/replaces
22:37.27Kobazthe called channel is still in Dial()
22:37.40Kobazand then if the called party answers, and THEN you transfer, you get
22:37.49Kobaz-- <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.23Kobazthe 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.27Kobazso cool

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.