Most of the time, if you get the right person on the carrier's side and you explain the situation, they will come up with a solution. If not, you need to break the RFC in a way that will counterpart their breakage.
The carrier is also using a SIP proxy (maybe kamailio, who knows). In the old days, the default kamailio config was using fix_nated_contact() to deal with NATed devices and this is exactly the behavior that you are seeing. The recommended way to deal with NATed devices is to use add_contact_alias([ip_addr, port, proto]) which is RFC compliant. There are several solution for this scenario: - mangle the signaling to allow proper routing on your end - use a B2BUA in between your kamailio and carrier - configure kamailio to use one of the topology hiding modules: topoh, topos, topos_redis - maybe something else ... :) There's no right or wrong approach, one must be comfortable with the chosen solution to be able to maintain it. -ovidiu On Sat, Jan 15, 2022 at 9:14 PM Chad <ccolu...@hotmail.com> wrote: > > Ok so in short I was not doing anything wrong (although I had some > miss-configurations), but the carrier is (i.e. they > are a bad actor). When they said I was doing it wrong, they did not mean in > the RFC sense they meant in the "to work > with us" sense. Now in order for me to get it to work with their SBC I have > to mangle the contact on the way out an > unmangle it on the return in Kamailio somehow, as I originally purposed. > However I have no idea how to do that :) > > Shouldn't we (the Kamailio community) assume there are lots of bad actors out > there and possibly many Kamailio users > with this exact same issue (I personally know of at least 2 bad actor > carriers right now) and create some kind of > template or snippet that we can publicly publish on the Kamailio docs or wiki > for all of the Kamailio community to use > for this use case? > > I have been fighting with carriers about this for years and they always said > I was doing it wrong and I don't know the > SIP RFC well enough to fight back. So why not build a solution for everyone > out there that has to deal with a bad actor? > > -- > ^C > > > On 1/15/22 11:40 AM, Ovidiu Sas wrote: > > As expected, your carrier is bogus and "thinks" it knows better. > > Your carrier is treating your setup as a dumb endpoint and is > > re-writing the Contact header: > > You provide this contact header in 200 OK: > > Contact: <sip:928#######@10.###.###.104:5060> > > The carrier should set the RURI in ACK like this: > > ACK sip:928#######@10.###.###.104:5060 SIP/2.0 > > Instead, your ACK is sent to you like this: > > ACK sip:928#######@209.###.###.###:5060 SIP/2.0 > > > > The RURI in ACK should point to the private IP of the asterisk server, > > not to the public IP of the kamailio server. > > You need to ask the carrier to follow the SIP RFC and not treat your > > endpoints like dumb SIP endpoints. > > > > There's a high chance that they won't do it :) > > Your best chance is to manually mangle the URI in Contact in the 200 > > OK in a way that when you receive the ACK with the mangled RURI, you > > can restore the original URI and let kamailio do the proper routing to > > the private IP of the asterisk serverr. > > You should be able to achieve this by using one of the following functions: > > https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact > > https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact > > https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode > > > > Regards, > > Ovidiu Sas > > > > On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolu...@hotmail.com> wrote: > >> > >> I changed the listen per your advice and here is the 200 and ACK. > >> I get no audio and the the call disconnects and I see this is the Asterisk > >> log: > >> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout > >> reached on transmission > >> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 > >> (Critical Response) -- See > >> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > >> Packet timed out after 6401ms with no response > >> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call > >> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no > >> reply to our critical packet (see https://wiki.asterisk.org/wik > >> > >> FYI 10.###.###.254 is the private virtual IP on the Kamailio server and > >> 10.###.###.104 is the asterisk box. > >> > >> SIP/2.0 200 OK > >> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0 > >> Via: SIP/2.0/UDP > >> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1 > >> Record-Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0> > >> Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0> > >> Record-Route: <sip:64.###.###.###;lr;ftag=as04035ef0> > >> From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as04035ef0 > >> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05 > >> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 > >> CSeq: 102 INVITE > >> Server: Asterisk PBX 16.18.0 > >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > >> PUBLISH, MESSAGE > >> Supported: replaces, timer > >> Contact: <sip:928#######@10.###.###.104:5060> > >> Content-Type: application/sdp > >> Content-Length: 274 > >> > >> v=0 > >> o=root 1911037741 1911037741 IN IP4 209.###.###.### > >> s=Asterisk PBX 16.18.0 > >> c=IN IP4 209.###.###.### > >> t=0 0 > >> m=audio 11384 RTP/AVP 0 101 > >> a=rtpmap:0 PCMU/8000 > >> a=rtpmap:101 telephone-event/8000 > >> a=fmtp:101 0-16 > >> a=ptime:20 > >> a=maxptime:150 > >> a=sendrecv > >> a=nortpproxy:yes > >> > >> ACK sip:928#######@209.###.###.###:5060 SIP/2.0 > >> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2 > >> Via: SIP/2.0/UDP > >> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1 > >> Max-Forwards: 67 > >> From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as04035ef0 > >> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05 > >> Contact: <sip:anonymous@206.###.###.###:5060;transport=udp> > >> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 > >> CSeq: 102 ACK > >> User-Agent: packetrino > >> Content-Length: 0 > >> Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0> > >> Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0> > >> > >> > >> -- > >> ^C > >> > >> > >> On 1/15/22 10:21 AM, Ovidiu Sas wrote: > >>> This is false. The IP in the Contact header must be routable by the > >>> SIP hop from the top Record-Route header in the reply. > >>> The carrier (and it seems that they have a PROXY also) must be able to > >>> route to their adjacent SIP hop, which is your public IP (the IP in > >>> the second Record-Route header). > >>> It seems that the carrier is not taking into account that they might > >>> interface with other proxies. > >>> Most likely, your carrier expects to interface with a simple SIP UA, > >>> not with another proxy. This is a pretty common setup for most of the > >>> carriers, although many new carrier implementations are taking care of > >>> the proxy to proxy calls. > >>> > >>> It would be helpful to see the ACK that is sent by the carrier in > >>> response to your 200ok (after you fix your config and you have your > >>> private IP listed in the Record-Route header). > >>> > >>> -ovidiu > >>> > >>> On Sat, Jan 15, 2022 at 12:33 PM Chad <ccolu...@hotmail.com> wrote: > >>>> > >>>> Hmm, I don't think you are right that the Contact header can be a > >>>> private IP even if the RR is correct. > >>>> I did some research on it and I found several places saying it must be a > >>>> routable IP which is what the carrier also said. > >>>> > >>>> "The Contact header contains the SIP URI where the client wants to be > >>>> contacted for subsequent requests. That means that > >>>> the host part of the URI must be globally reachable by anyone. > >>>> If your contact contains a private IP (behind a NAT?) then it is wrong, > >>>> because other peers cannot reach you with that." > >>>> > >>>> > >>>> -- > >>>> ^C > >>>> > >>>> > >>>> On 1/15/22 9:05 AM, Ovidiu Sas wrote: > >>>>> You have a different problem then. > >>>>> Having private IPs in Contact is fine. You need to lose route the > >>>>> calls (kamailio will add two Record-Route headers) and the origination > >>>>> server will set the RURI to the private IP from Contact, but it will > >>>>> send the in-dialog requests to the public IP of kamailio. This has > >>>>> nothing to do with virtual IPs. > >>>>> Maybe you have a buggy client that doesn't do proper loose routing. > >>>>> > >>>>> -ovidiu > >>>>> > >>>>> On Sat, Jan 15, 2022 at 11:50 AM Chad <ccolu...@hotmail.com> wrote: > >>>>>> > >>>>>> Ovidiu, > >>>>>> Thank you again for your response. > >>>>>> One is public (an internet IP) and one is private (a 10.x ip). > >>>>>> Apparently this is a known problem with virtual IPs, it does not work. > >>>>>> When the asterisk server responds to the invite it sends a contact > >>>>>> header with the private IP and Kamailio does not > >>>>>> rewrite it to the advertised public IP. So the originating server sees > >>>>>> the private IP in the Contact header and tries to > >>>>>> send the traffic to the 10.x IP (which is non-routable) and the call > >>>>>> dies. > >>>>>> I have been trying things for a long time to fix this (years) what you > >>>>>> are saying will not fix it because of the virtual > >>>>>> IPs. > >>>>>> If it was a normal IP it would work fine. It has something to do with > >>>>>> the routing table and how mhomed detects networks. > >>>>>> > >>>>>> -- > >>>>>> ^C > >>>>>> > >>>>>> > >>>>>> On 1/15/22 8:36 AM, Ovidiu Sas wrote: > >>>>>>> Hello Chad, > >>>>>>> > >>>>>>> The floating IPs that you have, are they both private IPs or one > >>>>>>> private IP and the other one a public IP? > >>>>>>> > >>>>>>> If you have to two floating private IPs, then you need a config like > >>>>>>> this: > >>>>>>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP > >>>>>>> listen=FLOATING_UDP_PRIVATE2 > >>>>>>> > >>>>>>> In the config, before relaying the initial INVITE you need to detect > >>>>>>> the direction of the call and set $fs accordingly: > >>>>>>> if (CAL_FROM_PRIVATE_TO_PUBLIC) { > >>>>>>> $fs = udp:FLOATING_UDP_PRIVATE1 > >>>>>>> } > >>>>>>> else { > >>>>>>> $fs = udp:FLOATING_UDP_PRIVATE2 > >>>>>>> } > >>>>>>> > >>>>>>> If you have a floating private IPs and a floating public IP, then you > >>>>>>> need a config like this: > >>>>>>> listen=FLOATING_UDP_PRIVATE > >>>>>>> listen=FLOATING_UDP_PUBLIC > >>>>>>> > >>>>>>> There should be no need to force the socket, but if you do, there's no > >>>>>>> harm (actually it's better and faster). > >>>>>>> > >>>>>>> Hope this clarifies things and helps, > >>>>>>> -ovidiu > >>>>>>> > >>>>>>> On Sat, Jan 15, 2022 at 9:48 AM Chad <ccolu...@hotmail.com> wrote: > >>>>>>>> > >>>>>>>> Ovidiu, > >>>>>>>> Thank you for your response. > >>>>>>>> > >>>>>>>> I have done that, in addition to the linux ip_nonlocal_bind I have > >>>>>>>> also set the Kamailio ip_free_bind=1 and it does not > >>>>>>>> work. > >>>>>>>> Here are my relevant config lines: > >>>>>>>> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 > >>>>>>>> listen=LISTEN_UDP_PUBLIC > >>>>>>>> > >>>>>>>> mhomed=1 > >>>>>>>> ip_free_bind=1 > >>>>>>>> > >>>>>>>> > >>>>>>>> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and > >>>>>>>> I have been using it for a long time and have > >>>>>>>> rebooted as well): > >>>>>>>> net.ipv4.ip_nonlocal_bind=1 > >>>>>>>> -- > >>>>>>>> ^C > >>>>>>>> > >>>>>>>> > >>>>>>>> On 1/15/22 4:55 AM, Ovidiu Sas wrote: > >>>>>>>>> Hello Chad, > >>>>>>>>> > >>>>>>>>> You can add a listen directive to your config for the virtual IPs > >>>>>>>>> (both public and private) and then you don't need to manually modify > >>>>>>>>> any headers or use force_send_socket(). > >>>>>>>>> You need to enable non local IP binding so kamailio can start on the > >>>>>>>>> server that doesn't have the virtual IP: > >>>>>>>>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind > >>>>>>>>> To make the change permanent, edit your sysctl.conf file and enable > >>>>>>>>> it there: > >>>>>>>>> net/ipv4/ip_nonlocal_bind = 1 > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Ovidiu Sas > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Sat, Jan 15, 2022 at 4:16 AM Chad <ccolu...@hotmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>> We are looking for some help (possibly a paid consultant) to help > >>>>>>>>>> us with our Kamailio setup. > >>>>>>>>>> To keep this as short as possible: we use Kamailio as a NAT proxy > >>>>>>>>>> to bridge our external IP and our private IP asterisk > >>>>>>>>>> servers (via dispatcher). > >>>>>>>>>> However both the external IP and the internal IP that the Kamailio > >>>>>>>>>> server uses are virtual IPs created by keepalived. > >>>>>>>>>> Because of that neither mhomed nor fix_nated_contact work, and we > >>>>>>>>>> use force_send_socket to direct the traffic. > >>>>>>>>>> We run linux Debian 10 for the OS. > >>>>>>>>>> Also we do not use a DB at all, everything is done with local > >>>>>>>>>> config files. > >>>>>>>>>> > >>>>>>>>>> The problem is that when traffic goes out the Contact header has a > >>>>>>>>>> private IP in it, like: > >>>>>>>>>> Contact: <sip:##########@10.10.10.###]:5060> > >>>>>>>>>> > >>>>>>>>>> There are 2 possible solutions to this: > >>>>>>>>>> 1. Make changes to linux, keepalived and/or Kamailio so that > >>>>>>>>>> Kamailio recognize the virtual IPs so that mhomed and > >>>>>>>>>> fix_nated_contact work as usual. > >>>>>>>>>> > >>>>>>>>>> 2. Create a manual header rewrite system. > >>>>>>>>>> > >>>>>>>>>> If solution #2: > >>>>>>>>>> What we need to do is create a way to rewrite the contact header > >>>>>>>>>> to the external IP on the way out, and on the way back > >>>>>>>>>> rewrite it back to the internal server that the call is already > >>>>>>>>>> connected to. > >>>>>>>>>> > >>>>>>>>>> Not sure if we will need to store those paths on the server or if > >>>>>>>>>> we can do some kind of cheat with another persistant > >>>>>>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. > >>>>>>>>>> store the internal IP in the name field or something). > >>>>>>>>>> > >>>>>>>>>> If anyone out there know of a way to do this or wants to give it a > >>>>>>>>>> try please reach out to me. > >>>>>>>>>> > >>>>>>>>>> Thank you all for your time. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> ^C > >>>>>>>>>> Chad > >>>>>>>>>> > >>>>>>>>>> __________________________________________________________ > >>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions > >>>>>>>>>> * sr-users@lists.kamailio.org > >>>>>>>>>> Important: keep the mailing list in the recipients, do not reply > >>>>>>>>>> only to the sender! > >>>>>>>>>> Edit mailing list options or unsubscribe: > >>>>>>>>>> * > >>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> VoIP Embedded, Inc. > >>>>>>>>> http://www.voipembedded.com > >>>>>>>>> > >>>>>>>>> __________________________________________________________ > >>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions > >>>>>>>>> * sr-users@lists.kamailio.org > >>>>>>>>> Important: keep the mailing list in the recipients, do not reply > >>>>>>>>> only to the sender! > >>>>>>>>> Edit mailing list options or unsubscribe: > >>>>>>>>> * > >>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > -- VoIP Embedded, Inc. http://www.voipembedded.com __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users