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

Ovidiu Sas osas at voipembedded.com
Sat Jan 15 19:09:12 CET 2022 

Oops ... copy/paste mistake:
You need to replace:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE

-ovidiu

On Sat, Jan 15, 2022 at 1:07 PM Ovidiu Sas <osas at voipembedded.com> wrote:
>
> 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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

More information about the sr-users mailing list