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

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