| 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.07 | Kobaz | Samot: correct, the media is the first matching tls transport |
| 00:56.25 | Kobaz | Samot: which is not the correct transport to talk to the endpoing on, considering it's talking to asterisk on wan2 |
| 00:56.29 | Kobaz | and only wan2 |
| 00:57.14 | Kobaz | Deeewayne: I would like to follow your issue. We use local channels extensively |
| 01:02.21 | Samot | Kobaz: Have you done an endpoint to endpoint test? |
| 01:02.33 | Kobaz | Samot: why add complexity? |
| 01:02.42 | Samot | Or endpoint to pstn |
| 01:02.50 | Kobaz | If Endpoint<->Asterisk isn't working... why would Endpoint<->Asterisk<->Endpoint be any better? |
| 01:03.04 | Kobaz | But no, I haven't tried that |
| 01:04.16 | Samot | Have you left a voicemail? |
| 01:04.31 | Samot | Set up a DTMF test? |
| 01:04.41 | Kobaz | No, but... what would be the purpose? |
| 01:04.58 | Kobaz | To see if the wrong transport is being used when executing something other than Playback()? |
| 01:05.01 | Samot | Make sure audio was getting to the PBX |
| 01:05.22 | Samot | The others would be to see what transport is used for the two channels |
| 01:05.30 | Kobaz | My plan was to work on one problem at a time |
| 01:06.09 | Samot | So two endpoints using wan2 have the right source for RTP |
| 01:06.22 | Kobaz | I 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.27 | Samot | These are to help troubleshoot the issue |
| 01:06.42 | Samot | Because right now one side is Asterisk |
| 01:06.47 | Kobaz | Right |
| 01:06.49 | Samot | Not two endpoints |
| 01:07.03 | Kobaz | Two endpoints would result in two sip conversations using the wrong media address |
| 01:07.11 | Kobaz | I'm not sure what we're trying to figure out with that sort of test? |
| 01:07.20 | Samot | So the sourcing from wan1 can be fine from the asterisk side |
| 01:07.34 | Samot | And youre hunting snipes |
| 01:07.43 | Kobaz | Are you saying, having asterisk call the endpoint? |
| 01:08.27 | Kobaz | Right now the endpoint is calling asterisk |
| 01:09.15 | Kobaz | I 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.30 | Kobaz | We know what the issue is |
| 01:09.49 | Samot | OK |
| 01:09.58 | Samot | How about this, set the transport in the endpoint. |
| 01:10.06 | Kobaz | Now 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.07 | Samot | Set it specifically to WAN2 transport |
| 01:10.09 | Samot | Test. |
| 01:10.13 | Kobaz | right |
| 01:10.30 | Kobaz | that'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.13 | Samot | Kobaz: Sometimes you have to do things before figuring out the solution to the issue. |
| 01:11.21 | Kobaz | Sure |
| 01:11.25 | Samot | Kobaz: Prove out theories. |
| 01:25.57 | Kobaz | I don't know why, but when I reloaded, nat stopped working |
| 01:26.04 | Kobaz | It's sending media back to 192.168.5.80 now |
| 01:26.24 | Kobaz | going through config diffs now to see what changed in between |
| 01:26.26 | Kobaz | ...not much |
| 01:32.52 | Samot | Reloaded or restart? |
| 01:34.15 | Kobaz | well, both |
| 01:34.22 | Kobaz | at various points |
| 01:35.38 | Samot | Show a call that doesnt work |
| 01:38.18 | *** join/#asterisk pchero (~pchero@211.178.226.108) |
| 01:42.38 | Kobaz | so weird... all of a sudden pj is sending the wrong public ip for media https://dpaste.com/BRPQ8SRSQ |
| 01:43.07 | Samot | Show your transports again |
| 01:45.02 | Kobaz | https://dpaste.com/AJHKS432E |
| 01:47.50 | Kobaz | Okay, got it |
| 01:48.06 | Kobaz | I had left in a local_net from trying an experiment |
| 01:48.29 | Kobaz | that was the only difference that would affect that, comparing the before and after |
| 01:48.53 | Kobaz | but, 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.28 | Kobaz | holy crap |
| 01:50.29 | Kobaz | it works |
| 01:50.39 | Kobaz | so, this scenario is supported |
| 01:50.40 | Kobaz | holy crap |
| 01:51.05 | Kobaz | symmetric_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.20 | Kobaz | Which is really surprising because -dev was saying this was not supported |
| 01:51.47 | Kobaz | that 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.18 | Kobaz | but, 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.31 | Kobaz | which is probably fine for dealing with ITSP and static trunks, but not for any kind of roadwarrier setup |
| 01:54.31 | Kobaz | So 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.40 | Samot | Well I would need to see a full call. |
| 01:56.57 | Kobaz | Yeah, sure |
| 01:56.58 | Samot | Because rewrite_contact is for the endpoint sending messages to Asterisk |
| 01:57.26 | Samot | local_net is for when Asterisk is to set the external_media or not to set it. |
| 01:57.30 | Kobaz | Let me break it again |
| 01:57.31 | Kobaz | sorry |
| 01:57.37 | Kobaz | i meant rtp_symmetric |
| 01:59.39 | Kobaz | okay so |
| 01:59.41 | Kobaz | here's the transport |
| 02:00.16 | Kobaz | https://dpaste.com/8RJJ749B2 |
| 02:00.19 | Kobaz | right... basic stuff here |
| 02:01.01 | Kobaz | the only difference between working and not working is: local_net = 192.168.181.0/24 |
| 02:01.04 | Samot | First, allow_reload is not the best thing. |
| 02:01.18 | Samot | Second, let's see the broken call |
| 02:01.18 | Kobaz | i've been doing a lot of experimenting with allow_reload and having some good results |
| 02:01.22 | Kobaz | right, that's next |
| 02:03.43 | Kobaz | https://dpaste.com/EU357FFBX |
| 02:04.07 | Kobaz | line 125 is the culprit |
| 02:04.21 | Kobaz | Asterisk is like. uhhh, sending the internal ip out to the world for media |
| 02:05.05 | Kobaz | I 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.34 | Samot | Add your PBX subnet |
| 02:12.38 | Samot | Test again |
| 02:13.11 | Samot | local_net=10.13.13.0/24 |
| 02:13.16 | Kobaz | Ah, that could be |
| 02:13.21 | Samot | Or whatever netmask it is |
| 02:16.18 | Kobaz | okay well |
| 02:16.22 | Kobaz | It's not perfect |
| 02:16.25 | Kobaz | But it's better |
| 02:17.58 | Samot | What does that mean? |
| 02:18.14 | Kobaz | Restarting, and trying another set of tests... but |
| 02:18.35 | Kobaz | Two way audio is working on both wan1 and wan2, buuuuut. Outgoing RTP is still only coming from WAN1 |
| 02:19.43 | Kobaz | Yeah, definitely talking to asterisk on wan2. rtp is being sent from wan1. And BYE's aren't being handled properly |
| 02:19.52 | Kobaz | yeah it's a transport issue... the peer goes unreachable |
| 02:20.02 | Samot | When you say "WAN1" which IP are you referring to? |
| 02:20.07 | Kobaz | the first one |
| 02:20.09 | Samot | The 10.13.13.x? |
| 02:20.13 | Samot | Or the actual WAN IP |
| 02:20.20 | Kobaz | well, internally |
| 02:20.30 | Kobaz | What I care about is 10.13.13.38 vs .39 |
| 02:20.32 | Samot | OK so it's using eth0 vs eth1 |
| 02:20.39 | Samot | Nothing to do with the WAN side. |
| 02:20.43 | Kobaz | no it's aliased |
| 02:20.49 | Kobaz | its eth0 vs eth0:1 |
| 02:20.56 | Samot | OK. |
| 02:21.09 | Kobaz | Well, the wan side (firewall) maps .38 to wan1 and .39 to wan2 |
| 02:21.12 | Samot | You knew what I meant. |
| 02:21.13 | Kobaz | It's source routing for me |
| 02:21.14 | Kobaz | Yeah |
| 02:21.29 | Kobaz | Just so you know more of the specifics in the lower level |
| 02:22.00 | Samot | And it still sources with the transport specifically setup from the "wan1" internal IP? |
| 02:22.06 | Kobaz | the firewall is source routing for me. If i send packets from .38, It will source it for wan1, etc |
| 02:22.09 | Kobaz | RIght |
| 02:22.17 | Kobaz | And... i don't have transport= defined for this endpoint |
| 02:22.21 | Kobaz | as recommended by file |
| 02:22.27 | Samot | I understand that |
| 02:22.30 | Kobaz | so that asterisk can pick the correct transport |
| 02:22.33 | Samot | I said a while ago to set it and test. |
| 02:22.39 | Kobaz | Right, was doing that as well |
| 02:22.54 | Samot | If you define the wan2 transport, does the RTP source from the WAN2 internal IP? |
| 02:22.57 | Samot | Yes/no? |
| 02:23.09 | Kobaz | Sure does |
| 02:23.16 | Samot | OK. |
| 02:23.29 | Samot | And the symmetric_transport doesn't solve it? |
| 02:23.32 | Kobaz | 21:23:06.484340 IP 10.13.13.39.16598 > ..... |
| 02:23.36 | Kobaz | well |
| 02:23.42 | Kobaz | symmetric_transport did *something* |
| 02:23.49 | Samot | What was that something? |
| 02:23.50 | Kobaz | because two way audio wasn't working at all before, on wan2 |
| 02:24.00 | Kobaz | Yeah, two way audio is the something |
| 02:24.23 | Samot | But the audio was always sourcing from the wan1 IP |
| 02:24.23 | Kobaz | so i'm going to back that out and re test |
| 02:24.29 | Kobaz | right, looks to be |
| 02:24.44 | Kobaz | in every single test, unless specifically setting transport to wan2, it uses 1 |
| 02:29.08 | Samot | From endpoint to Asterisk |
| 02:29.23 | Samot | So now you test endpoint to endpoint |
| 02:29.29 | Samot | Does it happen there? |
| 02:30.40 | Kobaz | I'm not going to bother with multiple endpoints if one endpoint doesn't work |
| 02:36.28 | Samot | Except the other side *isn't* Asterisk |
| 02:36.32 | Samot | It's *not the same* |
| 02:36.36 | Samot | It's a *different test* |
| 02:37.22 | Samot | If two endpoints over WAN2 talk to each other where is the RTP sourcing from? |
| 02:37.35 | Samot | From *each side* |
| 02:38.33 | *** join/#asterisk tsal_ (~tsal@i59F52FB9.versanet.de) |
| 02:41.05 | Kobaz | right, it's a different test. One that doesn't help isolate a root cause for this siutation i'm trying to fix |
| 02:41.40 | Samot | It doesn't? |
| 02:41.47 | Kobaz | And 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.54 | Kobaz | No, it doesn't |
| 02:42.03 | Samot | You mean if this doesn't happen endpoint to endpoint and only happens endpoint to Asterisk |
| 02:42.11 | Samot | That means it didn't help isolate the issue to just that? |
| 02:42.26 | Kobaz | It will happen endpoint to endpoint, because B2BUA |
| 02:42.52 | Kobaz | I 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.59 | Samot | So what is the issue with it sourcing from the other transport? |
| 02:43.07 | Samot | OK |
| 02:43.07 | Kobaz | Wan1 being down? |
| 02:43.13 | Samot | Uhm. |
| 02:43.33 | Kobaz | If endpoints are talking to me on wan2. That means wan1 is down |
| 02:43.54 | Kobaz | And if asterisk is sourcing from .38... the firewall is going to source route out to a dead link |
| 02:44.38 | Samot | Yeah, 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.51 | Kobaz | This site has two |
| 02:44.54 | Samot | LAN |
| 02:44.56 | Samot | Two WAN |
| 02:44.59 | Samot | One LAN |
| 02:45.03 | Samot | Does failover |
| 02:45.28 | Kobaz | <PROTECTED> |
| 02:45.30 | Kobaz | But... What do you do. Have externip updated when something bad happens to one link? |
| 02:45.48 | Samot | No, the firewall deals with it. |
| 02:46.14 | Kobaz | because that's how I typically do it. You ping out both interfaces, and if one is down, you change externip |
| 02:46.48 | Kobaz | This isn't your typical hard-cut situation where the wan goes down and everything switches |
| 02:46.59 | Kobaz | there's load balancing going on, and this also handles peering problems |
| 02:47.10 | Kobaz | If level3 goes down and people can' |
| 02:47.18 | Samot | What peering problems? |
| 02:47.23 | Kobaz | t reach wan1 in half the world, but the other people still can, it'll route in |
| 02:48.08 | Kobaz | it's basically active/active |
| 02:48.22 | Samot | What does peering have to do with that? |
| 02:48.34 | Kobaz | nothing, just saying it's a way to deal with peering issues |
| 02:48.40 | Samot | What kind of connections comes into this place? |
| 02:48.49 | Kobaz | radio station, tv stuff |
| 02:49.13 | Kobaz | two 10gbe pipes right on the backbone |
| 02:49.49 | Samot | And you don't have a firewall that can handle this? |
| 02:49.57 | Samot | Wow. |
| 02:50.37 | Kobaz | The firewall is handling load balancing and source routing |
| 02:50.45 | Samot | Right |
| 02:50.54 | Samot | But it can't handle the SIP stuff |
| 02:51.05 | Kobaz | And sip ALG was being problematic so we're doing that internally |
| 02:51.17 | Kobaz | Next vendor update isn't for a while |
| 02:51.22 | Samot | OK. |
| 02:52.10 | Samot | Just curious, what firewall? |
| 02:52.25 | Kobaz | i'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.08 | Kobaz | well, i think I'm done for tonight |
| 03:19.27 | Kobaz | I 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.33 | Kobaz | which 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.36 | 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:24.47 | rah | how do I disable port 5060? |
| 13:27.25 | Kobaz | do you specifically need chan_sip? the new wave is pjsip |
| 13:29.11 | Samot | Well TLS requires TCP |
| 13:30.28 | Kobaz | but you shouldn't need to bind to 5060, but tcpenable would be counterproductive, yeah |
| 13:30.40 | Kobaz | rah: you can firewall off 5060 |
| 13:34.50 | Kobaz | er... 'turning off tcpenable' would be counterproductive |
| 13:42.41 | rah | Kobaz: 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.26 | rah | Kobaz: 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.59 | rah | can anyone suggest how to stop asterisk from listening on port 5060? |
| 13:46.41 | Kobaz | I'm not sure if you can with chan_sip |
| 13:46.42 | rah | Samot: 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.15 | Kobaz | rah: it would be a reasonable assumption that tcpenable=no would prevent any kind of tcp from binding |
| 13:47.22 | Kobaz | but, you can try it? |
| 13:47.35 | Kobaz | I've never tried to turn off 5060, so that's something new |
| 13:47.43 | Kobaz | at least not with chan_sip |
| 13:47.46 | rah | Kobaz: I already told you I have tried it |
| 13:47.54 | rah | 13: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.28 | Kobaz | that's pretty much it in terms of enable options for those protocols, unfortunately |
| 13:48.34 | Samot | rah: Im making the observation that TLS is over TCP |
| 13:49.30 | rah | actually, there's been a misunderstanding |
| 13:49.46 | rah | it's not listening on tcp port 5060, it's listening on udp port 5060 |
| 13:49.54 | rah | but the same logic applies |
| 13:50.05 | Samot | Show your sip.conf with all these settings |
| 13:50.39 | Kobaz | maybe..... udpbindaddr= |
| 13:50.41 | *** join/#asterisk sinaowolabi (~Sina@105.112.38.30) |
| 13:50.44 | Kobaz | set to empty? |
| 13:51.18 | rah | this is the general section of sip.conf: https://paste.debian.net/1179793/ |
| 13:53.18 | rah | Kobaz: setting an empty udpbindaddr doesn't fix it |
| 13:53.31 | rah | I think a bug is in order |
| 13:53.45 | Kobaz | chan_sip wont really get changes like this |
| 13:53.50 | Kobaz | no one wants to work on it |
| 13:54.00 | Kobaz | you can try though |
| 13:54.14 | rah | at least the issue will be known then |
| 13:55.36 | Samot | rah: Chan_SIP is dead. |
| 13:55.43 | Samot | rah: Within the next few years it will be removed. |
| 13:55.48 | Samot | rah: No one is working on it. |
| 13:57.04 | file | chan_sip doesn't support disabling UDP |
| 13:59.20 | Samot | rah: Also show us what is listening on the server. Show us TCP isn't being used |
| 14:04.52 | rah | file: what does udpenable=no do? |
| 14:05.00 | file | nothing |
| 14:05.01 | file | it doesn't exist |
| 14:05.10 | rah | O_o |
| 14:07.27 | rah | file: is there a list of options that sip.conf accepts? |
| 14:07.53 | seanbright | configs/basic/sip.conf.sample should have most of them |
| 14:07.57 | rah | Samot: proving to you that I can read the output of the ss command won't help solve the problem :-) |
| 14:08.03 | file | there's the sample configuration file and the code |
| 14:08.07 | rah | seanbright: so that's a "no"? :-) |
| 14:08.17 | Samot | rah: No but it proves to us YOU are reading it right |
| 14:08.22 | rah | so just the code, right |
| 14:08.30 | Samot | rah: You're being very problematic for someone seeking help |
| 14:08.45 | seanbright | problematic is not the right word |
| 14:08.47 | seanbright | he's being a dick |
| 14:08.52 | rah | Samot: 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.53 | seanbright | stop being a dick |
| 14:08.54 | Samot | I was being nice. |
| 14:08.59 | rah | *I* know I can read the output of ss |
| 14:09.03 | Samot | rah: So there's no point in us wasting the time. |
| 14:09.09 | rah | exactly |
| 14:09.16 | seanbright | you cannot disable UDP in chan_sip |
| 14:09.17 | Samot | rah: You ask for help and then fight over the help being offered/given. |
| 14:09.28 | Samot | I'm so sick of that shit. |
| 14:09.30 | rah | Samot: O_o |
| 14:10.38 | rah | seanbright: I see, thanks |
| 14:10.48 | seanbright | you're welcome |
| 14:24.19 | *** join/#asterisk tsal_ (~tsal@i59F52D59.versanet.de) |
| 14:25.20 | Kobaz | Samot: I really think I do need Kamillio |
| 14:25.30 | rah | my "Asterisk: The Definitive Guide" doesn't cover pjsip |
| 14:25.36 | rah | woe is me :-( |
| 14:25.52 | Kobaz | rah: Yeah, the book is older |
| 14:27.16 | Kobaz | Kamailio... 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.40 | Samot | Kobaz: What made you come to the conclusion? |
| 14:29.00 | Kobaz | Samot: asterisk still is not actually properly using the origin transport |
| 14:29.25 | Samot | And this is still only testing an endpoint calling into Asterisk with a single channel in use? |
| 14:29.32 | Kobaz | Right |
| 14:29.35 | Kobaz | the base case |
| 14:29.49 | Samot | Because that's what they'll mostly being doing? |
| 14:29.53 | Kobaz | You get two way audio, yes. But SIP OPTIONS is going over UDP 5060, if transport is unset |
| 14:29.56 | Kobaz | Samot: no |
| 14:30.08 | Kobaz | Samot: but it's the base case. |
| 14:31.58 | Kobaz | I'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.20 | Kobaz | You test the base case first. If that doesn't work, you resolve the base case |
| 14:32.28 | Samot | I didn't say the test itself wasn't satifactory |
| 14:32.43 | Samot | It being the *only* test isn't satisfactory. |
| 14:33.22 | Samot | Kobaz: What is this issue persists in other cases? Or doesn't persist in other cases? |
| 14:33.24 | Kobaz | You want more testing, but the type of test you want adds complexity and changes the scenario |
| 14:33.38 | Samot | Kobaz: If the latter, what will happen when you fix this base case? |
| 14:33.45 | Samot | Kobaz: Does that change the latter? |
| 14:34.01 | Samot | Changes the scenario? |
| 14:34.13 | Samot | So there's no scenario where endpoint-to-endpoint calls will happen? |
| 14:34.21 | Samot | Nothing from the PSTN or to the PSTN |
| 14:34.24 | Samot | Nothing from user to user? |
| 14:34.27 | Kobaz | No the scenario doesn't change unless you say, add an endpoint to the mix |
| 14:34.32 | Samot | None of those will be a scenario? |
| 14:34.36 | Kobaz | Sure they would be |
| 14:34.50 | Kobaz | But if asterisk, talking to one endpoint... isn't sending media or signalling correctly |
| 14:34.54 | Kobaz | what's the point of testing more endpoints? |
| 14:35.14 | Samot | To see if the RTP is sourcing from the right interface. |
| 14:35.14 | Kobaz | B2BUA is still Asterisk<->Endpoint, there's just now two endpoints! |
| 14:35.18 | Kobaz | It wont |
| 14:35.21 | Samot | Is the Transports still being done right |
| 14:35.24 | Samot | So you're 100%? |
| 14:35.35 | Samot | No f'ing proof but you're 100%. |
| 14:35.50 | Samot | Forest for the trees, man. Forest for the trees. |
| 14:36.02 | Kobaz | I'm using basic logic here... Yes, because why would Endpoint<->Asterisk<->Endpoint work properly if Endpoint<->Asterisk does not |
| 14:36.27 | Kobaz | Why would anyone bother testing 10,000 clients hitting a web server, if ONE CLIENT doesn't work ? |
| 14:36.31 | Kobaz | I really don't get the logic here |
| 14:36.42 | Samot | That is not a valid comparison. |
| 14:36.42 | Kobaz | Or 2 clients. Or anything other than one |
| 14:36.52 | Kobaz | It's the same level of not-usefulness |
| 14:36.56 | Samot | OK. |
| 14:37.26 | Kobaz | If you really want me to test b2bua... sure |
| 14:37.32 | Kobaz | But, this is a total waste of time |
| 14:37.35 | Samot | No, that's fine |
| 14:37.42 | Samot | I don't want to waste your time troubleshooting. |
| 14:39.10 | Kobaz | I understand it's bridging instead of playing rtp direct to the endpoint |
| 14:39.15 | Kobaz | There's different stuff going on there for sure |
| 14:39.43 | Kobaz | But if the low level RTP created from the SDP is not working the way it needs to... there you go |
| 14:39.45 | Samot | You mean like both endpoints locking on the same transport |
| 14:40.05 | Samot | And perhaps not defaulting to the *first known transport that matches* like the single channel call. |
| 14:42.42 | Kobaz | It's the same behavior |
| 14:43.04 | Kobaz | I have one soft phone on WAN1 and one on WAN2. Both sets of RTP are coming from WAN1 |
| 14:44.48 | Samot | Well why do you need to ether interfaces? |
| 14:44.59 | Kobaz | Because one is bound to wan1 and one is bound to wan2 |
| 14:45.06 | Samot | Why? |
| 14:45.10 | Kobaz | Why not? |
| 14:45.15 | Samot | Wrong answer. |
| 14:45.18 | Samot | Why? |
| 14:45.19 | Kobaz | And ignoring the why... it should work |
| 14:45.24 | Samot | Sigh. |
| 14:45.40 | file | the code isn't written to work for that specific scenario, it COULD work |
| 14:45.42 | Kobaz | If I want asterisk to use RTP from x.y.z.q... I would like to be able to do that |
| 14:45.50 | Kobaz | Yeah. I understand |
| 14:45.53 | Kobaz | I'm trying to make it work :/ |
| 14:46.25 | Kobaz | I'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.39 | file | it's not an issue in the rtp engine |
| 14:46.49 | Kobaz | And while i'm testing I've been poking at res_pjsip_session.c and res_pjsip_sdp_rtp.c |
| 14:46.56 | Kobaz | Well the rtp engine can do it... it just needs to be told to do it |
| 14:47.07 | Kobaz | 'usage of the rtp engine' issue, sorry |
| 14:48.28 | Kobaz | Hmm... how long these days does a typical post to asterisk-dev take? |
| 14:48.56 | file | one appeared yesterday? |
| 14:49.04 | Kobaz | Yeah i saw |
| 14:49.06 | file | usually near instant? |
| 14:49.17 | Kobaz | Yeah usuaully... That's what I thought |
| 14:49.23 | Kobaz | Hmm... I posted about 20 minutes ago |
| 14:53.01 | Kobaz | Okay. 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.27 | Kobaz | I can re-share all my configs if needed |
| 14:54.31 | Kobaz | and that's with transport unset at the endpoint, and symmetric_transport=yes at the transport |
| 14:56.19 | file | because there's potentially a bug in your specific use case with transport selection involving multiple transports? |
| 14:56.47 | file | (theoretically speaking) |
| 14:57.30 | Kobaz | fair enough |
| 14:59.47 | Samot | Kobaz: Show this endpoint settings again |
| 14:59.56 | Kobaz | Yeah sure |
| 15:00.17 | Kobaz | Also, 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.33 | Kobaz | Haven't really started digging into that yet. It's on the chopping block |
| 15:01.55 | Kobaz | https://dpaste.com/8ZUPE3GU5 |
| 15:04.20 | Samot | And the contacts, I want to see the full contact details. |
| 15:04.23 | Kobaz | The 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.18 | Kobaz | 21005/sip:21005@XX.75.184.42:53326;transport=TLS |
| 15:05.35 | Kobaz | That's the one that really matters, i just unregistered the other ones |
| 15:07.09 | Samot | Sigh |
| 15:07.12 | Samot | I wanted to see ALL three |
| 15:07.35 | Samot | Has there been three contacts during all this? |
| 15:07.40 | Kobaz | no |
| 15:07.43 | Samot | OK. |
| 15:07.57 | Kobaz | been switching around to various softphones at various places, trying to pinpoint something |
| 15:08.28 | Samot | media_use_received_transport=yes <-- have you tried that? |
| 15:09.01 | Kobaz | it's been a while |
| 15:09.05 | Kobaz | let me test with my current setup |
| 15:10.22 | Kobaz | nope. media is sourcing from wan1 still |
| 15:10.57 | Kobaz | so i've been playing with symmetric_transport=yes |
| 15:11.00 | Kobaz | here's what it does |
| 15:11.27 | Kobaz | 22045/sip:22045@XX.225.50.173:52917;ob;x-ast-txp=transport-udp |
| 15:11.46 | Kobaz | the endpoint registers, and it saves the original transport |
| 15:11.51 | Kobaz | now... with TLS this does not happen |
| 15:12.05 | Kobaz | This might be the avenue to a solution here. |
| 15:12.31 | Kobaz | when a TLS endpoint registers... you get the earlier contact I pasted.... transport=TLS (generic TLS... not the specific transport) |
| 15:12.37 | Samot | So that example is the device registering over UDP? |
| 15:12.43 | Kobaz | yeah, udp 5060 |
| 15:12.49 | Samot | So this with a TLS |
| 15:12.56 | Samot | That has the x-ast-txp tag |
| 15:13.08 | Kobaz | right 21005 is TLS... and does not set x-ast-txp |
| 15:13.31 | Kobaz | which, 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.10 | Kobaz | If I add a static contact... |
| 15:16.39 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 15:23.01 | Kobaz | I can't be the only one using asterisk as a multi-homed media gateway |
| 15:23.07 | Kobaz | Heh.. well maybe |
| 15:23.09 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 15:24.17 | file | in this fashion, I haven't seen anyone else do such a thing, and I haven't seen any complaints regarding these issues |
| 15:24.42 | file | the vast majority of users don't do stuff like this |
| 15:25.02 | Kobaz | Yeah... I know |
| 15:25.07 | Kobaz | I'm always breakin stuff :( |
| 15:25.39 | Kobaz | file: 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.18 | Samot | Like l said, I have this setup at a location |
| 15:31.38 | Samot | Dont have two eth interfaces in the PBX |
| 15:32.06 | Kobaz | Yeah, i understand |
| 15:32.25 | Kobaz | There'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.13 | Kobaz | The 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.17 | jkroon | has anyone managed to utilize %C in the ASTERISK_PROMPT environment variable? |
| 15:33.51 | Samot | Kobaz no |
| 15:34.00 | Samot | That is the drivethru attitude |
| 15:34.04 | Kobaz | It'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.17 | Samot | Dont give yoy flack about the setup just solve thenone issue |
| 15:34.32 | Samot | I do this |
| 15:34.41 | Kobaz | Samot: that's management for you 'solve it, I don't care how' |
| 15:35.08 | Samot | So when Im asking questions it is because how i have made it work doesnt involve what youre doing |
| 15:35.18 | Kobaz | Sure, understandable |
| 15:35.36 | Samot | So when I ask why you are doing something, reasons shoukd follow. |
| 15:35.41 | Samot | Valid reasons |
| 15:35.49 | Samot | Not "just cuz" |
| 15:35.59 | Samot | Because that means zero thought |
| 15:36.14 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 15:36.53 | Kobaz | I have valid reasons. And I went over them. I just thought we were going around in circles |
| 15:37.06 | Kobaz | Another reason. I can't change the WAN setup right now |
| 15:37.17 | Kobaz | and probably can't for, several weeks/months/never? not sure |
| 15:37.26 | Kobaz | ... Not something I control |
| 15:37.36 | Samot | Do the ether ports plug into the same switch? |
| 15:37.44 | Kobaz | Yes |
| 15:37.48 | Samot | ..... |
| 15:38.04 | Kobaz | vswitch, vmware |
| 15:39.07 | Samot | So you need it on two local subnets |
| 15:39.08 | Kobaz | It's not as redundant as it should be. Really there should be two SBCs, one on each WAN |
| 15:39.20 | Samot | What? |
| 15:39.25 | Samot | No |
| 15:39.46 | Kobaz | Have a proper Proxy1/Proxy2 |
| 15:39.46 | Samot | If there are two SBCs one is for failover |
| 15:39.51 | Samot | Yes |
| 15:39.59 | Samot | I do that as well |
| 15:41.03 | Kobaz | Basically, 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.20 | Kobaz | so, I'm going to play with static contacts, and setting the x- flag for transport |
| 15:41.30 | Kobaz | If that fixes it, then I know what to change in the code |
| 15:41.45 | Samot | Do you have local phones? |
| 15:41.55 | Kobaz | Yeah, they are direct to the pbx |
| 15:42.05 | Kobaz | (Asterisk) |
| 15:42.11 | Samot | One their own subnet? |
| 15:42.26 | Samot | On* |
| 15:42.30 | Kobaz | It's like, 20 subnets, but yeah |
| 15:42.49 | Samot | Why are all the phones on 20 subnets? |
| 15:42.58 | Samot | Local ones |
| 15:43.03 | Kobaz | local-local. one subnet |
| 15:43.08 | Kobaz | remote-offices each has their own |
| 15:43.14 | Kobaz | and it depends on the floor, and whatever |
| 15:43.23 | Kobaz | I didn't build that part |
| 15:43.28 | Samot | So those are not local |
| 15:43.30 | Kobaz | But it's working well so far |
| 15:43.41 | Samot | I asked about local |
| 15:43.57 | Kobaz | Even the LAN, like I said, depending on the floor, subnets |
| 15:44.04 | Samot | So is the subnet one if the PBXes subnets? |
| 15:44.10 | Kobaz | One of them, yes |
| 15:44.13 | Samot | Oh jfc |
| 15:45.11 | Kobaz | Does this add clarity? So floor 1 is 182.168.181.x floor 2 is 192.168.182.x |
| 15:45.21 | Samot | No |
| 15:45.27 | Kobaz | The PBX is 192.168.181.5 |
| 15:45.33 | Samot | Because it becomes a why question |
| 15:45.44 | Kobaz | I don't know the why, I didn't build it |
| 15:46.13 | Samot | So part of the problem is poor network design |
| 15:46.23 | Samot | Just keep that in mind |
| 15:46.30 | Kobaz | Now you're grasping |
| 15:46.40 | Kobaz | There's no problems with the lan, local or remote |
| 15:46.41 | Samot | No I am not |
| 15:46.54 | Samot | OK |
| 15:46.56 | Kobaz | None of this plays a factor in the sbc asterisk |
| 15:47.09 | Samot | Sure it does |
| 15:47.23 | Samot | You have three subnets on the pbx |
| 15:47.35 | Kobaz | No it doesn't. The sbc talks to the pbx with no issues |
| 15:47.51 | Samot | Then why are there two transports |
| 15:48.03 | Kobaz | You can pretend the pbx doesn't exist, for this situation i'm trying to resolve |
| 15:48.24 | Samot | The one we have been troublesooting? |
| 15:48.32 | Samot | Shooting |
| 15:48.36 | Kobaz | Literally 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.46 | Samot | Ohhhh |
| 15:48.48 | Kobaz | the 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.58 | jkroon | Kobaz, 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.00 | Kobaz | Two pbx machine's actually. So there's three in total. PBX-A PBX-B and SBC |
| 15:49.00 | Samot | Youre trying to use asterisk as an SBC |
| 15:49.10 | Kobaz | correct |
| 15:49.15 | Samot | Ok |
| 15:49.21 | Samot | Not its intent |
| 15:49.27 | Kobaz | I know |
| 15:49.45 | Kobaz | But. Based on what I researched with pjsip options and multiple transports before diving into this. it 'should work' |
| 15:49.52 | Samot | No |
| 15:49.55 | Kobaz | And I know asterisk very well, Kamailio, not so much |
| 15:50.01 | jkroon | or am I being very confused here ... |
| 15:50.05 | Samot | SBCs are not B2BUAs |
| 15:50.14 | Kobaz | Well, this one is |
| 15:50.47 | Kobaz | To simplify.. and then we'll do reinvites and step out when everything is working as direct connections |
| 15:50.50 | file | jkroon: 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.06 | Samot | Yup |
| 15:51.12 | Samot | Default route |
| 15:51.18 | Kobaz | jkroon: yeah there's no nat on 192.168.x.x... and you can safely ignore those subnets, we were on a tangent |
| 15:51.26 | jkroon | Kobaz, I did some work on RTP address selection a number of revisions back |
| 15:51.40 | Kobaz | right it's using the default route, which is fine. and it's also using the 'default interface' on the box |
| 15:51.42 | jkroon | ok, so what's the problem here? |
| 15:51.44 | Kobaz | which asterisk can control |
| 15:51.52 | Kobaz | jkroon: thanks for jumping in :) |
| 15:52.15 | file | jkroon: 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.45 | Samot | Change the order and see what happens |
| 15:52.49 | seanbright | source based routing |
| 15:52.58 | Samot | Put wan2 transport first |
| 15:53.03 | jkroon | Kobaz, 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.07 | Kobaz | jkroon: 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.10 | jkroon | secondly, you need routing. |
| 15:53.23 | Samot | Put wan2 transport first |
| 15:53.30 | Kobaz | jkroon: well hold a sec on the routing... |
| 15:53.31 | Samot | Restart and test |
| 15:53.37 | seanbright | routing |
| 15:53.40 | seanbright | wan2 transport |
| 15:53.42 | seanbright | words |
| 15:53.43 | seanbright | things |
| 15:53.46 | jkroon | so address selection is to a large degree based on host routing. |
| 15:54.00 | Kobaz | jkroon: if i explicitly tell the endpoint to use -tls-wan2... address selection will be exactly what I expect |
| 15:54.16 | Kobaz | jkroon: correct unles you tell the host to use a specific source |
| 15:54.20 | Samot | Do what I suggested |
| 15:54.34 | Kobaz | jkroon: which will happen if transport=tls-wan2... asterisk WILL source the address I want |
| 15:54.37 | Kobaz | Samot: will do |
| 15:54.55 | jkroon | ok, and then you want the ip rule stuff at the OS level? |
| 15:55.03 | Kobaz | Opposite |
| 15:55.13 | jkroon | ok, i'm confused, let me re-read. |
| 15:55.25 | Kobaz | I want asterisk to tell the OS.. I'm sending from this address.. like ping -I |
| 15:55.55 | Samot | You do that by the socket binding |
| 15:56.01 | Kobaz | Asterisk 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.04 | Samot | Which is in the transport config |
| 15:56.08 | Kobaz | Samot: correct |
| 15:56.20 | jkroon | Samot, but rtp for pjsip *always* binds the 0.0.0.0 address. |
| 15:56.27 | Kobaz | Right |
| 15:56.36 | Kobaz | and can choose what source ip to use, for any given rtp session |
| 15:56.37 | jkroon | this is an issue I had too. |
| 15:56.43 | Kobaz | perfect |
| 15:56.48 | Kobaz | Oh man. we're on the same page :) |
| 15:56.56 | jkroon | Kobaz, it sends *from* 0.0.0.0 and then uses the routing. |
| 15:57.10 | Kobaz | Well yeah, you're bound already |
| 15:57.15 | jkroon | ip ro replace default via a.b.c.d src e.f.g.d |
| 15:57.47 | Kobaz | I need to avoid OS routing though. The endpoint can talk to asterisk on WAN1 *or* WAN2 |
| 15:57.57 | Kobaz | hold on a second... take this example: |
| 15:58.09 | jkroon | you can look at ice_{acl,deny,permit} in rtp.conf as well to assist with the *advertised* addresses. |
| 15:58.22 | Kobaz | define an endpoint, set transport=transport-tcp-wan2-tls |
| 15:58.33 | jkroon | behind the same router? |
| 15:58.37 | Kobaz | yes |
| 15:58.42 | Kobaz | no OS routing changes at all |
| 15:58.43 | jkroon | router type? |
| 15:58.50 | Kobaz | and asterisk will set the source ip |
| 15:58.56 | jkroon | how do you know *when* which route will be used? |
| 15:58.59 | Samot | Ignore tge router |
| 15:59.08 | Kobaz | Yeah this isn't router related |
| 15:59.15 | Samot | I already went down that path |
| 15:59.18 | Kobaz | jkroon: Okay. this will make more sense |
| 15:59.35 | jkroon | well, 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.40 | Kobaz | jkroon: ... same router (same default gw) is handling both wans |
| 15:59.52 | Samot | jkroon: thats how I do it too |
| 15:59.58 | Kobaz | i have IP Aliasing on lAN 10.13.13.38 and 10.13.13.39... WAN1/WAN2 respectively |
| 16:00.03 | Samot | jkroon: this was suggested and shot down |
| 16:00.12 | jkroon | on ingress, add the source IP to ipset, on egress, mark the traffic and rule-based route it. |
| 16:00.14 | Kobaz | Yeah, as of right now I can't handle this at the router |
| 16:00.24 | Kobaz | jkroon: I can do that |
| 16:00.26 | jkroon | only problem is if same IP comes in over multiple WAN links :(. |
| 16:00.38 | Kobaz | Yes, that's a possability here |
| 16:00.56 | Samot | Still requires router config |
| 16:01.05 | jkroon | problem at asterisk routing layer is source address is selected *before* the route rules kick in. |
| 16:01.11 | Kobaz | I can source route at the OS level |
| 16:01.17 | Kobaz | jkroon: can you explain this one though... |
| 16:01.25 | Kobaz | [2021-01-05 10:58:21] <Kobaz> define an endpoint, set transport=transport-tcp-wan2-tls |
| 16:01.40 | Kobaz | Asterisk will then use .39 (wan2) as the source ip |
| 16:01.51 | jkroon | RTP is STILL BOUND TO 0.0.0.0 unless you set MEDIA-ADDRESS |
| 16:01.56 | Kobaz | transport = undefined... then asterisk will use .38 (wan1) |
| 16:01.57 | Samot | Because it sets the socket |
| 16:02.14 | Kobaz | jkroon: which is fine... i don't care about the bind, i just want the right source address to go out |
| 16:02.16 | Samot | Setting an explicit transport sets an explict socket to bind to |
| 16:02.24 | Kobaz | Samot: correct |
| 16:02.25 | jkroon | Kobaz, to fix it, you need to fix the bind. |
| 16:03.01 | Kobaz | what 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.04 | jkroon | a bind to 0.0.0.0 uses routign looking (before netfilter kicks in) to determine source address. |
| 16:03.11 | Kobaz | correct |
| 16:03.12 | jkroon | you could SNAT the traffic on egress though. |
| 16:03.26 | Kobaz | correct it will use routing |
| 16:03.34 | Kobaz | here let me show you what i'm talking about |
| 16:03.53 | jkroon | no, 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.57 | Kobaz | https://dpaste.com/23EYGWDUH |
| 16:04.13 | Kobaz | yes |
| 16:04.14 | Kobaz | exactly! |
| 16:04.22 | Kobaz | 'unless a specific media address is set' |
| 16:04.26 | Kobaz | I want to set this ^^^^^ |
| 16:04.37 | jkroon | pjsip has an option somewhere ... |
| 16:04.41 | Kobaz | But dynamically, per RTP session, depending on which contact it comes from |
| 16:05.04 | jkroon | i suspect that will require code changes. |
| 16:05.18 | Kobaz | i bet |
| 16:05.46 | Kobaz | so far, I've found: transport/symmetric_transport |
| 16:05.56 | Kobaz | Which looks like a good basis for solving this |
| 16:06.13 | jkroon | and 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.35 | jkroon | yea, issues I will still need to solve those :). |
| 16:06.58 | Kobaz | It writes a contact like this: 22045/sip:22045@XX.225.50.173:52917;ob;x-ast-txp=transport-udp |
| 16:06.59 | jkroon | for 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.15 | Kobaz | jkroon: that's what I was thinking |
| 16:07.28 | Kobaz | I'll need to run two Asterisk instances, one on each wan |
| 16:07.38 | jkroon | nasty. |
| 16:07.42 | Samot | Yeah. |
| 16:07.43 | Kobaz | I know :( |
| 16:07.52 | Kobaz | x-ast-txp=transport-udp <<<< this is promising |
| 16:07.57 | Kobaz | storing the transport in the contact |
| 16:08.01 | jkroon | we run >200 asterisk instances per host when degraded, each on a specific IP address. |
| 16:08.08 | Samot | Is that the only udp transport you have set? |
| 16:08.17 | Kobaz | no there' two |
| 16:08.21 | Kobaz | one is for wan2 |
| 16:08.22 | Samot | Is that the first? |
| 16:08.25 | Kobaz | that's the first |
| 16:08.29 | Kobaz | yeah let me try the reverse ordering |
| 16:08.33 | Samot | So did that come in over wan2? |
| 16:08.45 | Kobaz | this one, probably came over wan1 |
| 16:08.54 | Samot | You need to be 100% on that |
| 16:09.00 | Kobaz | but... see the TLS... this one came over wan2 for sure |
| 16:09.02 | Samot | And not have a false positive. |
| 16:09.05 | Kobaz | 21005/sip:21005@XX.75.184.42:53326;transport=TLS |
| 16:09.06 | Samot | That's different. |
| 16:09.13 | Kobaz | this one does NOT store x-ast-txp |
| 16:09.16 | Kobaz | unfortunately |
| 16:09.17 | jkroon | we 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.25 | Samot | Right. It's different. |
| 16:09.32 | Samot | I'm asking about the udp ones. |
| 16:09.40 | jkroon | had to increase the RTP range from the default 10000-20000 to 10000 to 40000 to deal with that though. |
| 16:09.43 | Samot | Does it set the proper udp transport? |
| 16:09.44 | Kobaz | udp. I didn't really care, but.. that would be interesting |
| 16:09.48 | Kobaz | I can test that |
| 16:09.48 | jkroon | the SIP side is easy. |
| 16:09.49 | Samot | Or is it grabbing the first one? |
| 16:10.09 | jkroon | the issue is RTP (media) side. |
| 16:10.28 | jkroon | if a specific *transport* can enforce a bind to a specific *media* address our issues are solved too. |
| 16:10.44 | Samot | Kobaz: Make a connection over WAN2 UDP and see what transport is stored in the tag |
| 16:10.47 | Kobaz | jkroon: 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.57 | Kobaz | jkroon: YES! |
| 16:11.10 | jkroon | the 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.19 | Kobaz | yeah |
| 16:11.24 | Kobaz | in my cast RTP is filtered |
| 16:11.30 | Kobaz | because it's coming from the wrong WAN |
| 16:12.07 | Samot | Kobaz: Are you going to test the WAN2 connection to see which UDP transport is selected? |
| 16:12.13 | Kobaz | yeah |
| 16:12.41 | jkroon | Kobaz, i think that there are a few settings related to "endpoints" that I'd prefer to have transport specific. |
| 16:12.50 | jkroon | media address being one of them. |
| 16:13.03 | jkroon | dtls and other similar settings being others. |
| 16:13.14 | Kobaz | yeah |
| 16:13.17 | Kobaz | exactly |
| 16:13.48 | jkroon | so 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.54 | Kobaz | right |
| 16:14.03 | Kobaz | have you worked on this yet? |
| 16:14.27 | jkroon | one 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.17 | jkroon | and 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.26 | jkroon | but no, i haven't started work on that yet. |
| 16:16.08 | Kobaz | endpoint name? hmm |
| 16:16.32 | jkroon | really 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.48 | jkroon | but i haven't delved into pjsip code just enough yet to know what makes more sense. |
| 16:17.12 | jkroon | so now, the question really becomes if I set media-address in both endpoint and transport - which one should take preference? |
| 16:18.01 | jkroon | and 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.18 | jkroon | so another strategy is to narrow the binding of the RTP socket upon receipt of RTP ... |
| 16:18.40 | jkroon | many different strategies, and I honestly don't know which one will be best in the long term. |
| 16:18.52 | jkroon | and if you narrow, you need to widen again in some cases ... |
| 16:19.11 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 16:19.19 | Kobaz | i don't think you need two rtp sockets |
| 16:19.24 | jkroon | and after how much rtp do we narrow? Ie, do we follow the rtp bleed restriction code stuff? |
| 16:19.36 | jkroon | Kobaz, in my case where I have IPv4 + IPv6 I do. |
| 16:20.13 | Kobaz | oooh |
| 16:20.14 | Kobaz | right |
| 16:20.15 | Kobaz | yes |
| 16:20.25 | jkroon | because 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.33 | jkroon | neither option is very enticing. |
| 16:21.18 | Kobaz | ah |
| 16:21.18 | Kobaz | yeah |
| 16:21.25 | Kobaz | well multiple rtp's sounds like the way to go |
| 16:21.29 | jkroon | in 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.31 | Kobaz | and then you bind a transport to an rtp |
| 16:21.52 | Kobaz | just like multiple transports, i can see a need for multiple rtp binds |
| 16:22.00 | *** join/#asterisk tsal (~tsal@i59F52D59.versanet.de) |
| 16:22.08 | jkroon | well, that doesn't necessarily work either, since you may not want to preclude IPv6 RTP in the case of IPv4 SIP transport. |
| 16:22.38 | Kobaz | What about linking multipel rtp's |
| 16:22.49 | Kobaz | like multiple contacts... you would add as many rtps as are supported on that transport |
| 16:23.38 | jkroon | and 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.56 | jkroon | there are many, many questions, and I don't think many of them have easy answers btw. |
| 16:24.23 | Kobaz | yeah |
| 16:24.30 | jkroon | but yea, i need to get this back on my todo list. |
| 16:24.51 | jkroon | as things stand currently, I'd solve this with ipsets. |
| 16:26.12 | jkroon | in 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.23 | jkroon | hmm, I might have an even better hack for you: |
| 16:27.17 | Kobaz | i really don't want to do iproute if there's a (easy) way to do it in asterisk |
| 16:27.52 | jkroon | iptables -t nat PREROUTING -i eth?? -m udp ! --dport 5060 -j DNAT --to-destination prim.ip |
| 16:28.12 | jkroon | that will result in conntrack entry dealing with the heavy lifting for you potentially. |
| 16:28.22 | jkroon | --dport 10000:200001 might be better. |
| 16:28.39 | jkroon | and this assumes remote side sends RTP first. |
| 16:28.58 | jkroon | agreed with your last statement, but I don't think there is an easy way in asterisk currently. |
| 16:28.59 | Kobaz | wouldn't this need to be SNAT ? |
| 16:30.11 | jkroon | ironically, 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.23 | Kobaz | ah hmm |
| 16:30.42 | jkroon | I originally figured this out with openvpn listening on multiple WAN interfaces (0.0.0.0) with source-based routing. |
| 16:31.09 | jkroon | so ended up changing this so that openvpn binds to LAN side address, then DNAT all WAN traffic to the LAN address. |
| 16:31.47 | jkroon | later 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.14 | jkroon | mostly try to avoid those kind of hacks with voice because it's damn hard to trouble shoot. |
| 16:32.19 | Kobaz | yeah |
| 16:32.24 | jkroon | but we do use this with STUN. |
| 16:32.32 | Kobaz | So... ICE can possibly fix my issue? |
| 16:32.39 | Kobaz | to determine the best match for rtp ? |
| 16:32.51 | jkroon | i'd try and use media-address. |
| 16:33.00 | jkroon | if you know over which WAN link client will connect. |
| 16:33.06 | Kobaz | i don't |
| 16:33.14 | Kobaz | so i'll need a dynamic media-address |
| 16:33.23 | jkroon | then you're in the same boat as me (for completely different reasons) |
| 16:33.48 | jkroon | can you get asterisk to at least transmit the correct address in SDP? |
| 16:34.00 | Kobaz | yes |
| 16:34.01 | Kobaz | it does |
| 16:34.20 | jkroon | ok, then possibly the DNAT trick *might* work in your use case. |
| 16:34.37 | jkroon | assuming asterisk waits for remote side to send RTP first. |
| 16:34.43 | jkroon | conntrack -L becomes your friend here. |
| 16:34.57 | Kobaz | k |
| 16:35.16 | jkroon | give it a shot, would love to know your final pjsip conig (extract) and netfilter rules. |
| 16:53.21 | jkroon | Kobaz, 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.46 | Kobaz | ah |
| 16:54.02 | jkroon | or even IP versions, so connect initially with IPv4 then switch to IPv6. |
| 16:54.17 | Kobaz | yeah you can reinvite |
| 16:54.50 | jkroon | I *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.24 | Kobaz | yup |
| 16:55.25 | jkroon | this implies though that we have access to the ast_sip_transport on which the INVITE was received when we create the SDP. |
| 16:55.30 | Kobaz | exactly |
| 16:56.00 | Kobaz | static int create_rtp(struct ast_sip_session *session, struct ast_sip_session_media *session_media, |
| 16:56.00 | Kobaz | <PROTECTED> |
| 16:56.09 | jkroon | also, what do you do, if bind_rtp_to_media_address is true, and you have different addresses for the two transports? |
| 16:56.16 | Kobaz | so... I don't have the transport... that's the issue |
| 16:56.28 | Kobaz | I have the session... and I should be able to pull the SDP and then figure out the transport? |
| 16:56.34 | jkroon | if you can find all callers of that, and check if the transport is available there, then you could in theory add it. |
| 16:56.39 | Kobaz | yheah |
| 16:57.15 | jkroon | anyway, i need to go make dinner, was an insightful discussion, even if no solutions was found. |
| 17:00.36 | Kobaz | thanks |
| 17:00.44 | Kobaz | happy someone's here to not argue with me :) |
| 17:03.05 | seanbright | are people arguing with you? |
| 17:03.22 | Kobaz | heh, mostly Samot |
| 17:03.28 | Kobaz | not happy with how i've set this up |
| 17:03.31 | seanbright | that is not him arguing |
| 17:03.35 | seanbright | you don't want to see him argue |
| 17:03.40 | Kobaz | aha |
| 17:05.11 | Samot | Kobaz: 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.02 | seanbright | Samot: STOP ARGUING |
| 17:12.26 | seanbright | let me see if i understand what is going on, because this is important |
| 17:12.33 | seanbright | someone is here... asking for help |
| 17:12.43 | seanbright | you are asking them to try something |
| 17:12.43 | *** join/#asterisk sinaowolabi (~Sina@41.190.31.8) |
| 17:12.49 | seanbright | and then they are not trying |
| 17:13.00 | seanbright | so 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.52 | Samot | seanbright: Simple, because I'm being forced to. |
| 17:17.04 | Samot | "I have a problem." |
| 17:17.08 | Samot | "Ok, try X" |
| 17:17.19 | Samot | "Oh I don't think that's relevant. I don't see what it will accomplish" |
| 17:17.28 | Samot | "OK, try Y" |
| 17:17.30 | Samot | "Oh I don't think that's relevant. I don't see what it will accomplish" |
| 17:19.59 | Kobaz | Samot: the reverse order transport, not yet... i'm dealing with other stuff right now, but will do |
| 17:20.29 | zgu | how can i make a dialplan pattern that matches E.164 numbers (starting with +)? |
| 17:20.45 | Kobaz | Samot: 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.49 | Kobaz | albiet many times |
| 17:20.54 | Samot | zgu: The same way you do any others but you start with the + |
| 17:21.16 | Samot | Kobaz: OK let me get some context here. |
| 17:21.18 | Kobaz | And 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.26 | Samot | Kobaz: How many setups have you done like this in the past? |
| 17:21.41 | zgu | i tried "_+." and it didn't seem to work |
| 17:21.41 | Kobaz | Multiple wan's on the same box? just this one |
| 17:21.46 | Samot | OK |
| 17:22.04 | Kobaz | But I know asterisk well enough to know what test cases would be relavent in the situations i understand well |
| 17:22.06 | Samot | Me? Over the course of my career, a dozen to two dozen |
| 17:22.15 | zgu | all (UDP:10.x.x.x:5062) to extension '+11235551212' rejected because extension not found in context 'from-internal'. |
| 17:22.21 | Samot | So I kinda know WTF I am talking about. |
| 17:22.22 | Kobaz | But you've never set up one exactly like this |
| 17:22.27 | Samot | Really? |
| 17:22.36 | Samot | You're probably right |
| 17:22.51 | Samot | I wouldn't be using plain Asterisk as an SBC |
| 17:22.58 | Kobaz | correct |
| 17:23.02 | Samot | I wouldn't need two have two ether's for each WAN |
| 17:23.03 | Kobaz | I understand that |
| 17:23.11 | Samot | I would have a properly designed solution |
| 17:23.15 | Samot | So you're right, not like this. |
| 17:23.23 | Samot | Hence all my "Why is this..." questions |
| 17:23.26 | Kobaz | This is what we have... so... i'm dealing with it, but anyway. i need to go fix something |
| 17:23.36 | Samot | Oh yeah you do. |
| 17:23.41 | Kobaz | Yeah, I get it... the why is important if there's other ways to solve the issue |
| 17:24.00 | Samot | Yeah. Like running an Asterisk instance per WAN. |
| 17:24.05 | Samot | It's a way |
| 17:24.12 | Samot | Not a right way or the proper way |
| 17:24.12 | Kobaz | right, not ideal |
| 17:24.14 | Samot | But it's a way |
| 17:24.16 | Kobaz | but... it should work actually |
| 17:24.21 | Kobaz | it should work pretty well actually, oddly enough |
| 17:24.24 | Samot | I'm not saying it wouldn't. |
| 17:24.34 | Samot | I'm just saying it is improper. |
| 17:24.48 | Samot | Why are you painting yourself into a corner? |
| 17:24.53 | Kobaz | I'm not |
| 17:24.56 | Samot | OK. |
| 17:25.00 | Kobaz | I'm busting through the wall, of the corner someone else painted me into |
| 17:25.27 | Kobaz | Making do with what I have, and getting out and making it work, in some fashion |
| 17:25.34 | Kobaz | so hopefully without too much code changes |
| 17:25.55 | Kobaz | or without having to rip it all apart and do Kamailio, or have them redo their firewall and get all that worked out |
| 17:26.10 | zgu | does the + need to be escaped in patterns or something? |
| 17:26.17 | Kobaz | or many other ways... this is the typical "We're really friggin close, so lets dig a little more" |
| 17:26.37 | Kobaz | zgu: you need to explitly match the pattern received |
| 17:27.01 | Kobaz | if you don't have a literal +11235551212 in your dialplan, or +1X. or something that matches it... it won't match |
| 17:27.27 | Kobaz | zgu: try this: dialplan show +11235551212@from-internal |
| 17:27.28 | kjetilho | it may be easier to just convert + to 00. |
| 17:27.57 | Kobaz | it'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.43 | zgu | hmm, with exten => _+.,1,... it shows the dialplan when i do dialplan show +1...@from-internal |
| 17:30.06 | zgu | but dialing that from a phone fails. specifically trying to redial an incoming call since my sip trunk formats everything as e.164 |
| 17:32.00 | Kobaz | show? dpaste.com |
| 17:35.10 | Kobaz | what's your console look like? |
| 17:35.27 | zgu | https://dpaste.com/CUPL3WEFT |
| 17:40.30 | Kobaz | asterisk version? |
| 17:42.31 | Samot | Uhm... |
| 17:42.38 | Samot | There's no match in the context. |
| 17:43.07 | Samot | You can't have two from-internal contexts |
| 17:43.23 | Samot | Asterisk is a top down setup |
| 17:43.32 | Samot | The first context to load wins |
| 17:43.47 | Samot | Just like transports, endpoints, peers |
| 17:44.00 | Kobaz | sure you can. if one of them is marked extend |
| 17:44.25 | Samot | Oh wait...I'm reading this wrong. |
| 17:44.26 | Kobaz | But his issue is not two from-internal contexts |
| 17:44.33 | Kobaz | He just ran the command twice |
| 17:44.59 | Kobaz | zgu: asterisk version? |
| 17:45.23 | Kobaz | Something 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.31 | zgu | 18.1.1 |
| 17:45.34 | Kobaz | I haven't seen that, maybe that's new in 17/18 ? |
| 17:45.37 | Kobaz | Ah, that's why |
| 17:45.52 | Kobaz | zgu: See if you have this issue in 16.15.1 |
| 17:46.07 | Kobaz | I'm glad that finally got added |
| 17:46.30 | Kobaz | I'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.39 | zgu | hmm |
| 17:47.10 | Kobaz | zgu: that does look right, this could very well be a bug |
| 17:47.19 | Samot | zgu: What happens if it is _+1.? |
| 17:47.28 | zgu | same thing i believe |
| 17:47.37 | Samot | Can you confirm that? |
| 17:48.21 | zgu | same with _+1. |
| 17:48.58 | zgu | and _+1NXXNXXXXXX |
| 17:49.45 | Kobaz | zgu: you may have to dump the sip traffic |
| 17:49.50 | Kobaz | you may have a non-printable in there? |
| 17:49.55 | Kobaz | what type of device is sending this invite? |
| 17:50.09 | Samot | Show an entire call out |
| 17:50.13 | Samot | asterisk -rvvvvvvvvvv |
| 17:50.33 | zgu | tried a grandstream GXP1628 and two different android softphones |
| 17:51.10 | Samot | Show a call that fails, full verbose output |
| 17:51.25 | Kobaz | okay so it's probably not crap in the invite |
| 17:51.26 | Samot | turn on the pjsip logger as well for extra details |
| 17:51.36 | Kobaz | but you never know |
| 17:52.16 | zgu | tshark summary shows 'SIP/SDP 1489 Request: INVITE sip:+16362021234@10.6.1.38' |
| 17:52.53 | Samot | zgu: Please provide the information asked for. |
| 17:53.40 | zgu | how do i turn on pjsip logging? |
| 17:54.21 | Kobaz | pjsip set logger on |
| 17:54.26 | Samot | Also fix your priority |
| 17:54.32 | Kobaz | oh yeah |
| 17:54.36 | Kobaz | ooooh |
| 17:54.37 | Samot | '_+.' => 4. Dial(PJSIP/${EXTEN}@twilio-na-us) |
| 17:54.37 | Kobaz | haha |
| 17:54.43 | Samot | That's not going to work |
| 17:54.44 | Kobaz | yeaaah that's the problem, why didn't i catch that |
| 17:54.57 | Kobaz | My brain skimed over and assumed it was prio 1 |
| 17:55.33 | zgu | ohhhh i forgot to add a priority to that line |
| 17:56.19 | zgu | ah that was it. thanks |
| 17:56.33 | Kobaz | [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.54 | Kobaz | ^^ the error message should mention Priority 1 not found |
| 17:56.56 | Kobaz | like a goto |
| 17:57.56 | zgu | and the dialplan show console command doesn't care there's no priority 1 |
| 17:58.07 | Kobaz | well yeah, it's just showing you what's there |
| 17:58.09 | Kobaz | which is fine |
| 17:58.16 | zgu | right |
| 17:58.45 | Kobaz | goto 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.59 | Samot | Because you can define all those. |
| 18:04.10 | Samot | For a peer/endpoint you're just defining a context |
| 18:04.25 | Samot | You could match on callerid |
| 18:04.43 | Samot | It's always going to start at 1 |
| 18:05.04 | Kobaz | But to make it more obvious, yes it always starts at 1 |
| 18:05.14 | Kobaz | But, the error message just says 'not found' |
| 18:05.26 | Kobaz | +11235551212 DOES exist in context 'from-internal' |
| 18:05.30 | Kobaz | so that's why it's confusing for new users |
| 18:05.41 | Kobaz | it does exist, just not priority 1 |
| 18:06.51 | Samot | So I guess it needs to include the included contexts too? |
| 18:07.06 | Samot | Because I could make from-internal have nothing but include => statements. |
| 18:07.24 | Samot | It's still going to say it wasn't found in the context "from-internal" |
| 18:07.28 | Kobaz | correct |
| 18:07.37 | Kobaz | but, it would be specifically useful to say, priority 1 not found |
| 18:07.41 | Samot | Which doesn't really help if it's support to match in the 3rd include=> statement |
| 18:07.59 | Kobaz | really the syntax should be the same as a goto |
| 18:08.27 | Samot | What if there is no match? |
| 18:08.37 | Samot | Like not a literal match |
| 18:08.38 | Kobaz | since it's really a ast_pbx_start() that's occuring at that point, to a context,exten,prio |
| 18:08.43 | Kobaz | If there's no match that's fine |
| 18:08.54 | Samot | So there needs to be two errors |
| 18:09.05 | Samot | Either it exists with a wrong priority or it doesn't. |
| 18:09.09 | Kobaz | one would catch all the situations, I think |
| 18:09.23 | Samot | But then it would be incorrect if there was no real match |
| 18:09.23 | Kobaz | you don't have to double check to see exactly why it failed, just that it failed, and how it failed |
| 18:09.43 | Samot | Adding "priority 1 not found" or whatever |
| 18:09.54 | Samot | Would mean when *no match exists* that is still the error |
| 18:09.58 | Kobaz | correct |
| 18:10.07 | Samot | Making it seem like there is a match just wrong priority |
| 18:10.11 | Samot | Vs not one being there. |
| 18:10.35 | Kobaz | better error: New Call Rejected, context,exten,priority Not found: (from-internal, +11235551212, 1) |
| 18:10.42 | Kobaz | Basically a goto error |
| 18:10.45 | Kobaz | short and sweet |
| 18:10.53 | Samot | OK. |
| 18:11.11 | Samot | Go put in a feature request |
| 18:11.34 | Kobaz | Not a bad idea |
| 18:11.51 | Kobaz | Except the tracker doesn't do feature requests, it would need a gerrit patch |
| 18:12.04 | Kobaz | which would be a one line patch |
| 18:12.14 | Kobaz | so, yeah |
| 18:12.41 | Kobaz | I might play with the case |
| 18:12.47 | Kobaz | and 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) |