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

Ovidiu Sas osas at voipembedded.com
Sat Jan 15 19:07:58 CET 2022


It doesn't look good because you have the public IP twice in the
Record-Route header.
You need to replace the
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
and all should be good.

If your carrier is telling you that the IP address in Contact should
be public, then you need to find an RFC compliant carrier (or mangle
the Contact to make them happy).
Most of the time I fight with them until they have this fixed.
Sometimes it's a lost battle and you just need to hack your config to
make it work.

I have deployed kamailio using this setup and if you deal with RFC
compliant end-point (carriers, softphones, hardphones) then all is
good.

-ovidiu

On Sat, Jan 15, 2022 at 12:14 PM Chad <ccolumbu at hotmail.com> wrote:
>
> It would be great if you are right and I am simply doing something else wrong in the config file!
>
> Here is the 200 OK (note I have enable_double_rr enabled):
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
> Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
> Record-Route: <sip:209.###.###.###:5060;r2=on;lr=on;ftag=gK0e16642e>
> Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=gK0e16642e>
> Record-Route: <sip:18.###.###.###;lr;ftag=gK0e16642e;did=6dc.283659a3>
> From: <sip:+1202#######@66.###.###.###:5060>;tag=gK0e16642e
> To: <sip:+1845#######@sip-us-west-2a.numberaccess.net:5060>;tag=as488a6fb4
> Call-ID: 202251204_54250714 at 206.###.###.###
> CSeq: 710596 INVITE
> Server: Asterisk PBX 16.18.0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:1845#######@10.###.###.###:5060>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 272
>
> v=0
> o=root 153822920 153822920 IN IP4 209.###.###.###
> s=Asterisk PBX 16.18.0
> c=IN IP4 209.###.###.###
> t=0 0
> m=audio 17198 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
>
>
> --
> ^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 <ccolumbu at 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 <ccolumbu at 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 <ccolumbu at 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 at 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 at 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



More information about the sr-users mailing list