| 00:00.50 | Kobaz | well |
| 00:00.52 | Kobaz | blame the asterisk wiki |
| 00:00.55 | Kobaz | https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial |
| 00:01.06 | Kobaz | 1/4 way down the page: method=sslv23 |
| 00:02.01 | Kobaz | still getting drops in microsip... okay lets do some debugging |
| 00:06.35 | Samot | Read what the defaults are |
| 00:06.47 | Samot | Tlsv1 |
| 00:06.54 | Kobaz | yeah makes sense |
| 00:07.11 | Kobaz | I don't thnk ssl2+3 vls tls 1.2 is causing my drops though |
| 00:07.24 | Samot | Also TLS standards changed in 2020 |
| 00:07.41 | Samot | Everyone made a push to be on TLSv1.2 |
| 00:07.58 | Kobaz | right |
| 00:44.22 | *** join/#asterisk tsal (~tsal@i59F5F906.versanet.de) |
| 01:43.34 | Kobaz | okay so |
| 01:43.38 | Kobaz | figuring out stuff here |
| 01:43.39 | Kobaz | one last issue |
| 01:43.58 | Kobaz | i have two wan interfaces... and pjsip is sending media from the wrong wan interface |
| 01:44.32 | Kobaz | if 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.03 | Kobaz | https://dpaste.com/FGMBYHQA6 |
| 01:46.32 | Kobaz | i have my soft phone set to connect specifically to the wan2 public |
| 01:46.46 | Kobaz | hmm lemme check something |
| 01:47.50 | Kobaz | https://dpaste.com/7X99RENBG |
| 01:47.57 | Kobaz | with the register packet |
| 01:51.16 | Kobaz | do i need bind_rtp_to_media_address |
| 01:54.01 | Kobaz | Well 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.30 | Kobaz | sooooo |
| 17:01.33 | Kobaz | Samot: around? |
| 17:02.46 | *** join/#asterisk waldo323_ (~waldo323@d149-67-45-83.clv.wideopenwest.com) |
| 17:04.48 | Samot | ? |
| 17:22.37 | *** join/#asterisk detha (~detha@unaffiliated/detha) |
| 17:24.06 | Kobaz | Oh hey |
| 17:24.12 | Kobaz | So... continuing from yesterday |
| 17:24.26 | Kobaz | I have a registration AND invite coming in from my WAN2 tls transport |
| 17:24.33 | Kobaz | and media is being sent to the client from WAN1 |
| 17:24.51 | Kobaz | https://dpaste.com/7X99RENBG |
| 17:25.35 | Kobaz | 10.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.08 | Kobaz | pjsip pcap logger is messed up |
| 17:28.18 | Kobaz | all the traffic outgoing is showing up as 0.0.0.0:0 |
| 17:32.52 | file | that's on purpose, it's a placeholder to indicate that it is Asterisk |
| 17:33.14 | file | the pcap logger shows the endpoint address and contents |
| 17:34.46 | Kobaz | ah |
| 17:36.02 | Kobaz | file: 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.20 | Samot | file: Wasn't there a limitation of only one TLS transport? |
| 17:36.21 | file | right. |
| 17:36.30 | file | Samot: PJSIP removed that, but we haven't really tested it |
| 17:36.40 | Samot | Ahh OK. |
| 17:36.49 | Kobaz | So, is this expected behavior? |
| 17:36.54 | Samot | Perhaps. |
| 17:36.59 | Kobaz | Hmm |
| 17:37.19 | file | RTP is independent from signaling transport generally |
| 17:37.55 | Samot | So is this not setting the external media to the right WAN IP? |
| 17:38.06 | Kobaz | Understood, but RTP should use the external_media_address in the transport that I told it to... no? |
| 17:38.15 | Kobaz | Correct, it is not |
| 17:38.19 | Kobaz | It's more than just a setting though |
| 17:38.28 | Kobaz | It's not sourcing it from the correct IP |
| 17:38.49 | Samot | Show the endpoint for this |
| 17:38.58 | file | RTP doesn't use external_media_address, that is what goes into the SDP |
| 17:39.00 | Kobaz | Based on these settings, I would expect Asterisk to use WAN2:5061 as the source for sending packets |
| 17:39.08 | Kobaz | file: so this is the issue then... I think |
| 17:39.27 | Kobaz | RTP needs to bind to WAN2:RTP-Range |
| 17:39.41 | Kobaz | Samot: sure |
| 17:40.43 | Kobaz | Samot: https://dpaste.com/2EKPTVC83 |
| 17:41.37 | Samot | That's the phone side. |
| 17:41.44 | Samot | Is the phone remote? |
| 17:41.46 | Kobaz | YEah |
| 17:42.17 | Samot | Sigh. |
| 17:42.20 | Samot | Dude. |
| 17:42.27 | Kobaz | Yes? |
| 17:42.42 | Samot | If you don't specify a transport, Asterisk will pick the *first* matching transport |
| 17:42.57 | Kobaz | That's also a problem |
| 17:43.08 | Kobaz | Specify a transport, and then WAN2 won't work, ever |
| 17:43.16 | Kobaz | Well it doesn't work at all anyway... (no audio) |
| 17:43.25 | Kobaz | If I set transport to wan2, then wan1 will never work for sure |
| 17:43.49 | Kobaz | So, we need to redefine 'first matching' then |
| 17:44.03 | Samot | Or you use Kamailio in between. |
| 17:44.04 | Kobaz | it should be first matching transport that logically applies to this call-id |
| 17:44.08 | Samot | Solves all my problems like this. |
| 17:44.11 | Kobaz | yeah |
| 17:44.20 | Kobaz | But there's no reason Asterisk can't handle this |
| 17:44.40 | Samot | Well you can use only one transport in the endpoint. |
| 17:44.50 | Kobaz | That's not going to fly here |
| 17:44.52 | Samot | Your issue now is that WAN1 is the first transport. |
| 17:45.24 | Kobaz | So. 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.46 | Samot | Show a debug of a full call over the WAN2 connection. |
| 17:45.56 | Kobaz | Sure |
| 17:49.08 | Kobaz | https://dpaste.com/7NR4MNEAP |
| 17:49.28 | Kobaz | Asterisk PJSIP is using the correct WAN2 in the signalling: YY.9.5.40 |
| 17:49.33 | Kobaz | But not when sending RTP |
| 17:49.54 | Kobaz | from the original dpaste with transports and some packets: |
| 17:50.02 | Kobaz | from another session: 20:43:11.063835 IP 10.13.13.38.53912 > ZZ.75.184.42.20000: UDP, length 192 |
| 17:50.19 | Kobaz | it's using .38 (WAN1) not .39 (WAN2) as the source IP for RTP -> Client |
| 17:51.54 | Samot | And there's what? |
| 17:52.06 | Samot | No incoming audio to your softphone? |
| 17:52.26 | Kobaz | No incoming Audio, correct |
| 17:52.38 | Kobaz | Because the audio is expecting media from WAN1 |
| 17:52.51 | Kobaz | And I'm sure is like WTF, this is unsolicited, and drops it |
| 17:52.53 | Samot | Stop |
| 17:53.17 | Samot | You dial into Asterisk, the recording plays back but you don't hear it? |
| 17:53.25 | Kobaz | I don't hear it, correct |
| 17:53.28 | Samot | OK |
| 17:53.35 | Samot | Does Asterisk hear you? |
| 17:53.40 | Samot | Can you leave a voicemail? |
| 17:53.47 | Samot | Because I see a problem already |
| 17:54.21 | Samot | If this is remote.. |
| 17:54.27 | Samot | c=IN IP4 192.168.5.80 <-- That's not helping |
| 17:54.35 | Samot | That's the SDP for the softphone. |
| 17:54.50 | Samot | Your softphone is telling Asterisk to send audio to an RFC1918 address. |
| 17:55.21 | Kobaz | Which is fine |
| 17:55.26 | Samot | Really? |
| 17:55.35 | Samot | You can route an RFC1918 address over the public Internet? |
| 17:55.37 | Kobaz | PJSIP will run through its nat rules, and not trust it (as it shouldn't) |
| 17:55.57 | Samot | OK man.. |
| 17:56.06 | Samot | First off, and this is a very serious question... |
| 17:56.07 | Kobaz | You can't trust the client to be configured correctly |
| 17:56.13 | Samot | WTF are you running your crap behind NAT? |
| 17:56.46 | Kobaz | Because most 'normal' people in the world is natt'd in some way |
| 17:56.51 | Kobaz | So we need to support that |
| 17:56.51 | Samot | No. |
| 17:56.55 | Samot | Not ITSPs |
| 17:57.02 | Kobaz | Correct not ITSPs. but we're not dealing with ITSP |
| 17:57.21 | Samot | This isn't some multi-tenant hosted voice solution? |
| 17:57.21 | Kobaz | we're dealing with end users and their crappy soft phones and most likly incorrect settings |
| 17:57.25 | Kobaz | Samot: no, it's not |
| 17:57.34 | Kobaz | It's a single site, with two wans |
| 17:57.56 | Kobaz | And Nat or no nat. Asterisk still would be dropping the ball on sourcing RTP |
| 17:58.06 | Kobaz | I can almost guarantee that, based on what I'm seeing |
| 18:00.13 | Samot | OK, then you need to leave the external media stuff blank. |
| 18:00.19 | Samot | The firewall has to do the rest. |
| 18:00.32 | Samot | If 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.32 | Kobaz | I don't think this firewall is smart enough to source route based on SIP headers |
| 18:22.01 | Kobaz | .38 is however source routing to wan1 (at the firewall) and .39 wan2 |
| 18:22.20 | Kobaz | so if asterisk just uses the correct ip, then. we're all done |
| 18:22.31 | Kobaz | and, this would be an issue nat, or no nat |
| 18:23.05 | Kobaz | based 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.19 | Kobaz | So without modifying asterisk as far as I can tell so far, throwing Kamillio in there would be the bandaid |
| 18:42.45 | Kobaz | Based on what file said about the RTP not doing anything with external_media_address |
| 19:12.21 | Samot | The SDP in the call I saw had the WAN2 IP |
| 19:12.40 | Samot | No it is setting the SDP properly |
| 19:25.02 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 19:41.27 | Samot | o=- 2414 226 IN IP4 YY.9.5.40 |
| 19:41.27 | Samot | s=Asterisk |
| 19:41.27 | Samot | c=IN IP4 YY.9.5.40 |
| 19:41.53 | Samot | external_media_address = YY.9.5.40 <-- from the wan2 transport. |
| 19:42.39 | Samot | It would appear that it is getting the right transport and using the right media IP |
| 19:43.37 | Samot | Kobaz: You are dialing a feature code. That is causing Asterisk to do things, it's causing Asterisk to *Source* media for you. |
| 19:44.02 | Samot | Kobaz: 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.15 | Deeewayne | I'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.15 | Deeewayne | o 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.43 | Deeewayne | On 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.50 | Samot | Deeewayne: Do not use Asterisk 17 for this. It is end of life basically. |
| 21:10.59 | Samot | Deeewayne: You should be using 16 or 18. |
| 21:11.49 | Samot | Deeewayne: 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.30 | Deeewayne | Samot, I need to take baby steps. I need 17 for prometheus and AsteriskJava doesn't yet support 18 |
| 21:22.09 | Deeewayne | I'd like to get to something recent, then get to pjsip, then get to LTS |
| 21:22.13 | Samot | OK then use 16 |
| 21:22.21 | Samot | 16 is recent and supported |
| 21:22.27 | Samot | 17 is not supported. |
| 21:22.33 | Deeewayne | I thought prometheus was introduced in 17 |
| 21:22.43 | Samot | Then it would be in 18 |
| 21:23.01 | Deeewayne | points to AsteriskJava |
| 21:23.05 | Samot | OK. |
| 21:23.16 | Deeewayne | I appreciate the advice though |
| 21:23.41 | Deeewayne | My first attempt was for 18, but I need AsteriskJava to catch up |
| 21:24.12 | Deeewayne | any idea on the renaming/masquerade question? |
| 21:25.02 | Samot | Interesting that the AsteriskJava github has support listed up to 16 |
| 21:26.18 | Deeewayne | hrm, yeah I see that; but in the code it does support 17 and I'm using it |
| 21:26.45 | Deeewayne | I had problems w/ 18, plus Asterisk 18 ups the AMI protocol version |
| 21:26.53 | Samot | OK so when I said used 16 it seems to support that. |
| 21:29.02 | Deeewayne | Asterisk 17 is not EOL until 10/28/2021; I'm good w/ that |
| 21:29.18 | Deeewayne | The first jump is to get to something from this decade. |
| 21:29.47 | armin | so 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.23 | Samot | Deeewayne: It's currently in Security Fix Only. |
| 21:30.30 | Deeewayne | That's fine |
| 21:30.32 | Samot | Deeewayne: No bug fixes will be released. |
| 21:30.34 | Samot | OK. |
| 21:48.36 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 23:29.02 | *** join/#asterisk ckb_ (~ckb@unaffiliated/ckb) |