IRC log for #asterisk on 20210104

00:00.50Kobazwell
00:00.52Kobazblame the asterisk wiki
00:00.55Kobazhttps://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial
00:01.06Kobaz1/4 way down the page:  method=sslv23
00:02.01Kobazstill getting drops in microsip... okay lets do some debugging
00:06.35SamotRead what the defaults are
00:06.47SamotTlsv1
00:06.54Kobazyeah makes sense
00:07.11KobazI don't thnk ssl2+3 vls tls 1.2 is causing my drops though
00:07.24SamotAlso TLS standards changed in 2020
00:07.41SamotEveryone made a push to be on TLSv1.2
00:07.58Kobazright
00:44.22*** join/#asterisk tsal (~tsal@i59F5F906.versanet.de)
01:43.34Kobazokay so
01:43.38Kobazfiguring out stuff here
01:43.39Kobazone last issue
01:43.58Kobazi have two wan interfaces... and pjsip is sending media from the wrong wan interface
01:44.32Kobazif endpoint A registers on WAN1 sip-tls.  it works fine.  if endpoint B registers on WAN2... RTP media is going out using wan1 as the source ip
01:46.03Kobazhttps://dpaste.com/FGMBYHQA6
01:46.32Kobazi have my soft phone set to connect specifically to the wan2 public
01:46.46Kobazhmm lemme check something
01:47.50Kobazhttps://dpaste.com/7X99RENBG
01:47.57Kobazwith the register packet
01:51.16Kobazdo i need bind_rtp_to_media_address
01:54.01KobazWell hmm, that woudldn't work.. i can't hard_code media_address
02:39.46*** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0)
02:39.46*** mode/#asterisk [+o DivideBy0] by ChanServ
02:44.36*** join/#asterisk tsal (~tsal@i59F4DC6F.versanet.de)
03:42.34*** join/#asterisk electronic_eel (~quassel@213.240.182.64)
04:13.41*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
05:06.10*** join/#asterisk Posterdati (~posterdat@host-79-45-214-86.retail.telecomitalia.it)
05:20.11*** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net)
05:54.26*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
06:01.58*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
06:19.20*** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net)
06:31.47*** join/#asterisk Grommish (~quassel@2600:2b00:932e:5900:50bc:511:fbac:f3b6)
06:55.03*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
07:37.21*** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme)
08:10.15*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
08:10.24*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
08:32.00*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
09:00.54*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
09:24.03*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
09:38.28*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
10:20.57*** join/#asterisk Grommish (~quassel@2600:2b00:932e:5900:50bc:511:fbac:f3b6)
10:27.39*** join/#asterisk tsal (~tsal@i59F4DC6F.versanet.de)
10:34.00*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
11:22.48*** join/#asterisk post-factum (~post-fact@vulcan.natalenko.name)
12:52.38*** join/#asterisk gavlee (~gav@unaffiliated/gavlee)
14:14.16*** join/#asterisk tips (~tips@pool-173-72-12-154.cmdnnj.fios.verizon.net)
14:46.00*** join/#asterisk maximCH (~maximCH@mail.swill.org)
14:46.33*** join/#asterisk Grommish (~quassel@2600:2b00:932e:5900:50bc:511:fbac:f3b6)
14:49.01*** join/#asterisk gregs (sid160074@gateway/web/irccloud.com/x-rmljleskivfakzvu)
15:06.42*** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-nvngruvefbtapcmh)
15:06.42*** mode/#asterisk [+o bford] by ChanServ
15:07.45*** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-ivjgjdkysrfjkttt)
15:07.45*** mode/#asterisk [+o kharwell] by ChanServ
15:57.33*** join/#asterisk waldo323 (~waldo323@d149-67-45-83.clv.wideopenwest.com)
16:00.47*** join/#asterisk akp55_ (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
16:12.23*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
16:49.20*** join/#asterisk linuxlad (~crosiak@74.115.41.9)
17:01.30Kobazsooooo
17:01.33KobazSamot: around?
17:02.46*** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com)
17:04.48Samot?
17:22.37*** join/#asterisk detha (~detha@unaffiliated/detha)
17:24.06KobazOh hey
17:24.12KobazSo... continuing from yesterday
17:24.26KobazI have a registration AND invite coming in from my WAN2 tls transport
17:24.33Kobazand media is being sent to the client from WAN1
17:24.51Kobazhttps://dpaste.com/7X99RENBG
17:25.35Kobaz10.13.13.39.5061 is WAN2.  And the registration is coming into WAN2 (10.13.13.39.5061). and the INVITE is coming into 10.13.13.39.5061
17:28.08Kobazpjsip pcap logger is messed up
17:28.18Kobazall the traffic outgoing is showing up as 0.0.0.0:0
17:32.52filethat's on purpose, it's a placeholder to indicate that it is Asterisk
17:33.14filethe pcap logger shows the endpoint address and contents
17:34.46Kobazah
17:36.02Kobazfile: I remember someone from -dev saying that pjsip doesn't save/coorolate the transport that the registration came in in terms of what transport to use for the outbound (from asterisk) packets ?
17:36.20Samotfile: Wasn't there a limitation of only one TLS transport?
17:36.21fileright.
17:36.30fileSamot: PJSIP removed that, but we haven't really tested it
17:36.40SamotAhh OK.
17:36.49KobazSo, is this expected behavior?
17:36.54SamotPerhaps.
17:36.59KobazHmm
17:37.19fileRTP is independent from signaling transport generally
17:37.55SamotSo is this not setting the external media to the right WAN IP?
17:38.06KobazUnderstood, but RTP should use the external_media_address in the transport that I told it to... no?
17:38.15KobazCorrect, it is not
17:38.19KobazIt's more than just a setting though
17:38.28KobazIt's not sourcing it from the correct IP
17:38.49SamotShow the endpoint for this
17:38.58fileRTP doesn't use external_media_address, that is what goes into the SDP
17:39.00KobazBased on these settings, I would expect Asterisk to use WAN2:5061 as the source for sending packets
17:39.08Kobazfile: so this is the issue then... I think
17:39.27KobazRTP needs to bind to WAN2:RTP-Range
17:39.41KobazSamot: sure
17:40.43KobazSamot: https://dpaste.com/2EKPTVC83
17:41.37SamotThat's the phone side.
17:41.44SamotIs the phone remote?
17:41.46KobazYEah
17:42.17SamotSigh.
17:42.20SamotDude.
17:42.27KobazYes?
17:42.42SamotIf you don't specify a transport, Asterisk will pick the *first* matching transport
17:42.57KobazThat's also a problem
17:43.08KobazSpecify a transport, and then WAN2 won't work, ever
17:43.16KobazWell it doesn't work at all anyway... (no audio)
17:43.25KobazIf I set transport to wan2, then wan1 will never work for sure
17:43.49KobazSo, we need to redefine 'first matching' then
17:44.03SamotOr you use Kamailio in between.
17:44.04Kobazit should be first matching transport that logically applies to this call-id
17:44.08SamotSolves all my problems like this.
17:44.11Kobazyeah
17:44.20KobazBut there's no reason Asterisk can't handle this
17:44.40SamotWell you can use only one transport in the endpoint.
17:44.50KobazThat's not going to fly here
17:44.52SamotYour issue now is that WAN1 is the first transport.
17:45.24KobazSo.  I'll need to dig into the code that determins what transport to use and add some smarts into how it picks the transport. AND it will need to bind RTP to the external media address set in the transport
17:45.46SamotShow a debug of a full call over the WAN2 connection.
17:45.56KobazSure
17:49.08Kobazhttps://dpaste.com/7NR4MNEAP
17:49.28KobazAsterisk PJSIP is using the correct WAN2 in the signalling: YY.9.5.40
17:49.33KobazBut not when sending RTP
17:49.54Kobazfrom the original dpaste with transports and some packets:
17:50.02Kobazfrom another session: 20:43:11.063835 IP 10.13.13.38.53912 > ZZ.75.184.42.20000: UDP, length 192
17:50.19Kobazit's using .38  (WAN1)  not .39  (WAN2)  as the source IP for RTP -> Client
17:51.54SamotAnd there's what?
17:52.06SamotNo incoming audio to your softphone?
17:52.26KobazNo incoming Audio, correct
17:52.38KobazBecause the audio is expecting media from WAN1
17:52.51KobazAnd I'm sure is like WTF, this is unsolicited, and drops it
17:52.53SamotStop
17:53.17SamotYou dial into Asterisk, the recording plays back but you don't hear it?
17:53.25KobazI don't hear it, correct
17:53.28SamotOK
17:53.35SamotDoes Asterisk hear you?
17:53.40SamotCan you leave a voicemail?
17:53.47SamotBecause I see a problem already
17:54.21SamotIf this is remote..
17:54.27Samotc=IN IP4 192.168.5.80 <-- That's not helping
17:54.35SamotThat's the SDP for the softphone.
17:54.50SamotYour softphone is telling Asterisk to send audio to an RFC1918 address.
17:55.21KobazWhich is fine
17:55.26SamotReally?
17:55.35SamotYou can route an RFC1918 address over the public Internet?
17:55.37KobazPJSIP will run through its nat rules, and not trust it (as it shouldn't)
17:55.57SamotOK man..
17:56.06SamotFirst off, and this is a very serious question...
17:56.07KobazYou can't trust the client to be configured correctly
17:56.13SamotWTF are you running your crap behind NAT?
17:56.46KobazBecause most 'normal' people in the world is natt'd in some way
17:56.51KobazSo we need to support that
17:56.51SamotNo.
17:56.55SamotNot ITSPs
17:57.02KobazCorrect not ITSPs. but we're not dealing with ITSP
17:57.21SamotThis isn't some multi-tenant hosted voice solution?
17:57.21Kobazwe're dealing with end users and their crappy soft phones and most likly incorrect settings
17:57.25KobazSamot: no, it's not
17:57.34KobazIt's a single site, with two wans
17:57.56KobazAnd Nat or no nat.  Asterisk still would be dropping the ball on sourcing RTP
17:58.06KobazI can almost guarantee that, based on what I'm seeing
18:00.13SamotOK, then you need to leave the external media stuff blank.
18:00.19SamotThe firewall has to do the rest.
18:00.32SamotIf this is a on-prem, dual wan thing.. that's how I do it.
18:02.05*** join/#asterisk pchero (~pchero@211.178.226.108)
18:02.54*** join/#asterisk Deeewayne (~dwayne@2605:a601:a816:5000:f7ce:535c:c78:9ec3)
18:21.32KobazI don't think this firewall is smart enough to source route based on SIP headers
18:22.01Kobaz.38 is however source routing to wan1 (at the firewall) and .39 wan2
18:22.20Kobazso if asterisk just uses the correct ip, then. we're all done
18:22.31Kobazand, this would be an issue nat, or no nat
18:23.05Kobazbased on what we're seeing the dump, if asterisk has access to wan2 directly, it's *still* going to use the first matching transport yada yada and use the wrong wan ip
18:26.49*** join/#asterisk n0tiz (~n0tiz@82-69-15-38.dsl.in-addr.zen.co.uk)
18:32.19KobazSo without modifying asterisk as far as I can tell so far, throwing Kamillio in there would be the bandaid
18:42.45KobazBased on what file said about the RTP not doing anything with external_media_address
19:12.21SamotThe SDP in the call I saw had the WAN2 IP
19:12.40SamotNo it is setting the SDP properly
19:25.02*** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772)
19:41.27Samoto=- 2414 226 IN IP4 YY.9.5.40
19:41.27Samots=Asterisk
19:41.27Samotc=IN IP4 YY.9.5.40
19:41.53Samotexternal_media_address     = YY.9.5.40 <-- from the wan2 transport.
19:42.39SamotIt would appear that it is getting the right transport and using the right media IP
19:43.37SamotKobaz: You are dialing a feature code. That is causing Asterisk to do things, it's causing Asterisk to *Source* media for you.
19:44.02SamotKobaz: So the media sourcing could be from the first transport.
20:21.37*** join/#asterisk overyander (~overyande@216.163.21.11)
20:43.24*** join/#asterisk scampbell (~scampbell@mail.scampbell.net)
20:47.09*** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net)
21:07.15DeeewayneI'm migrating a very large Asterisk-based platform from a very customized version of Asterisk 1.4 to Asterisk 17. In this platform, a Local channel is used to dial --> Dial(SIP/${dial_string}@${trunk},${timeout}) which resulted in a masquerade of the Local channel into a SIP channel in the original platform. It seems that in Asterisk 17, the Local channel doesn't get Renamed. I did some reading that might indicate this is due t
21:07.15Deeewayneo the Bridging framework that was introducted around Asterisk 12. Should I be expecting the Local channel to be optimized out with Asterisk 17 ?
21:08.43DeeewayneOn a side note, when I'm done w/ this migration, they are interested in offering some of their customizations back to trunk if the open source community wants them, but that is a separate discussion.
21:10.50SamotDeeewayne: Do not use Asterisk 17 for this. It is end of life basically.
21:10.59SamotDeeewayne: You should be using 16 or 18.
21:11.49SamotDeeewayne: Also, you should be looking at and migrating to Chan_PJSIP. Chan_SIP is basically dead.
21:13.15*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
21:17.18*** join/#asterisk yokel (~yokel@unaffiliated/contempt)
21:21.30DeeewayneSamot, I need to take baby steps. I need 17 for prometheus and AsteriskJava doesn't yet support 18
21:22.09DeeewayneI'd like to get to something recent, then get to pjsip, then get to LTS
21:22.13SamotOK then use 16
21:22.21Samot16 is recent and supported
21:22.27Samot17 is not supported.
21:22.33DeeewayneI thought prometheus was introduced in 17
21:22.43SamotThen it would be in 18
21:23.01Deeewaynepoints to AsteriskJava
21:23.05SamotOK.
21:23.16DeeewayneI appreciate the advice though
21:23.41DeeewayneMy first attempt was for 18, but I need AsteriskJava to catch up
21:24.12Deeewayneany idea on the renaming/masquerade question?
21:25.02SamotInteresting that the AsteriskJava github has support listed up to 16
21:26.18Deeewaynehrm, yeah I see that; but in the code it does support 17 and I'm using it
21:26.45DeeewayneI had problems w/ 18, plus Asterisk 18 ups the AMI protocol version
21:26.53SamotOK so when I said used 16 it seems to support that.
21:29.02DeeewayneAsterisk 17 is not EOL until 10/28/2021; I'm good w/ that
21:29.18DeeewayneThe first jump is to get to something from this decade.
21:29.47arminso i currently run asterisk 16 on some old thin client i got for free (someone wanted to put it in the trash) on freebsd, with /usr on a usb drive (2gb internal storage). works perfectly so far, no issues. hooray.
21:30.23SamotDeeewayne: It's currently in Security Fix Only.
21:30.30DeeewayneThat's fine
21:30.32SamotDeeewayne: No bug fixes will be released.
21:30.34SamotOK.
21:48.36*** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme)
23:29.02*** join/#asterisk ckb_ (~ckb@unaffiliated/ckb)

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