IRC log for #asterisk on 20210105

00:21.20*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
00:41.44*** join/#asterisk Grommish (~quassel@74.215.155.80)
00:45.03*** join/#asterisk ckb__ (~ckb@unaffiliated/ckb)
00:55.27*** join/#asterisk erichowey (uid462861@gateway/web/irccloud.com/x-kllkncuczspcjaiu)
00:56.07KobazSamot: correct, the media is the first matching tls transport
00:56.25KobazSamot: which is not the correct transport to talk to the endpoing on, considering it's talking to asterisk on wan2
00:56.29Kobazand only wan2
00:57.14KobazDeeewayne: I would like to follow your issue.  We use local channels extensively
01:02.21SamotKobaz: Have you done an endpoint to endpoint test?
01:02.33KobazSamot: why add complexity?
01:02.42SamotOr endpoint to pstn
01:02.50KobazIf Endpoint<->Asterisk isn't working... why would Endpoint<->Asterisk<->Endpoint be any better?
01:03.04KobazBut no, I haven't tried that
01:04.16SamotHave you left a voicemail?
01:04.31SamotSet up a DTMF test?
01:04.41KobazNo, but... what would be the purpose?
01:04.58KobazTo see if the wrong transport is being used when executing something other than Playback()?
01:05.01SamotMake sure audio was getting to the PBX
01:05.22SamotThe others would be to see what transport is used for the two channels
01:05.30KobazMy plan was to work on one problem at a time
01:06.09SamotSo two endpoints using wan2 have the right source for RTP
01:06.22KobazI can try that for sure, but... I'm curious... how would that help solve the issue with the media address source being wrong for the conversation?
01:06.27SamotThese are to help troubleshoot the issue
01:06.42SamotBecause right now one side is Asterisk
01:06.47KobazRight
01:06.49SamotNot two endpoints
01:07.03KobazTwo endpoints would result in two sip conversations using the wrong media address
01:07.11KobazI'm not sure what we're trying to figure out with that sort of test?
01:07.20SamotSo the sourcing from wan1 can be fine from the asterisk side
01:07.34SamotAnd youre hunting snipes
01:07.43KobazAre you saying, having asterisk call the endpoint?
01:08.27KobazRight now the endpoint is calling asterisk
01:09.15KobazI just really don't see the reason to do any other kinds of testing other than this test I have.  Because we're looking for a root cause.  And the root cause here is the base case of "asterisk is not using the correct media source ip"
01:09.30KobazWe know what the issue is
01:09.49SamotOK
01:09.58SamotHow about this, set the transport in the endpoint.
01:10.06KobazNow the next step is... 1) does configuration fix this?  2) is this expected behavior?  3) is this a bug?   4) if this is a bug, how do we fix this
01:10.07SamotSet it specifically to WAN2 transport
01:10.09SamotTest.
01:10.13Kobazright
01:10.30Kobazthat's a good test, but doesn't solve the issue.  But sure.  I'll show you debugs on that if it doesn't work
01:11.13SamotKobaz: Sometimes you have to do things before figuring out the solution to the issue.
01:11.21KobazSure
01:11.25SamotKobaz: Prove out theories.
01:25.57KobazI don't know why, but when I reloaded, nat stopped working
01:26.04KobazIt's sending media back to 192.168.5.80 now
01:26.24Kobazgoing through config diffs now to see what changed in between
01:26.26Kobaz...not much
01:32.52SamotReloaded or restart?
01:34.15Kobazwell, both
01:34.22Kobazat various points
01:35.38SamotShow a call that doesnt work
01:38.18*** join/#asterisk pchero (~pchero@211.178.226.108)
01:42.38Kobazso weird... all of a sudden pj is sending the wrong public ip  for media https://dpaste.com/BRPQ8SRSQ
01:43.07SamotShow your transports again
01:45.02Kobazhttps://dpaste.com/AJHKS432E
01:47.50KobazOkay, got it
01:48.06KobazI had left in a local_net from trying an experiment
01:48.29Kobazthat was the only difference that would affect that, comparing the before and after
01:48.53Kobazbut, that seems broken... the local_net has nothing to do with my client's private lan, yet it wasn't treating it as 'nat'
01:50.28Kobazholy crap
01:50.29Kobazit works
01:50.39Kobazso, this scenario is supported
01:50.40Kobazholy crap
01:51.05Kobazsymmetric_transport   When a request from a dynamic contact comes in on a transport with this option set to 'yes', the transport name will be saved and used for subsequent outgoing requests like OPTIONS, NOTIFY and INVITE.
01:51.20KobazWhich is really surprising because -dev was saying this was not supported
01:51.47Kobazthat there was no way for pjsip to 'remember' which transport was used for the conversation and use the correct transport for the return path
01:53.18Kobazbut, given you can define multiple transports, you would think it's a given, to be able to know which transport to use in which situation... otherwise it's only useful in very specific situations, where you know all the transports ahead of time and statically map that
01:53.31Kobazwhich is probably fine for dealing with ITSP and static trunks, but not for any kind of roadwarrier setup
01:54.31KobazSo the only other remaining issue is: why does setting local_net=192.168.181.0/24  and talking to an endpoint 'claiming to be' 192.168.5.80... why this breaks NAT (rewrite_contact) entirely
01:56.40SamotWell I would need to see a full call.
01:56.57KobazYeah, sure
01:56.58SamotBecause rewrite_contact is for the endpoint sending messages to Asterisk
01:57.26Samotlocal_net is for when Asterisk is to set the external_media or not to set it.
01:57.30KobazLet me break it again
01:57.31Kobazsorry
01:57.37Kobazi meant rtp_symmetric
01:59.39Kobazokay so
01:59.41Kobazhere's the transport
02:00.16Kobazhttps://dpaste.com/8RJJ749B2
02:00.19Kobazright... basic stuff here
02:01.01Kobazthe only difference between working and not working is: local_net = 192.168.181.0/24
02:01.04SamotFirst, allow_reload is not the best thing.
02:01.18SamotSecond, let's see the broken call
02:01.18Kobazi've been doing a lot of experimenting with allow_reload and having some good results
02:01.22Kobazright, that's next
02:03.43Kobazhttps://dpaste.com/EU357FFBX
02:04.07Kobazline 125 is the culprit
02:04.21KobazAsterisk is like. uhhh, sending the internal ip out to the world for media
02:05.05KobazI have no reason for local_net in the wan-tls-*, so that's coming out, but.. something's not right at all.  chan_sip would handle that just fine in this situation
02:12.34SamotAdd your PBX subnet
02:12.38SamotTest again
02:13.11Samotlocal_net=10.13.13.0/24
02:13.16KobazAh, that could be
02:13.21SamotOr whatever netmask it is
02:16.18Kobazokay well
02:16.22KobazIt's not perfect
02:16.25KobazBut it's better
02:17.58SamotWhat does that mean?
02:18.14KobazRestarting, and trying another set of tests... but
02:18.35KobazTwo way audio is working on both wan1 and wan2, buuuuut.  Outgoing RTP is still only coming from WAN1
02:19.43KobazYeah, definitely talking to asterisk on wan2.  rtp is being sent from wan1.  And BYE's aren't being handled properly
02:19.52Kobazyeah it's a transport issue... the peer goes unreachable
02:20.02SamotWhen you say "WAN1" which IP are you referring to?
02:20.07Kobazthe first one
02:20.09SamotThe 10.13.13.x?
02:20.13SamotOr the actual WAN IP
02:20.20Kobazwell, internally
02:20.30KobazWhat I care about is 10.13.13.38 vs .39
02:20.32SamotOK so it's using eth0 vs eth1
02:20.39SamotNothing to do with the WAN side.
02:20.43Kobazno it's aliased
02:20.49Kobazits eth0 vs eth0:1
02:20.56SamotOK.
02:21.09KobazWell, the wan side (firewall) maps .38 to wan1 and .39 to wan2
02:21.12SamotYou knew what I meant.
02:21.13KobazIt's source routing for me
02:21.14KobazYeah
02:21.29KobazJust so you know more of the specifics in the lower level
02:22.00SamotAnd it still sources with the transport specifically setup from the "wan1" internal IP?
02:22.06Kobazthe firewall is source routing for me. If i send packets from .38, It will source it for wan1, etc
02:22.09KobazRIght
02:22.17KobazAnd... i don't have transport= defined for this endpoint
02:22.21Kobazas recommended by file
02:22.27SamotI understand that
02:22.30Kobazso that asterisk can pick the correct transport
02:22.33SamotI said a while ago to set it and test.
02:22.39KobazRight, was doing that as well
02:22.54SamotIf you define the wan2 transport, does the RTP source from the WAN2 internal IP?
02:22.57SamotYes/no?
02:23.09KobazSure does
02:23.16SamotOK.
02:23.29SamotAnd the symmetric_transport doesn't solve it?
02:23.32Kobaz21:23:06.484340 IP 10.13.13.39.16598 > .....
02:23.36Kobazwell
02:23.42Kobazsymmetric_transport did *something*
02:23.49SamotWhat was that something?
02:23.50Kobazbecause two way audio wasn't working at all before, on wan2
02:24.00KobazYeah, two way audio is the something
02:24.23SamotBut the audio was always sourcing from the wan1 IP
02:24.23Kobazso i'm going to back that out and re test
02:24.29Kobazright, looks to be
02:24.44Kobazin every single test, unless specifically setting transport to wan2, it uses 1
02:29.08SamotFrom endpoint to Asterisk
02:29.23SamotSo now you test endpoint to endpoint
02:29.29SamotDoes it happen there?
02:30.40KobazI'm not going to bother with multiple endpoints if one endpoint doesn't work
02:36.28SamotExcept the other side *isn't* Asterisk
02:36.32SamotIt's *not the same*
02:36.36SamotIt's a *different test*
02:37.22SamotIf two endpoints over WAN2 talk to each other where is the RTP sourcing from?
02:37.35SamotFrom *each side*
02:38.33*** join/#asterisk tsal_ (~tsal@i59F52FB9.versanet.de)
02:41.05Kobazright, it's a different test.  One that doesn't help isolate a root cause for this siutation i'm trying to fix
02:41.40SamotIt doesn't?
02:41.47KobazAnd I agree, it's not the same.  Which digs a different rabbit hole.  When testing it helps to keep your environment the same and compare actual apples to apples
02:41.54KobazNo, it doesn't
02:42.03SamotYou mean if this doesn't happen endpoint to endpoint and only happens endpoint to Asterisk
02:42.11SamotThat means it didn't help isolate the issue to just that?
02:42.26KobazIt will happen endpoint to endpoint, because B2BUA
02:42.52KobazI can guarantee that 110%.  I don't need to test for that, since obviously it's going to happen with two endpoints, because it happens with one
02:42.59SamotSo what is the issue with it sourcing from the other transport?
02:43.07SamotOK
02:43.07KobazWan1 being down?
02:43.13SamotUhm.
02:43.33KobazIf endpoints are talking to me on wan2.  That means wan1 is down
02:43.54KobazAnd if asterisk is sourcing from .38... the firewall is going to source route out to a dead link
02:44.38SamotYeah, I do this with a medical office they only have one LAN IP.
02:44.41*** join/#asterisk spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net)
02:44.51KobazThis site has two
02:44.54SamotLAN
02:44.56SamotTwo WAN
02:44.59SamotOne LAN
02:45.03SamotDoes failover
02:45.28Kobaz<PROTECTED>
02:45.30KobazBut... What do you do.  Have externip updated when something bad happens to one link?
02:45.48SamotNo, the firewall deals with it.
02:46.14Kobazbecause that's how I typically do it.  You ping out both interfaces, and if one is down, you change externip
02:46.48KobazThis isn't your typical hard-cut situation where the wan goes down and everything switches
02:46.59Kobazthere's load balancing going on, and this also handles peering problems
02:47.10KobazIf level3 goes down and people can'
02:47.18SamotWhat peering problems?
02:47.23Kobazt reach wan1 in half the world, but the other people still can, it'll route in
02:48.08Kobazit's basically active/active
02:48.22SamotWhat does peering have to do with that?
02:48.34Kobaznothing, just saying it's a way to deal with peering issues
02:48.40SamotWhat kind of connections comes into this place?
02:48.49Kobazradio station, tv stuff
02:49.13Kobaztwo 10gbe pipes right on the backbone
02:49.49SamotAnd you don't have a firewall that can handle this?
02:49.57SamotWow.
02:50.37KobazThe firewall is handling load balancing and source routing
02:50.45SamotRight
02:50.54SamotBut it can't handle the SIP stuff
02:51.05KobazAnd sip ALG was being problematic so we're doing that internally
02:51.17KobazNext vendor update isn't for a while
02:51.22SamotOK.
02:52.10SamotJust curious, what firewall?
02:52.25Kobazi'll have to dig my notes, i don't have that in front of me
02:57.45*** join/#asterisk leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage)
02:57.45*** mode/#asterisk [+o leifmadsen] by ChanServ
03:19.08Kobazwell, i think I'm done for tonight
03:19.27KobazI think the issue really is lack of the rtp engine knowing about symmetric_transport=yes
03:19.29*** join/#asterisk tsal (~tsal@i59F5247A.versanet.de)
03:19.33Kobazwhich is what file said is probably the problem
03:42.44*** join/#asterisk electronic_eel (~quassel@213.240.182.71)
03:55.04*** join/#asterisk tsal_ (~tsal@i59F5F068.versanet.de)
05:04.17*** join/#asterisk waldo323__ (~waldo323@d149-67-45-83.clv.wideopenwest.com)
05:06.30*** join/#asterisk ckb__ (~ckb@unaffiliated/ckb)
05:41.56*** join/#asterisk tsal (~tsal@i59F5FB43.versanet.de)
06:46.46*** join/#asterisk hfb (~hfb@cpe-75-82-92-216.socal.res.rr.com)
07:10.23*** join/#asterisk Cory (~Cory@unaffiliated/cory)
08:03.41*** join/#asterisk retentiveboy (~retentive@c-24-125-16-104.hsd1.ga.comcast.net)
08:35.36*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
08:39.20*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
09:09.10*** join/#asterisk zapata (~zapata@2a02:1748:fad4:7260:a00a:448f:cff9:bd35)
09:37.26*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
10:43.45*** join/#asterisk sinaowolabi (~Sina@169.159.80.79)
10:44.45*** join/#asterisk sinaowolabi (~Sina@169.159.80.79)
11:53.41*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
12:54.08*** join/#asterisk TandyUK (~admin@TandyUK/staff/James)
12:57.26*** join/#asterisk EmleyMoor (42b789682f@firthpark.tinsleyviaduct.com)
13:22.56*** join/#asterisk rah (rah@verain.settrans.net)
13:24.36rahI'm trying to limit my asterisk to just TLS but it's listening on port 5060 even though my sip.conf has udpenable=no and tcpenable=no
13:24.47rahhow do I disable port 5060?
13:27.25Kobazdo you specifically need chan_sip?  the new wave is pjsip
13:29.11SamotWell TLS requires TCP
13:30.28Kobazbut you shouldn't need to bind to 5060, but tcpenable would be counterproductive, yeah
13:30.40Kobazrah: you can firewall off 5060
13:34.50Kobazer... 'turning off tcpenable' would be counterproductive
13:42.41rahKobaz: I'm moving my configuration from an existing setup to a new server, I'm not interested in making big changes like changing to pjsip right now
13:43.26rahKobaz: I can firewall off 5060 but that just works around the problem, I'd rather solve the problem and not need to work around it
13:44.59rahcan anyone suggest how to stop asterisk from listening on port 5060?
13:46.41KobazI'm not sure if you can with chan_sip
13:46.42rahSamot: are you just making an observation about Internet protocols, or are you saying that in asterisk, tlsenable=yes also turns on tcpenable=yes?
13:47.15Kobazrah: it would be a reasonable assumption that tcpenable=no would prevent any kind of tcp from binding
13:47.22Kobazbut, you can try it?
13:47.35KobazI've never tried to turn off 5060, so that's something new
13:47.43Kobazat least not with chan_sip
13:47.46rahKobaz: I already told you I have tried it
13:47.54rah13:24 < rah> I'm trying to limit my asterisk to just TLS but it's listening on port 5060 even though my sip.conf has udpenable=no and tcpenable=no
13:48.28Kobazthat's pretty much it in terms of enable options for those protocols, unfortunately
13:48.34Samotrah: Im making the observation that TLS is over TCP
13:49.30rahactually, there's been a misunderstanding
13:49.46rahit's not listening on tcp port 5060, it's listening on udp port 5060
13:49.54rahbut the same logic applies
13:50.05SamotShow your sip.conf with all these settings
13:50.39Kobazmaybe..... udpbindaddr=
13:50.41*** join/#asterisk sinaowolabi (~Sina@105.112.38.30)
13:50.44Kobazset to empty?
13:51.18rahthis is the general section of sip.conf: https://paste.debian.net/1179793/
13:53.18rahKobaz: setting an empty udpbindaddr doesn't fix it
13:53.31rahI think a bug is in order
13:53.45Kobazchan_sip wont really get changes like this
13:53.50Kobazno one wants to work on it
13:54.00Kobazyou can try though
13:54.14rahat least the issue will be known then
13:55.36Samotrah: Chan_SIP is dead.
13:55.43Samotrah: Within the next few years it will be removed.
13:55.48Samotrah: No one is working on it.
13:57.04filechan_sip doesn't support disabling UDP
13:59.20Samotrah: Also show us what is listening on the server. Show us TCP isn't being used
14:04.52rahfile: what does udpenable=no do?
14:05.00filenothing
14:05.01fileit doesn't exist
14:05.10rahO_o
14:07.27rahfile: is there a list of options that sip.conf accepts?
14:07.53seanbrightconfigs/basic/sip.conf.sample should have most of them
14:07.57rahSamot: proving to you that I can read the output of the ss command won't help solve the problem :-)
14:08.03filethere's the sample configuration file and the code
14:08.07rahseanbright: so that's a "no"? :-)
14:08.17Samotrah: No but it proves to us YOU are reading it right
14:08.22rahso just the code, right
14:08.30Samotrah: You're being very problematic for someone seeking help
14:08.45seanbrightproblematic is not the right word
14:08.47seanbrighthe's being a dick
14:08.52rahSamot: what I'm saying is that doing that won't help solve the problem so there's no point in me wasting my time
14:08.53seanbrightstop being a dick
14:08.54SamotI was being nice.
14:08.59rah*I* know I can read the output of ss
14:09.03Samotrah: So there's no point in us wasting the time.
14:09.09rahexactly
14:09.16seanbrightyou cannot disable UDP in chan_sip
14:09.17Samotrah: You ask for help and then fight over the help being offered/given.
14:09.28SamotI'm so sick of that shit.
14:09.30rahSamot: O_o
14:10.38rahseanbright: I see, thanks
14:10.48seanbrightyou're welcome
14:24.19*** join/#asterisk tsal_ (~tsal@i59F52D59.versanet.de)
14:25.20KobazSamot: I really think I do need Kamillio
14:25.30rahmy "Asterisk: The Definitive Guide" doesn't cover pjsip
14:25.36rahwoe is me :-(
14:25.52Kobazrah: Yeah, the book is older
14:27.16KobazKamailio... i should probably remember how to spell it if I'm going to start using it
14:27.53*** join/#asterisk zgu (~steve@2603-7080-b744-4900-16ad-d120-de49-dc8b.res6.spectrum.com)
14:28.40SamotKobaz: What made you come to the conclusion?
14:29.00KobazSamot: asterisk still is not actually properly using the origin transport
14:29.25SamotAnd this is still only testing an endpoint calling into Asterisk with a single channel in use?
14:29.32KobazRight
14:29.35Kobazthe base case
14:29.49SamotBecause that's what they'll mostly being doing?
14:29.53KobazYou get two way audio, yes.  But SIP OPTIONS is going over UDP 5060, if transport is unset
14:29.56KobazSamot: no
14:30.08KobazSamot: but it's the base case.
14:31.58KobazI'm still really confused why my testing scenario isn't satisfactory for you.  Like... if I'm going to test fly an airplane.  I'm going to see if the engine starts first... no?  And then before I get in the air... I will do a taxi test.   And then after that I will do a high speed taxi to make sure my engine doesn't fall off.  And THEN you do ground effect flying.
14:32.20KobazYou test the base case first.  If that doesn't work, you resolve the base case
14:32.28SamotI didn't say the test itself wasn't satifactory
14:32.43SamotIt being the *only* test isn't satisfactory.
14:33.22SamotKobaz: What is this issue persists in other cases? Or doesn't persist in other cases?
14:33.24KobazYou want more testing, but the type of test you want adds complexity and changes the scenario
14:33.38SamotKobaz: If the latter, what will happen when you fix this base case?
14:33.45SamotKobaz: Does that change the latter?
14:34.01SamotChanges the scenario?
14:34.13SamotSo there's no scenario where endpoint-to-endpoint calls will happen?
14:34.21SamotNothing from the PSTN or to the PSTN
14:34.24SamotNothing from user to user?
14:34.27KobazNo the scenario doesn't change unless you say, add an endpoint to the mix
14:34.32SamotNone of those will be a scenario?
14:34.36KobazSure they would be
14:34.50KobazBut if asterisk, talking to one endpoint... isn't sending media or signalling correctly
14:34.54Kobazwhat's the point of testing more endpoints?
14:35.14SamotTo see if the RTP is sourcing from the right interface.
14:35.14KobazB2BUA is still Asterisk<->Endpoint, there's just now two endpoints!
14:35.18KobazIt wont
14:35.21SamotIs the Transports still being done right
14:35.24SamotSo you're 100%?
14:35.35SamotNo f'ing proof but you're 100%.
14:35.50SamotForest for the trees, man. Forest for the trees.
14:36.02KobazI'm using basic logic here... Yes, because why would Endpoint<->Asterisk<->Endpoint work properly if Endpoint<->Asterisk does not
14:36.27KobazWhy would anyone bother testing 10,000 clients hitting a web server, if ONE CLIENT doesn't work ?
14:36.31KobazI really don't get the logic here
14:36.42SamotThat is not a valid comparison.
14:36.42KobazOr 2 clients. Or anything other than one
14:36.52KobazIt's the same level of not-usefulness
14:36.56SamotOK.
14:37.26KobazIf you really want me to test b2bua... sure
14:37.32KobazBut, this is a total waste of time
14:37.35SamotNo, that's fine
14:37.42SamotI don't want to waste your time troubleshooting.
14:39.10KobazI understand it's bridging instead of playing rtp direct to the endpoint
14:39.15KobazThere's different stuff going on there for sure
14:39.43KobazBut if the low level RTP created from the SDP is not working the way it needs to... there you go
14:39.45SamotYou mean like both endpoints locking on the same transport
14:40.05SamotAnd perhaps not defaulting to the *first known transport that matches* like the single channel call.
14:42.42KobazIt's the same behavior
14:43.04KobazI have one soft phone on WAN1 and one on WAN2. Both sets of RTP are coming from WAN1
14:44.48SamotWell why do you need to ether interfaces?
14:44.59KobazBecause one is bound to wan1 and one is bound to wan2
14:45.06SamotWhy?
14:45.10KobazWhy not?
14:45.15SamotWrong answer.
14:45.18SamotWhy?
14:45.19KobazAnd ignoring the why... it should work
14:45.24SamotSigh.
14:45.40filethe code isn't written to work for that specific scenario, it COULD work
14:45.42KobazIf I want asterisk to use RTP from x.y.z.q... I would like to be able to do that
14:45.50KobazYeah. I understand
14:45.53KobazI'm trying to make it work :/
14:46.25KobazI'm definitely understanding this is less of a configuration issue and more of a rtp engine issue, like you indicated it could very be
14:46.39fileit's not an issue in the rtp engine
14:46.49KobazAnd while i'm testing I've been poking at res_pjsip_session.c and res_pjsip_sdp_rtp.c
14:46.56KobazWell the rtp engine can do it... it just needs to be told to do it
14:47.07Kobaz'usage of the rtp engine' issue, sorry
14:48.28KobazHmm... how long these days does a typical post to asterisk-dev take?
14:48.56fileone appeared yesterday?
14:49.04KobazYeah i saw
14:49.06fileusually near instant?
14:49.17KobazYeah usuaully... That's what I thought
14:49.23KobazHmm... I posted about 20 minutes ago
14:53.01KobazOkay. well.  I think we can move on to something that asteirsk is designed to handle well.  Which is signalling.... curious... why would pjsip send OPTIONS to a contact using UDP 5060, when it has registered using TLS ?
14:53.27KobazI can re-share all my configs if needed
14:54.31Kobazand that's with transport unset at the endpoint, and symmetric_transport=yes at the transport
14:56.19filebecause there's potentially a bug in your specific use case with transport selection involving multiple transports?
14:56.47file(theoretically speaking)
14:57.30Kobazfair enough
14:59.47SamotKobaz: Show this endpoint settings again
14:59.56KobazYeah sure
15:00.17KobazAlso, completely random.  And, not a lot of detail.  But wondering if there's some markers here for a known issue.  The first 1-2 seconds of a call the audio is jittery and then it's fine
15:00.33KobazHaven't really started digging into that yet.  It's on the chopping block
15:01.55Kobazhttps://dpaste.com/8ZUPE3GU5
15:04.20SamotAnd the contacts, I want to see the full contact details.
15:04.23KobazThe biggest issue, is... I don't get two way audio on wan2 if transport is unset.  I DO get two way audio if transport = transport-udp
15:05.18Kobaz21005/sip:21005@XX.75.184.42:53326;transport=TLS
15:05.35KobazThat's the one that really matters, i just unregistered the other ones
15:07.09SamotSigh
15:07.12SamotI wanted to see ALL three
15:07.35SamotHas there been three contacts during all this?
15:07.40Kobazno
15:07.43SamotOK.
15:07.57Kobazbeen switching around to various softphones at various places, trying to pinpoint something
15:08.28Samotmedia_use_received_transport=yes <-- have you tried that?
15:09.01Kobazit's been a while
15:09.05Kobazlet me test with my current setup
15:10.22Kobaznope. media is sourcing from wan1 still
15:10.57Kobazso i've been playing with symmetric_transport=yes
15:11.00Kobazhere's what it does
15:11.27Kobaz22045/sip:22045@XX.225.50.173:52917;ob;x-ast-txp=transport-udp
15:11.46Kobazthe endpoint registers, and it saves the original transport
15:11.51Kobaznow... with TLS this does not happen
15:12.05KobazThis might be the avenue to a solution here.
15:12.31Kobazwhen a TLS endpoint registers... you get the earlier contact I pasted.... transport=TLS (generic TLS... not the specific transport)
15:12.37SamotSo that example is the device registering over UDP?
15:12.43Kobazyeah, udp 5060
15:12.49SamotSo this with a TLS
15:12.56SamotThat has the x-ast-txp tag
15:13.08Kobazright 21005 is TLS... and does not set x-ast-txp
15:13.31Kobazwhich, I've been looking at the code.  So far I can tell, if x-ast-txp is set, it will use THAT transport for media as well
15:14.10KobazIf I add a static contact...
15:16.39*** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be)
15:23.01KobazI can't be the only one using asterisk as a multi-homed media gateway
15:23.07KobazHeh.. well maybe
15:23.09*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
15:24.17filein this fashion, I haven't seen anyone else do such a thing, and I haven't seen any complaints regarding these issues
15:24.42filethe vast majority of users don't do stuff like this
15:25.02KobazYeah... I know
15:25.07KobazI'm always breakin stuff :(
15:25.39Kobazfile: thanks for your reply to the list... Typically I get a copy of my own post back to me, but I still don't have one
15:26.33*** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-kjfjmplosmdgpjsl)
15:26.34*** mode/#asterisk [+o kharwell] by ChanServ
15:31.18SamotLike l said, I have this setup at a location
15:31.38SamotDont have two eth interfaces in the PBX
15:32.06KobazYeah, i understand
15:32.25KobazThere's multiple ways to accomplish the goal, and I'm trying to make this one work before I move onto the other ways
15:33.13KobazThe thing that gets lost in translation, without fail on IRC/etc. is all the underlying context (backstory perhaps), and the whats and whys of the setup
15:33.17jkroonhas anyone managed to utilize %C in the ASTERISK_PROMPT environment variable?
15:33.51SamotKobaz no
15:34.00SamotThat is the drivethru attitude
15:34.04KobazIt's really common to join #linux or #debian and be like, okay how do I XYZ... and you have a million people jumping down your throat to not do that.  And then it might take 30 minutes to explain the situation and then they go "ooooh, I see"
15:34.17SamotDont give yoy flack about the setup just solve thenone issue
15:34.32SamotI do this
15:34.41KobazSamot: that's management for you 'solve it, I don't care how'
15:35.08SamotSo when Im asking questions it is because how i have made it work doesnt involve what youre doing
15:35.18KobazSure, understandable
15:35.36SamotSo when I ask why you are doing something, reasons shoukd follow.
15:35.41SamotValid reasons
15:35.49SamotNot "just cuz"
15:35.59SamotBecause that means zero thought
15:36.14*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
15:36.53KobazI have valid reasons.  And I went over them.  I just thought we were going around in circles
15:37.06KobazAnother reason.  I can't change the WAN setup right now
15:37.17Kobazand probably can't for, several weeks/months/never? not sure
15:37.26Kobaz... Not something I control
15:37.36SamotDo the ether ports plug into the same switch?
15:37.44KobazYes
15:37.48Samot.....
15:38.04Kobazvswitch, vmware
15:39.07SamotSo you need it on two local subnets
15:39.08KobazIt's not as redundant as it should be.  Really there should be two SBCs, one on each WAN
15:39.20SamotWhat?
15:39.25SamotNo
15:39.46KobazHave a proper Proxy1/Proxy2
15:39.46SamotIf there are two SBCs one is for failover
15:39.51SamotYes
15:39.59SamotI do that as well
15:41.03KobazBasically, the root of the matter is... *if* asterisk could consistently segment wan1 from wan2 based on which one the contact is using, i would be happy
15:41.20Kobazso, I'm going to play with static contacts, and setting the x- flag for transport
15:41.30KobazIf that fixes it, then I know what to change in the code
15:41.45SamotDo you have local phones?
15:41.55KobazYeah, they are direct to the pbx
15:42.05Kobaz(Asterisk)
15:42.11SamotOne their own subnet?
15:42.26SamotOn*
15:42.30KobazIt's like, 20 subnets, but yeah
15:42.49SamotWhy are all the phones on 20 subnets?
15:42.58SamotLocal ones
15:43.03Kobazlocal-local. one subnet
15:43.08Kobazremote-offices each has their own
15:43.14Kobazand it depends on the floor, and whatever
15:43.23KobazI didn't build that part
15:43.28SamotSo those are not local
15:43.30KobazBut it's working well so far
15:43.41SamotI asked about local
15:43.57KobazEven the LAN, like I said, depending on the floor, subnets
15:44.04SamotSo is the subnet one if the PBXes subnets?
15:44.10KobazOne of them, yes
15:44.13SamotOh jfc
15:45.11KobazDoes this add clarity?  So floor 1 is 182.168.181.x floor 2 is 192.168.182.x
15:45.21SamotNo
15:45.27KobazThe PBX is 192.168.181.5
15:45.33SamotBecause it becomes a why question
15:45.44KobazI don't know the why, I didn't build it
15:46.13SamotSo part of the problem is poor network design
15:46.23SamotJust keep that in mind
15:46.30KobazNow you're grasping
15:46.40KobazThere's no problems with the lan, local or remote
15:46.41SamotNo I am not
15:46.54SamotOK
15:46.56KobazNone of this plays a factor in the sbc asterisk
15:47.09SamotSure it does
15:47.23SamotYou have three subnets on the pbx
15:47.35KobazNo it doesn't.  The sbc talks to the pbx with no issues
15:47.51SamotThen why are there two transports
15:48.03KobazYou can pretend the pbx doesn't exist, for this situation i'm trying to resolve
15:48.24SamotThe one we have been troublesooting?
15:48.32SamotShooting
15:48.36KobazLiterally I'm talking to one asterisk, (the sbc), with a soft phone, over two wans... And that's what I'm working on right now
15:48.46SamotOhhhh
15:48.48Kobazthe pbx is another machine
15:48.49*** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-nkwfibjaliwdoqhb)
15:48.49*** mode/#asterisk [+o bford] by ChanServ
15:48.58jkroonKobaz, i haven't read everything, but it sounds like your WAN/LAN definitions aren't what I would use.  LAN is everything inside your building.  I'm assuming there is no NAT between your different 192.168.*.* networks?
15:49.00KobazTwo pbx machine's actually.  So there's three in total.  PBX-A PBX-B and SBC
15:49.00SamotYoure trying to use asterisk as an SBC
15:49.10Kobazcorrect
15:49.15SamotOk
15:49.21SamotNot its intent
15:49.27KobazI know
15:49.45KobazBut.  Based on what I researched with pjsip options and multiple transports before diving into this. it 'should work'
15:49.52SamotNo
15:49.55KobazAnd I know asterisk very well, Kamailio, not so much
15:50.01jkroonor am I being very confused here ...
15:50.05SamotSBCs are not B2BUAs
15:50.14KobazWell, this one is
15:50.47KobazTo simplify.. and then we'll do reinvites and step out when everything is working as direct connections
15:50.50filejkroon: he has two transports, same subnet, a router which treats traffic differently (goes out WAN1 vs WAN2), but RTP is bound to wildcard so it goes out the default route which is effectively the local IP that is WAN1
15:51.06SamotYup
15:51.12SamotDefault route
15:51.18Kobazjkroon: yeah there's no nat on 192.168.x.x... and you can safely ignore those subnets, we were on a tangent
15:51.26jkroonKobaz, I did some work on RTP address selection a number of revisions back
15:51.40Kobazright it's using the default route, which is fine. and it's also using the 'default interface' on the box
15:51.42jkroonok, so what's the problem here?
15:51.44Kobazwhich asterisk can control
15:51.52Kobazjkroon: thanks for jumping in :)
15:52.15filejkroon: he wants RTP to be bound explicitly to the local IP that corresponds to WAN2 to force traffic to go out via WAN2, but since it's wildcard it goes via default which is local of WAN1
15:52.45SamotChange the order and see what happens
15:52.49seanbrightsource based routing
15:52.58SamotPut wan2 transport first
15:53.03jkroonKobaz, ok, so you need two things:  1 - bind to the IP for RTP (btw, asterisk does really interesting things w.r.t. here, just looking for the gerrit link for my patches but git log will also find them).
15:53.07Kobazjkroon: long story short... I want. endpoint A, using Contact A, when it registers.  To have asterisk note that: 1) Talk to this contact/endpoint on the same transport, and 2) talk to the contact/endpoint using RTP sourced from the media address associated to that transport
15:53.10jkroonsecondly, you need routing.
15:53.23SamotPut wan2 transport first
15:53.30Kobazjkroon: well hold a sec on the routing...
15:53.31SamotRestart and test
15:53.37seanbrightrouting
15:53.40seanbrightwan2 transport
15:53.42seanbrightwords
15:53.43seanbrightthings
15:53.46jkroonso address selection is to a large degree based on host routing.
15:54.00Kobazjkroon: if i explicitly tell the endpoint to use -tls-wan2... address selection will be exactly what I expect
15:54.16Kobazjkroon: correct unles you tell the host to use a specific source
15:54.20SamotDo what I suggested
15:54.34Kobazjkroon: which will happen if transport=tls-wan2... asterisk WILL source the address I want
15:54.37KobazSamot: will do
15:54.55jkroonok, and then you want the ip rule stuff at the OS level?
15:55.03KobazOpposite
15:55.13jkroonok, i'm confused, let me re-read.
15:55.25KobazI want asterisk to tell the OS.. I'm sending from this address.. like ping -I
15:55.55SamotYou do that by the socket binding
15:56.01KobazAsterisk knows the transport, it knows the contact, it knows the endpoint it's dealing with.  Asterisk can the equivalent 'ping -I <WAN2> <DEST>'
15:56.04SamotWhich is in the transport config
15:56.08KobazSamot: correct
15:56.20jkroonSamot, but rtp for pjsip *always* binds the 0.0.0.0 address.
15:56.27KobazRight
15:56.36Kobazand can choose what source ip to use, for any given rtp session
15:56.37jkroonthis is an issue I had too.
15:56.43Kobazperfect
15:56.48KobazOh man. we're on the same page :)
15:56.56jkroonKobaz, it sends *from* 0.0.0.0 and then uses the routing.
15:57.10KobazWell yeah, you're bound already
15:57.15jkroonip ro replace default via a.b.c.d src e.f.g.d
15:57.47KobazI need to avoid OS routing though.  The endpoint can talk to asterisk on WAN1 *or* WAN2
15:57.57Kobazhold on a second... take this example:
15:58.09jkroonyou can look at ice_{acl,deny,permit} in rtp.conf as well to assist with the *advertised* addresses.
15:58.22Kobazdefine an endpoint, set transport=transport-tcp-wan2-tls
15:58.33jkroonbehind the same router?
15:58.37Kobazyes
15:58.42Kobazno OS routing changes at all
15:58.43jkroonrouter type?
15:58.50Kobazand asterisk will set the source ip
15:58.56jkroonhow do you know *when* which route will be used?
15:58.59SamotIgnore tge router
15:59.08KobazYeah this isn't router related
15:59.15SamotI already went down that path
15:59.18Kobazjkroon: Okay. this will make more sense
15:59.35jkroonwell, i'd solve this at the router ... i'm assuming you want to use WAN1 if the client came in on WAN1, and WAN2 if the client came in on WAN2?
15:59.40Kobazjkroon: ... same router (same default gw) is handling both wans
15:59.52Samotjkroon: thats how I do it too
15:59.58Kobazi have IP Aliasing on lAN 10.13.13.38 and 10.13.13.39... WAN1/WAN2 respectively
16:00.03Samotjkroon: this was suggested and shot down
16:00.12jkroonon ingress, add the source IP to ipset, on egress, mark the traffic and rule-based route it.
16:00.14KobazYeah, as of right now I can't handle this at the router
16:00.24Kobazjkroon: I can do that
16:00.26jkroononly problem is if same IP comes in over multiple WAN links :(.
16:00.38KobazYes, that's a possability here
16:00.56SamotStill requires router config
16:01.05jkroonproblem at asterisk routing layer is source address is selected *before* the route rules kick in.
16:01.11KobazI can source route at the OS level
16:01.17Kobazjkroon: can you explain this one though...
16:01.25Kobaz[2021-01-05 10:58:21] <Kobaz> define an endpoint, set transport=transport-tcp-wan2-tls
16:01.40KobazAsterisk will then use .39 (wan2) as the source ip
16:01.51jkroonRTP is STILL BOUND TO 0.0.0.0 unless you set MEDIA-ADDRESS
16:01.56Kobaztransport = undefined... then asterisk will use .38 (wan1)
16:01.57SamotBecause it sets the socket
16:02.14Kobazjkroon: which is fine... i don't care about the bind, i just want the right source address to go out
16:02.16SamotSetting an explicit transport sets an explict socket to bind to
16:02.24KobazSamot: correct
16:02.25jkroonKobaz, to fix it, you need to fix the bind.
16:03.01Kobazwhat I mean is... I don't care if it needs to bind to something else... I know what part of the pjsip code it sets this
16:03.04jkroona bind to 0.0.0.0 uses routign looking (before netfilter kicks in) to determine source address.
16:03.11Kobazcorrect
16:03.12jkroonyou could SNAT the traffic on egress though.
16:03.26Kobazcorrect it will use routing
16:03.34Kobazhere let me show you what i'm talking about
16:03.53jkroonno, it's rtp.c that determines the RTP address, and determines the advertised addresses, and for pjsip this will (currently) always be 0.0.0.0 unless a specific media address is set.
16:03.57Kobazhttps://dpaste.com/23EYGWDUH
16:04.13Kobazyes
16:04.14Kobazexactly!
16:04.22Kobaz'unless a specific media address is set'
16:04.26KobazI want to set this ^^^^^
16:04.37jkroonpjsip has an option somewhere ...
16:04.41KobazBut dynamically, per RTP session, depending on which contact it comes from
16:05.04jkrooni suspect that will require code changes.
16:05.18Kobazi bet
16:05.46Kobazso far, I've found: transport/symmetric_transport
16:05.56KobazWhich looks like a good basis for solving this
16:06.13jkroonand if I recall, even when I set the options, RTP still bound to 0.0.0.0 which is why I cooked the ICE patches anyway (with >32 addresses on a system the PJSIP library clutched out completely)
16:06.35jkroonyea, issues I will still need to solve those :).
16:06.58KobazIt writes a contact like this: 22045/sip:22045@XX.225.50.173:52917;ob;x-ast-txp=transport-udp
16:06.59jkroonfor now, the only way for us to handle some of the use cases is with chan_sip bound to a specific IP address.
16:07.15Kobazjkroon: that's what I was thinking
16:07.28KobazI'll need to run two Asterisk instances, one on each wan
16:07.38jkroonnasty.
16:07.42SamotYeah.
16:07.43KobazI know :(
16:07.52Kobazx-ast-txp=transport-udp  <<<< this is promising
16:07.57Kobazstoring the transport in the contact
16:08.01jkroonwe run >200 asterisk instances per host when degraded, each on a specific IP address.
16:08.08SamotIs that the only udp transport you have set?
16:08.17Kobazno there' two
16:08.21Kobazone is for wan2
16:08.22SamotIs that the first?
16:08.25Kobazthat's the first
16:08.29Kobazyeah let me try the reverse ordering
16:08.33SamotSo did that come in over wan2?
16:08.45Kobazthis one, probably came over wan1
16:08.54SamotYou need to be 100% on that
16:09.00Kobazbut... see the TLS... this one came over wan2 for sure
16:09.02SamotAnd not have a false positive.
16:09.05Kobaz21005/sip:21005@XX.75.184.42:53326;transport=TLS
16:09.06SamotThat's different.
16:09.13Kobazthis one does NOT store x-ast-txp
16:09.16Kobazunfortunately
16:09.17jkroonwe can bind PJSIP to a specific adddres for *transport* (or multiple), but I still need to figure out how to bind the RTP instance, but we're not behind NAT, so we used the ICE acl stuff to restrict the selected addresses to the /28 that's used for host addresses.
16:09.25SamotRight. It's different.
16:09.32SamotI'm asking about the udp ones.
16:09.40jkroonhad to increase the RTP range from the default 10000-20000 to 10000 to 40000 to deal with that though.
16:09.43SamotDoes it set the proper udp transport?
16:09.44Kobazudp.  I didn't really care, but.. that would be interesting
16:09.48KobazI can test that
16:09.48jkroonthe SIP side is easy.
16:09.49SamotOr is it grabbing the first one?
16:10.09jkroonthe issue is RTP (media) side.
16:10.28jkroonif a specific *transport* can enforce a bind to a specific *media* address our issues are solved too.
16:10.44SamotKobaz: Make a connection over WAN2 UDP and see what transport is stored in the tag
16:10.47Kobazjkroon: so, do you agree that, create_rtp().. (or something similar).. where it finds the transport  transport = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "transport", session->endpoint->transport);... would be a good way to fix this?
16:10.57Kobazjkroon: YES!
16:11.10jkroonthe issue we have with the above solution we currently have for pjsip is that many of our clients only look at the hots address and ONLY treat that one address with QOS ... resulting in RTP (going to a different address) to be completely ignored, or in the worst case, filtered.
16:11.19Kobazyeah
16:11.24Kobazin my cast RTP is filtered
16:11.30Kobazbecause it's coming from the wrong WAN
16:12.07SamotKobaz: Are you going to test the WAN2 connection to see which UDP transport is selected?
16:12.13Kobazyeah
16:12.41jkroonKobaz, i think that there are a few settings related to "endpoints" that I'd prefer to have transport specific.
16:12.50jkroonmedia address being one of them.
16:13.03jkroondtls and other similar settings being others.
16:13.14Kobazyeah
16:13.17Kobazexactly
16:13.48jkroonso if client connects using SIP/TCP I want one set of rules, SIP/UDP probably the same (or similar), SIP/TLS a completely different set of rules and for SIP/WS yet another set.
16:13.54Kobazright
16:14.03Kobazhave you worked on this yet?
16:14.27jkroonone way I was thinking at some point was to modify the endpoint name based on transport, but i don't think this will fly reliably either.
16:15.17jkroonand create multiple endpoints for each actual client, eg XXX_{pt,tls,rtc} where XXX is the actual client, use auth=XXX for all of them, and aor=XXX as well.
16:15.26jkroonbut no, i haven't started work on that yet.
16:16.08Kobazendpoint name? hmm
16:16.32jkroonreally I'm thinking that the transport just needs to also have all settings from endpoint as well, and then some way to select priority ...
16:16.48jkroonbut i haven't delved into pjsip code just enough yet to know what makes more sense.
16:17.12jkroonso now, the question really becomes if I set media-address in both endpoint and transport - which one should take preference?
16:18.01jkroonand if media-address is set, then really RTP should bind to that address explicitly - the problem with that is IPv4 vs IPv6 though ... so I want to media addresses, and this means two RTP sockets, which is NOT supported and will be HUGE changes.
16:18.18jkroonso another strategy is to narrow the binding of the RTP socket upon receipt of RTP ...
16:18.40jkroonmany different strategies, and I honestly don't know which one will be best in the long term.
16:18.52jkroonand if you narrow, you need to widen again in some cases ...
16:19.11*** join/#asterisk irrgit (~ch33se@192.241.175.183)
16:19.19Kobazi don't think you need two rtp sockets
16:19.24jkroonand after how much rtp do we narrow?  Ie, do we follow the rtp bleed restriction code stuff?
16:19.36jkroonKobaz, in my case where I have IPv4 + IPv6 I do.
16:20.13Kobazoooh
16:20.14Kobazright
16:20.15Kobazyes
16:20.25jkroonbecause in my SDP I'm going to advertise an IPv4 address and an IPv6 address.  So either  need to retain the common to the host addresses here, or I need to bind multiple RTP sockets.
16:20.33jkroonneither option is very enticing.
16:21.18Kobazah
16:21.18Kobazyeah
16:21.25Kobazwell multiple rtp's sounds like the way to go
16:21.29jkroonin my case I have 1 IPv4 address and 1 IPv6 address per asterisk instance, if you case you have multiple IPv4s which you need to deal with ... two very different scenarios, but possibly related "solutions" (workarounds really IMHO).
16:21.31Kobazand then you bind a transport to an rtp
16:21.52Kobazjust like multiple transports, i can see a need for multiple rtp binds
16:22.00*** join/#asterisk tsal (~tsal@i59F52D59.versanet.de)
16:22.08jkroonwell, that doesn't necessarily work either, since you may not want to preclude IPv6 RTP in the case of IPv4 SIP transport.
16:22.38KobazWhat about linking multipel rtp's
16:22.49Kobazlike multiple contacts... you would add as many rtps as are supported on that transport
16:23.38jkroonand multiple RTP sockets per RTP session is a MAJOR rewrite ... and begs the question - until you've completed selection in the Call (You could have multiple Call's or Session's per endpoint/contact/transport), on which RTP socket do you send?
16:23.56jkroonthere are many, many questions, and I don't think many of them have easy answers btw.
16:24.23Kobazyeah
16:24.30jkroonbut yea, i need to get this back on my todo list.
16:24.51jkroonas things stand currently, I'd solve this with ipsets.
16:26.12jkroonin your case you could mark on a per flow basis, ie, source udp streams incoming to your non-default IP address you add the source ip:port pair into an ipset, and you SNAT/mangle (modify ONLY the source IP, not the source port) on outpoint where dest ip:port is in the set.
16:26.23jkroonhmm, I might have an even better hack for you:
16:27.17Kobazi really don't want to do iproute if there's a (easy) way to do it in asterisk
16:27.52jkrooniptables -t nat PREROUTING -i eth?? -m udp ! --dport 5060 -j DNAT --to-destination prim.ip
16:28.12jkroonthat will result in conntrack entry dealing with the heavy lifting for you potentially.
16:28.22jkroon--dport 10000:200001 might be better.
16:28.39jkroonand this assumes remote side sends RTP first.
16:28.58jkroonagreed with your last statement, but I don't think there is an easy way in asterisk currently.
16:28.59Kobazwouldn't this need to be SNAT ?
16:30.11jkroonironically, no, DNAT on ingress, this creates a CONNTRACK entry for extip:port alt2:port <=> alt1:port <=> extip:port resulting in the return traffc (being sent from alt1) to be deNATed in such a way that you end up with a per-flow SNAT effectively.
16:30.23Kobazah hmm
16:30.42jkroonI originally figured this out with openvpn listening on multiple WAN interfaces (0.0.0.0) with source-based routing.
16:31.09jkroonso ended up changing this so that openvpn binds to LAN side address, then DNAT all WAN traffic to the LAN address.
16:31.47jkroonlater realized it works equally well with 0.0.0.0 as long as you DNAT to the src address selection on outbound route for 0.0.0.0 traffic (so DNAT to lo address that's not 127.0.0.0/8 also works)
16:32.14jkroonmostly try to avoid those kind of hacks with voice because it's damn hard to trouble shoot.
16:32.19Kobazyeah
16:32.24jkroonbut we do use this with STUN.
16:32.32KobazSo... ICE can possibly fix my issue?
16:32.39Kobazto determine the best match for rtp ?
16:32.51jkrooni'd try and use media-address.
16:33.00jkroonif you know over which WAN link client will connect.
16:33.06Kobazi don't
16:33.14Kobazso i'll need a dynamic media-address
16:33.23jkroonthen you're in the same boat as me (for completely different reasons)
16:33.48jkrooncan you get asterisk to at least transmit the correct address in SDP?
16:34.00Kobazyes
16:34.01Kobazit does
16:34.20jkroonok, then possibly the DNAT trick *might* work in your use case.
16:34.37jkroonassuming asterisk waits for remote side to send RTP first.
16:34.43jkroonconntrack -L becomes your friend here.
16:34.57Kobazk
16:35.16jkroongive it a shot, would love to know your final pjsip conig (extract) and netfilter rules.
16:53.21jkroonKobaz, the other issue someone pointed out to me ... but I've not seen practical examples of this ... as it's possible to migrate RTP mid-call, it's also possible to switch SIP transport mid-call.  ie, initially INVITE via SIP/UDP, then later re-INVITE over SIP/TCP.  I've *never* seen a practical or real-world example of this though.
16:53.46Kobazah
16:54.02jkroonor even IP versions, so connect initially with IPv4 then switch to IPv6.
16:54.17Kobazyeah you can reinvite
16:54.50jkroonI *think* the way to handle that if transport options become relevant is to use the options from the transport on which the INVITE was received.  So if at a later stage you re-INVITE, use the transport settings from that updated INVITE.
16:55.24Kobazyup
16:55.25jkroonthis implies though that we have access to the ast_sip_transport on which the INVITE was received when we create the SDP.
16:55.30Kobazexactly
16:56.00Kobazstatic int create_rtp(struct ast_sip_session *session, struct ast_sip_session_media *session_media,
16:56.00Kobaz<PROTECTED>
16:56.09jkroonalso, what do you do, if bind_rtp_to_media_address is true, and you have different addresses for the two transports?
16:56.16Kobazso... I don't have the transport... that's the issue
16:56.28KobazI have the session... and I should be able to pull the SDP and then figure out the transport?
16:56.34jkroonif you can find all callers of that, and check if the transport is available there, then you could in theory add it.
16:56.39Kobazyheah
16:57.15jkroonanyway, i need to go make dinner, was an insightful discussion, even if no solutions was found.
17:00.36Kobazthanks
17:00.44Kobazhappy someone's here to not argue with me :)
17:03.05seanbrightare people arguing with you?
17:03.22Kobazheh, mostly Samot
17:03.28Kobaznot happy with how i've set this up
17:03.31seanbrightthat is not him arguing
17:03.35seanbrightyou don't want to see him argue
17:03.40Kobazaha
17:05.11SamotKobaz: Did you ever do those two tests I suggested and you said you were going to do?
17:05.16*** join/#asterisk electronic_eel (~quassel@213.240.182.12)
17:12.02seanbrightSamot: STOP ARGUING
17:12.26seanbrightlet me see if i understand what is going on, because this is important
17:12.33seanbrightsomeone is here... asking for help
17:12.43seanbrightyou are asking them to try something
17:12.43*** join/#asterisk sinaowolabi (~Sina@41.190.31.8)
17:12.49seanbrightand then they are not trying
17:13.00seanbrightso let me ask you this... why are you arguing?
17:13.44*** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net)
17:16.52Samotseanbright: Simple, because I'm being forced to.
17:17.04Samot"I have a problem."
17:17.08Samot"Ok, try X"
17:17.19Samot"Oh I don't think that's relevant. I don't see what it will accomplish"
17:17.28Samot"OK, try Y"
17:17.30Samot"Oh I don't think that's relevant. I don't see what it will accomplish"
17:19.59KobazSamot: the reverse order transport, not yet... i'm dealing with other stuff right now, but will do
17:20.29zguhow can i make a dialplan pattern that matches E.164 numbers (starting with +)?
17:20.45KobazSamot: correct... and we went though this before... and we didn't have that many rounds of 'try this, no that's not relavent'  I literally said that to one thing
17:20.49Kobazalbiet many times
17:20.54Samotzgu: The same way you do any others but you start with the +
17:21.16SamotKobaz: OK let me get some context here.
17:21.18KobazAnd I did do that test for you, and it wasn't relavent, and it didn't help isotlate or prove or disprove anything
17:21.26SamotKobaz: How many setups have you done like this in the past?
17:21.41zgui tried "_+." and it didn't seem to work
17:21.41KobazMultiple wan's on the same box? just this one
17:21.46SamotOK
17:22.04KobazBut I know asterisk well enough to know what test cases would be relavent in the situations i understand well
17:22.06SamotMe? Over the course of my career, a dozen to two dozen
17:22.15zguall (UDP:10.x.x.x:5062) to extension '+11235551212' rejected because extension not found in context 'from-internal'.
17:22.21SamotSo I kinda know WTF I am talking about.
17:22.22KobazBut you've never set up one exactly like this
17:22.27SamotReally?
17:22.36SamotYou're probably right
17:22.51SamotI wouldn't be using plain Asterisk as an SBC
17:22.58Kobazcorrect
17:23.02SamotI wouldn't need two have two ether's for each WAN
17:23.03KobazI understand that
17:23.11SamotI would have a properly designed solution
17:23.15SamotSo you're right, not like this.
17:23.23SamotHence all my "Why is this..." questions
17:23.26KobazThis is what we have... so... i'm dealing with it, but anyway.  i need to go fix something
17:23.36SamotOh yeah you do.
17:23.41KobazYeah, I get it... the why is important if there's other ways to solve the issue
17:24.00SamotYeah. Like running an Asterisk instance per WAN.
17:24.05SamotIt's a way
17:24.12SamotNot a right way or the proper way
17:24.12Kobazright, not ideal
17:24.14SamotBut it's a way
17:24.16Kobazbut... it should work actually
17:24.21Kobazit should work pretty well actually, oddly enough
17:24.24SamotI'm not saying it wouldn't.
17:24.34SamotI'm just saying it is improper.
17:24.48SamotWhy are you painting yourself into a corner?
17:24.53KobazI'm not
17:24.56SamotOK.
17:25.00KobazI'm busting through the wall, of the corner someone else painted me into
17:25.27KobazMaking do with what I have, and getting out and making it work, in some fashion
17:25.34Kobazso hopefully without too much code changes
17:25.55Kobazor without having to rip it all apart and do Kamailio, or have them redo their firewall and get all that worked out
17:26.10zgudoes the + need to be escaped in patterns or something?
17:26.17Kobazor many other ways... this is the typical "We're really friggin close, so lets dig a little more"
17:26.37Kobazzgu: you need to explitly match the pattern received
17:27.01Kobazif you don't have a literal +11235551212 in your dialplan, or +1X. or something that matches it... it won't match
17:27.27Kobazzgu: try this: dialplan show +11235551212@from-internal
17:27.28kjetilhoit may be easier to just convert + to 00.
17:27.57Kobazit's going to tell you it doesn't exist... so the resolution is going to be, add a pattern that matches, so that ^^ that dialplan show command, will return something
17:29.43zguhmm, with exten => _+.,1,... it shows the dialplan when i do dialplan show +1...@from-internal
17:30.06zgubut dialing that from a phone fails. specifically trying to redial an incoming call since my sip trunk formats everything as e.164
17:32.00Kobazshow? dpaste.com
17:35.10Kobazwhat's your console look like?
17:35.27zguhttps://dpaste.com/CUPL3WEFT
17:40.30Kobazasterisk version?
17:42.31SamotUhm...
17:42.38SamotThere's no match in the context.
17:43.07SamotYou can't have two from-internal contexts
17:43.23SamotAsterisk is a top down setup
17:43.32SamotThe first context to load wins
17:43.47SamotJust like transports, endpoints, peers
17:44.00Kobazsure you can. if one of them is marked extend
17:44.25SamotOh wait...I'm reading this wrong.
17:44.26KobazBut his issue is not two from-internal contexts
17:44.33KobazHe just ran the command twice
17:44.59Kobazzgu: asterisk version?
17:45.23KobazSomething is odd, because the invite looks funny NOTICE[104200]: res_pjsip_session.c:4001 new_invite:  x103: Call (UDP:10.6.2.46:52744) to extension
17:45.31zgu18.1.1
17:45.34KobazI haven't seen that, maybe that's new in 17/18 ?
17:45.37KobazAh, that's why
17:45.52Kobazzgu: See if you have this issue in 16.15.1
17:46.07KobazI'm glad that finally got added
17:46.30KobazI've been merging in my changes to asterisk for years to add ip and port to invite logging in chan_sip and in pjsip
17:46.39zguhmm
17:47.10Kobazzgu: that does look right, this could very well be a bug
17:47.19Samotzgu: What happens if it is _+1.?
17:47.28zgusame thing i believe
17:47.37SamotCan you confirm that?
17:48.21zgusame with _+1.
17:48.58zguand _+1NXXNXXXXXX
17:49.45Kobazzgu: you may have to dump the sip traffic
17:49.50Kobazyou may have a non-printable in there?
17:49.55Kobazwhat type of device is sending this invite?
17:50.09SamotShow an entire call out
17:50.13Samotasterisk -rvvvvvvvvvv
17:50.33zgutried a grandstream GXP1628 and two different android softphones
17:51.10SamotShow a call that fails, full verbose output
17:51.25Kobazokay so it's probably not crap in the invite
17:51.26Samotturn on the pjsip logger as well for extra details
17:51.36Kobazbut you never know
17:52.16zgutshark summary shows 'SIP/SDP 1489 Request: INVITE sip:+16362021234@10.6.1.38'
17:52.53Samotzgu: Please provide the information asked for.
17:53.40zguhow do i turn on pjsip logging?
17:54.21Kobazpjsip set logger on
17:54.26SamotAlso fix your priority
17:54.32Kobazoh yeah
17:54.36Kobazooooh
17:54.37Samot'_+.' =>          4. Dial(PJSIP/${EXTEN}@twilio-na-us)
17:54.37Kobazhaha
17:54.43SamotThat's not going to work
17:54.44Kobazyeaaah that's the problem, why didn't i catch that
17:54.57KobazMy brain skimed over and assumed it was prio 1
17:55.33zguohhhh i forgot to add a priority to that line
17:56.19zguah that was it. thanks
17:56.33Kobaz[2021-01-05 12:22:15] <zgu> all (UDP:10.x.x.x:5062) to extension '+11235551212' rejected because extension not found in context 'from-internal'.
17:56.54Kobaz^^ the error message should mention Priority 1 not found
17:56.56Kobazlike a goto
17:57.56zguand the dialplan show console command doesn't care there's no priority 1
17:58.07Kobazwell yeah, it's just showing you what's there
17:58.09Kobazwhich is fine
17:58.16zguright
17:58.45Kobazgoto fail will say context,exten,priority not found
18:03.40*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
18:03.59SamotBecause you can define all those.
18:04.10SamotFor a peer/endpoint you're just defining a context
18:04.25SamotYou could match on callerid
18:04.43SamotIt's always going to start at 1
18:05.04KobazBut to make it more obvious, yes it always starts at 1
18:05.14KobazBut, the error message just says 'not found'
18:05.26Kobaz+11235551212 DOES exist in context 'from-internal'
18:05.30Kobazso that's why it's confusing for new users
18:05.41Kobazit does exist, just not priority 1
18:06.51SamotSo I guess it needs to include the included contexts too?
18:07.06SamotBecause I could make from-internal have nothing but include => statements.
18:07.24SamotIt's still going to say it wasn't found in the context "from-internal"
18:07.28Kobazcorrect
18:07.37Kobazbut, it would be specifically useful to say, priority 1 not found
18:07.41SamotWhich doesn't really help if it's support to match in the 3rd include=> statement
18:07.59Kobazreally the syntax should be the same as a goto
18:08.27SamotWhat if there is no match?
18:08.37SamotLike not a literal match
18:08.38Kobazsince it's really a ast_pbx_start() that's occuring at that point, to a context,exten,prio
18:08.43KobazIf there's no match that's fine
18:08.54SamotSo there needs to be two errors
18:09.05SamotEither it exists with a wrong priority or it doesn't.
18:09.09Kobazone would catch all the situations, I think
18:09.23SamotBut then it would be incorrect if there was no real match
18:09.23Kobazyou don't have to double check to see exactly why it failed, just that it failed, and how it failed
18:09.43SamotAdding "priority 1 not found" or whatever
18:09.54SamotWould mean when *no match exists* that is still the error
18:09.58Kobazcorrect
18:10.07SamotMaking it seem like there is a match just wrong priority
18:10.11SamotVs not one being there.
18:10.35Kobazbetter error: New Call Rejected, context,exten,priority Not found: (from-internal, +11235551212, 1)
18:10.42KobazBasically a goto error
18:10.45Kobazshort and sweet
18:10.53SamotOK.
18:11.11SamotGo put in a feature request
18:11.34KobazNot a bad idea
18:11.51KobazExcept the tracker doesn't do feature requests, it would need a gerrit patch
18:12.04Kobazwhich would be a one line patch
18:12.14Kobazso, yeah
18:12.41KobazI might play with the case
18:12.47Kobazand position, but that's the gist of it
18:20.07*** join/#asterisk mboehn_ (mathias@hh1.nuxis.org)
18:52.19*** join/#asterisk pchero (~pchero@211.178.226.108)
19:40.13*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
19:51.01*** join/#asterisk hfb (~hfb@47.139.16.87)
20:34.42*** join/#asterisk overyander (~overyande@216.163.21.11)
21:35.34*** join/#asterisk cryptic (~cryptic@142-196-139-017.res.spectrum.com)
21:37.02*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
21:52.33*** join/#asterisk hfb (~hfb@47.139.16.87)
22:00.49*** join/#asterisk yokel (~yokel@unaffiliated/contempt)
22:01.52*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
22:31.35*** join/#asterisk tripleslash (~triplesla@unaffiliated/imsaguy)
22:38.12*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
23:17.02*** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou)

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