Re: [SR-Users] Help with rewriting headers for NAT manually

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 &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@hotmail.com>> wrote: > > Ok so in short I was not doing anything wrong (although I had some miss-configurations), but the carrier is

> are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense they meant in the

> 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

> 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

> with this exact same issue (I personally know of at least 2 bad actor carriers right now) and create some

> template or snippet that we can publicly publish on the Kamailio docs or wiki for all of the Kamailio community

> 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

> SIP RFC well enough to fight back. So why not build a solution for everyone out there that has to deal with a

> > -- > ^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.enco…

>> https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…

>> https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…

>> >> Regards, >> Ovidiu Sas >> >> On Sat, Jan 15, 2022 at 1:28 PM Chad &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@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

>>> 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

>>> reply to our critical packet (see https://wiki.asterisk.org/wik <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 &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@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

>>>>> >>>>> "The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests.

>>>>> 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

>>>>> >>>>> >>>>> -- >>>>> ^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 &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@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

>>>>>>> rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact

>>>>>>> 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

>>>>>>> IPs. >>>>>>> If it was a normal IP it would work fine. It has something to do with the routing table and how mhomed

>>>>>>> >>>>>>> -- >>>>>>> ^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 &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@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

>>>>>>>>> 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

>>>>>>>>> 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 &lt;ccolumbu(a)hotmail.com <mailto:ccolumbu@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

>>>>>>>>>>> servers (via dispatcher). >>>>>>>>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created

>>>>>>>>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the

>>>>>>>>>>> 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 <http://10.10.10.#%23%23]: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

>>>>>>>>>>> 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,

>>>>>>>>>>> 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

>>>>>>>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field

>>>>>>>>>>> >>>>>>>>>>> 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(a)lists.kamailio.org <mailto: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 <http://www.voipembedded.com> >>>>>>>>>> >>>>>>>>>> __________________________________________________________ >>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>>>>>>         * sr-users(a)lists.kamailio.org <mailto: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

>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >>