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

17 Jan 2022

David,
Thank you for the suggestion.
Do you have any sample config files you can point me at?

--
^C

On 1/17/22 12:41 AM, David Villasmil wrote:
...
  Take a look at freeSWITCH

 On Mon, 17 Jan 2022 at 00:58, Chad &lt;ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:

     Hmm, it did not fix it (calls still work with my other carriers).
     It looks to me like it should work, it does use the external IP for everything.

     It generates an error in the log about making your existing address:
     topoh [topoh_mod.c:179]: mod_init(): mask address matches myself [209.###.###.###]

     Here is ther 200 and ACK.
     SIP/2.0 200 OK
     Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.0
     Via: SIP/2.0/UDP
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKrs8bqi00cg14535baf70.1
     Record-Route:
<sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*>
     Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75>
     Record-Route: <sip:64.###.###.###;lr;ftag=as471a1f75>
     From: "Anonymous"
<sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75
     To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1
     Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@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:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF*>
     Content-Type: application/sdp
     Content-Length: 274

     v=0
     o=root 1644013823 1644013823 IN IP4 209.###.###.###
     s=Asterisk PBX 16.18.0
     c=IN IP4 209.###.###.###
     t=0 0
     m=audio 19180 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:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF* SIP/2.0
     Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.2
     Via: SIP/2.0/UDP
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKvtgb6f1048h1g6l9s890.1
     Max-Forwards: 67
     From: "Anonymous"
<sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75
     To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1
     Contact: <sip:anonymous@206.###.###.###:5060;transport=udp>
     Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@10.44.###.###:5060
     CSeq: 102 ACK
     User-Agent: packetrino
     Content-Length: 0
     Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75>
     Route:
<sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*>

     --
     ^C

     On 1/16/22 3:16 PM, Ovidiu Sas wrote:
  Use your 209.x external IP.

 On Sun, Jan 16, 2022 at 18:07 Chad &lt;ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>> wrote:

     Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but again
because 172.16.x.x is also a      private IP
      it is the same as using my real 10.x.x.x IP.
The carrier's ACK throws away the local IP and sends the      response to my
      209.x external IP.

     --
     ^C

     On 1/16/22 1:38 PM, Ovidiu Sas wrote:
      > Have you tried using the mask_ip param:
      > https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask…

<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>

 <https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip 

<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>
       >
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip  
   <https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>

 <https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip 

<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>>
       >
      > -ovidiu
      >
      > On Sun, Jan 16, 2022 at 16:09 Chad &lt;ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@hotmail.com     
<mailto:ccolumbu@hotmail.com>>>> wrote:
       >
      >     I found a sample config file using topoh, which I copied (with some
changes) and added the topoh      module to my
      config.
      It works fine, but it does not solve the
problem.
     In fact it has the exact same problem, because all the topoh module does is replace
one private IP with      another in the
      >     2nd (top most) Record-Route header.
      >     So the carrier still changes the ACK to the public IP and the call is still
broken in the exact same way.
      >     It was super easy to add, but does not work, 1 possible solution down.
      >
      >     --
      >     ^C
      >
      >
      >     On 1/16/22 8:26 AM, Ovidiu Sas wrote:
      >      > 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>      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
       >     (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.enco…

<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>

 <https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact

<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>>
       >   
 <https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact

<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>

 <https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact

<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.en…

<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.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.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.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.co…

<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode>

 <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode

<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode>>
       >   
 <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode

<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode>

 <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode

<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 &lt;ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
     <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>

 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>
       >   
 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>

 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>> for seqno 102
(Critical Response) -- See
       >      >>>>
https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions     
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>

 <https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions     
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>>
       >   
 <https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions     
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>

 <https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions     
<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     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>
     <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
     <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>

 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>

 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060     
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>> - no
       >      >>>> reply to our
critical packet (see https://wiki.asterisk.org/wik <https://wiki.asterisk.org/wik>
     <https://wiki.asterisk.org/wik <https://wiki.asterisk.org/wik>>
      <https://wiki.asterisk.org/wik
<https://wiki.asterisk.org/wik> <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>     
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
       >     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 <mailto:ccolumbu@hotmail.com>     
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
      >     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 <mailto:ccolumbu@hotmail.com>     
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
      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 <mailto:ccolumbu@hotmail.com>     
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
      <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@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
       >     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 <http://10.10.10.#%23%23]:5060>     
<http://10.10.10.#%23%23]:5060 <http://10.10.10.#%23%23]:5060>>
      <http://10.10.10.#%23%23]:5060
<http://10.10.10.#%23%23]:5060> <http://10.10.10.#%23%23]: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
       >     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 <mailto:sr-users@lists.kamailio.org>     
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
      <mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> <mailto:sr-users@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     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
       >   
 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>>
       >     
>>>>>>>>>>>
      >      >>>>>>>>>>>
      >      >>>>>>>>>>>
      >      >>>>>>>>>>> --
      >      >>>>>>>>>>> VoIP Embedded, Inc.
      >      >>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com> <http://www.voipembedded.com     
<http://www.voipembedded.com>> <http://www.voipembedded.com
<http://www.voipembedded.com>
      <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>     
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
      <mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> <mailto:sr-users@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     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
       >   
 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users     
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>>
       >     
>>>>>>>>>
      >      >>>>>>>>>
      >      >>>>>>>>>
      >      >>>>>>>
      >      >>>>>>>
      >      >>>>>>>
      >      >>>>>
      >      >>>>>
      >      >>>>>
      >      >>>
      >      >>>
      >      >>>
      >      >
      >      >
      >      >
      >
      > --
      > VoIP Embedded, Inc.
      > http://www.voipembedded.com <http://www.voipembedded.com>
<http://www.voipembedded.com      <http://www.voipembedded.com>>
<http://www.voipembedded.com <http://www.voipembedded.com>
     <http://www.voipembedded.com <http://www.voipembedded.com>>>

 --
 VoIP Embedded, Inc.
 http://www.voipembedded.com <http://www.voipembedded.com>
<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
     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

 -- 
 Regards,

 David Villasmil
 email: david.villasmil.work(a)gmail.com <mailto:david.villasmil.work@gmail.com>
 phone: +34669448337

 __________________________________________________________
 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 

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

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