<div dir="auto">Take a look at freeSWITCH</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Jan 2022 at 00:58, Chad <<a href="mailto:ccolumbu@hotmail.com">ccolumbu@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm, it did not fix it (calls still work with my other carriers).<br>
It looks to me like it should work, it does use the external IP for everything.<br>
<br>
It generates an error in the log about making your existing address:<br>
topoh [topoh_mod.c:179]: mod_init(): mask address matches myself [209.###.###.###]<br>
<br>
Here is ther 200 and ACK.<br>
SIP/2.0 200 OK<br>
Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.0<br>
Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKrs8bqi00cg14535baf70.1<br>
Record-Route: <sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*><br>
Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75><br>
Record-Route: <sip:64.###.###.###;lr;ftag=as471a1f75><br>
From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75<br>
To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1<br>
Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@10.44.###.###:5060<br>
CSeq: 102 INVITE<br>
Server: Asterisk PBX 16.18.0<br>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE<br>
Supported: replaces, timer<br>
Contact: <sip:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF*><br>
Content-Type: application/sdp<br>
Content-Length: 274<br>
<br>
v=0<br>
o=root 1644013823 1644013823 IN IP4 209.###.###.###<br>
s=Asterisk PBX 16.18.0<br>
c=IN IP4 209.###.###.###<br>
t=0 0<br>
m=audio 19180 RTP/AVP 0 101<br>
a=rtpmap:0 PCMU/8000<br>
a=rtpmap:101 telephone-event/8000<br>
a=fmtp:101 0-16<br>
a=ptime:20<br>
a=maxptime:150<br>
a=sendrecv<br>
a=nortpproxy:yes<br>
<br>
<br>
ACK sip:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF* SIP/2.0<br>
Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.2<br>
Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKvtgb6f1048h1g6l9s890.1<br>
Max-Forwards: 67<br>
From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75<br>
To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1<br>
Contact: <sip:anonymous@206.###.###.###:5060;transport=udp><br>
Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@10.44.###.###:5060<br>
CSeq: 102 ACK<br>
User-Agent: packetrino<br>
Content-Length: 0<br>
Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75><br>
Route: <sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*><br>
<br>
--<br>
^C<br>
<br>
<br>
On 1/16/22 3:16 PM, Ovidiu Sas wrote:<br>
> Use your 209.x external IP.<br>
> <br>
> On Sun, Jan 16, 2022 at 18:07 Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>> wrote:<br>
> <br>
> 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<br>
> 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<br>
> 209.x external IP.<br>
> <br>
> <br>
> --<br>
> ^C<br>
> <br>
> <br>
> On 1/16/22 1:38 PM, Ovidiu Sas wrote:<br>
> > Have you tried using the mask_ip param:<br>
> > <a href="https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip" rel="noreferrer" target="_blank">https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip</a><br>
> <<a href="https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip" rel="noreferrer" target="_blank">https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip</a>><br>
> > <<a href="https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip" rel="noreferrer" target="_blank">https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip</a><br>
> <<a href="https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip" rel="noreferrer" target="_blank">https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip</a>>><br>
> ><br>
> > -ovidiu<br>
> ><br>
> > On Sun, Jan 16, 2022 at 16:09 Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> ><br>
> > I found a sample config file using topoh, which I copied (with some changes) and added the topoh module to my<br>
> config.<br>
> > It works fine, but it does not solve the problem.<br>
> > In fact it has the exact same problem, because all the topoh module does is replace one private IP with<br>
> another in the<br>
> > 2nd (top most) Record-Route header.<br>
> > So the carrier still changes the ACK to the public IP and the call is still broken in the exact same way.<br>
> > It was super easy to add, but does not work, 1 possible solution down.<br>
> ><br>
> > --<br>
> > ^C<br>
> ><br>
> ><br>
> > On 1/16/22 8:26 AM, Ovidiu Sas wrote:<br>
> > > Most of the time, if you get the right person on the carrier's side<br>
> > > and you explain the situation, they will come up with a solution.<br>
> > > If not, you need to break the RFC in a way that will counterpart their breakage.<br>
> > ><br>
> > > The carrier is also using a SIP proxy (maybe kamailio, who knows).<br>
> > > In the old days, the default kamailio config was using<br>
> > > fix_nated_contact() to deal with NATed devices and this is exactly the<br>
> > > behavior that you are seeing.<br>
> > > The recommended way to deal with NATed devices is to use<br>
> > > add_contact_alias([ip_addr, port, proto]) which is RFC compliant.<br>
> > ><br>
> > > There are several solution for this scenario:<br>
> > > - mangle the signaling to allow proper routing on your end<br>
> > > - use a B2BUA in between your kamailio and carrier<br>
> > > - configure kamailio to use one of the topology hiding modules:<br>
> > > topoh, topos, topos_redis<br>
> > > - maybe something else ... :)<br>
> > ><br>
> > > There's no right or wrong approach, one must be comfortable with the<br>
> > > chosen solution to be able to maintain it.<br>
> > ><br>
> > > -ovidiu<br>
> > ><br>
> > > On Sat, Jan 15, 2022 at 9:14 PM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >><br>
> > >> Ok so in short I was not doing anything wrong (although I had some miss-configurations), but the carrier is<br>
> > (i.e. they<br>
> > >> are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense they meant in<br>
> the "to work<br>
> > >> with us" sense. Now in order for me to get it to work with their SBC I have to mangle the contact on the<br>
> way out an<br>
> > >> unmangle it on the return in Kamailio somehow, as I originally purposed.<br>
> > >> However I have no idea how to do that :)<br>
> > >><br>
> > >> Shouldn't we (the Kamailio community) assume there are lots of bad actors out there and possibly many<br>
> Kamailio users<br>
> > >> with this exact same issue (I personally know of at least 2 bad actor carriers right now) and create some<br>
> kind of<br>
> > >> template or snippet that we can publicly publish on the Kamailio docs or wiki for all of the Kamailio<br>
> community<br>
> > to use<br>
> > >> for this use case?<br>
> > >><br>
> > >> I have been fighting with carriers about this for years and they always said I was doing it wrong and I don't<br>
> > know the<br>
> > >> SIP RFC well enough to fight back. So why not build a solution for everyone out there that has to deal with a<br>
> > bad actor?<br>
> > >><br>
> > >> --<br>
> > >> ^C<br>
> > >><br>
> > >><br>
> > >> On 1/15/22 11:40 AM, Ovidiu Sas wrote:<br>
> > >>> As expected, your carrier is bogus and "thinks" it knows better.<br>
> > >>> Your carrier is treating your setup as a dumb endpoint and is<br>
> > >>> re-writing the Contact header:<br>
> > >>> You provide this contact header in 200 OK:<br>
> > >>> Contact: <sip:928#######@10.###.###.104:5060><br>
> > >>> The carrier should set the RURI in ACK like this:<br>
> > >>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0<br>
> > >>> Instead, your ACK is sent to you like this:<br>
> > >>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0<br>
> > >>><br>
> > >>> The RURI in ACK should point to the private IP of the asterisk server,<br>
> > >>> not to the public IP of the kamailio server.<br>
> > >>> You need to ask the carrier to follow the SIP RFC and not treat your<br>
> > >>> endpoints like dumb SIP endpoints.<br>
> > >>><br>
> > >>> There's a high chance that they won't do it :)<br>
> > >>> Your best chance is to manually mangle the URI in Contact in the 200<br>
> > >>> OK in a way that when you receive the ACK with the mangled RURI, you<br>
> > >>> can restore the original URI and let kamailio do the proper routing to<br>
> > >>> the private IP of the asterisk serverr.<br>
> > >>> You should be able to achieve this by using one of the following functions:<br>
> > >>> <a href="https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact</a>><br>
> > <<a href="https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact</a>>><br>
> > >>> <a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact</a>><br>
> > <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact</a>>><br>
> > >>> <a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode</a>><br>
> > <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode</a><br>
> <<a href="https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode</a>>><br>
> > >>><br>
> > >>> Regards,<br>
> > >>> Ovidiu Sas<br>
> > >>><br>
> > >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >>>><br>
> > >>>> I changed the listen per your advice and here is the 200 and ACK.<br>
> > >>>> I get no audio and the the call disconnects and I see this is the Asterisk log:<br>
> > >>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached on transmission<br>
> > >>>> <a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a><br>
> <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a>><br>
> > <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a><br>
> <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a>>> for seqno 102 (Critical Response) -- See<br>
> > >>>> <a href="https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions</a><br>
> <<a href="https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions</a>><br>
> > <<a href="https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions</a><br>
> <<a href="https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions</a>>><br>
> > >>>> Packet timed out after 6401ms with no response<br>
> > >>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call<br>
> > <a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a> <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a>><br>
> <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a><br>
> <<a href="http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060" rel="noreferrer" target="_blank">http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060</a>>> - no<br>
> > >>>> reply to our critical packet (see <a href="https://wiki.asterisk.org/wik" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik</a> <<a href="https://wiki.asterisk.org/wik" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik</a>><br>
> <<a href="https://wiki.asterisk.org/wik" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik</a> <<a href="https://wiki.asterisk.org/wik" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik</a>>><br>
> > >>>><br>
> > >>>> FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 10.###.###.104 is the asterisk box.<br>
> > >>>><br>
> > >>>> SIP/2.0 200 OK<br>
> > >>>> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0<br>
> > >>>> Via: SIP/2.0/UDP<br>
> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1<br>
> > >>>> Record-Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0><br>
> > >>>> Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0><br>
> > >>>> Record-Route: <sip:64.###.###.###;lr;ftag=as04035ef0><br>
> > >>>> From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as04035ef0<br>
> > >>>> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05<br>
> > >>>> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060<br>
> > >>>> CSeq: 102 INVITE<br>
> > >>>> Server: Asterisk PBX 16.18.0<br>
> > >>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE<br>
> > >>>> Supported: replaces, timer<br>
> > >>>> Contact: <sip:928#######@10.###.###.104:5060><br>
> > >>>> Content-Type: application/sdp<br>
> > >>>> Content-Length: 274<br>
> > >>>><br>
> > >>>> v=0<br>
> > >>>> o=root 1911037741 1911037741 IN IP4 209.###.###.###<br>
> > >>>> s=Asterisk PBX 16.18.0<br>
> > >>>> c=IN IP4 209.###.###.###<br>
> > >>>> t=0 0<br>
> > >>>> m=audio 11384 RTP/AVP 0 101<br>
> > >>>> a=rtpmap:0 PCMU/8000<br>
> > >>>> a=rtpmap:101 telephone-event/8000<br>
> > >>>> a=fmtp:101 0-16<br>
> > >>>> a=ptime:20<br>
> > >>>> a=maxptime:150<br>
> > >>>> a=sendrecv<br>
> > >>>> a=nortpproxy:yes<br>
> > >>>><br>
> > >>>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0<br>
> > >>>> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2<br>
> > >>>> Via: SIP/2.0/UDP<br>
> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1<br>
> > >>>> Max-Forwards: 67<br>
> > >>>> From: "Anonymous" <sip:anonymous@anonymous.invalid:5060>;tag=as04035ef0<br>
> > >>>> To: <sip:928#######@64.###.###.###:5060>;tag=as7047ed05<br>
> > >>>> Contact: <sip:anonymous@206.###.###.###:5060;transport=udp><br>
> > >>>> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060<br>
> > >>>> CSeq: 102 ACK<br>
> > >>>> User-Agent: packetrino<br>
> > >>>> Content-Length: 0<br>
> > >>>> Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0><br>
> > >>>> Route: <sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0><br>
> > >>>><br>
> > >>>><br>
> > >>>> --<br>
> > >>>> ^C<br>
> > >>>><br>
> > >>>><br>
> > >>>> On 1/15/22 10:21 AM, Ovidiu Sas wrote:<br>
> > >>>>> This is false. The IP in the Contact header must be routable by the<br>
> > >>>>> SIP hop from the top Record-Route header in the reply.<br>
> > >>>>> The carrier (and it seems that they have a PROXY also) must be able to<br>
> > >>>>> route to their adjacent SIP hop, which is your public IP (the IP in<br>
> > >>>>> the second Record-Route header).<br>
> > >>>>> It seems that the carrier is not taking into account that they might<br>
> > >>>>> interface with other proxies.<br>
> > >>>>> Most likely, your carrier expects to interface with a simple SIP UA,<br>
> > >>>>> not with another proxy. This is a pretty common setup for most of the<br>
> > >>>>> carriers, although many new carrier implementations are taking care of<br>
> > >>>>> the proxy to proxy calls.<br>
> > >>>>><br>
> > >>>>> It would be helpful to see the ACK that is sent by the carrier in<br>
> > >>>>> response to your 200ok (after you fix your config and you have your<br>
> > >>>>> private IP listed in the Record-Route header).<br>
> > >>>>><br>
> > >>>>> -ovidiu<br>
> > >>>>><br>
> > >>>>> On Sat, Jan 15, 2022 at 12:33 PM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >>>>>><br>
> > >>>>>> Hmm, I don't think you are right that the Contact header can be a private IP even if the RR is correct.<br>
> > >>>>>> I did some research on it and I found several places saying it must be a routable IP which is what the<br>
> > carrier also said.<br>
> > >>>>>><br>
> > >>>>>> "The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests.<br>
> > That means that<br>
> > >>>>>> the host part of the URI must be globally reachable by anyone.<br>
> > >>>>>> If your contact contains a private IP (behind a NAT?) then it is wrong, because other peers cannot<br>
> reach you<br>
> > with that."<br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>> --<br>
> > >>>>>> ^C<br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>> On 1/15/22 9:05 AM, Ovidiu Sas wrote:<br>
> > >>>>>>> You have a different problem then.<br>
> > >>>>>>> Having private IPs in Contact is fine. You need to lose route the<br>
> > >>>>>>> calls (kamailio will add two Record-Route headers) and the origination<br>
> > >>>>>>> server will set the RURI to the private IP from Contact, but it will<br>
> > >>>>>>> send the in-dialog requests to the public IP of kamailio. This has<br>
> > >>>>>>> nothing to do with virtual IPs.<br>
> > >>>>>>> Maybe you have a buggy client that doesn't do proper loose routing.<br>
> > >>>>>>><br>
> > >>>>>>> -ovidiu<br>
> > >>>>>>><br>
> > >>>>>>> On Sat, Jan 15, 2022 at 11:50 AM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >>>>>>>><br>
> > >>>>>>>> Ovidiu,<br>
> > >>>>>>>> Thank you again for your response.<br>
> > >>>>>>>> One is public (an internet IP) and one is private (a 10.x ip).<br>
> > >>>>>>>> Apparently this is a known problem with virtual IPs, it does not work.<br>
> > >>>>>>>> When the asterisk server responds to the invite it sends a contact header with the private IP and<br>
> Kamailio<br>
> > does not<br>
> > >>>>>>>> rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact<br>
> > header and tries to<br>
> > >>>>>>>> send the traffic to the 10.x IP (which is non-routable) and the call dies.<br>
> > >>>>>>>> I have been trying things for a long time to fix this (years) what you are saying will not fix it<br>
> because<br>
> > of the virtual<br>
> > >>>>>>>> IPs.<br>
> > >>>>>>>> If it was a normal IP it would work fine. It has something to do with the routing table and how mhomed<br>
> > detects networks.<br>
> > >>>>>>>><br>
> > >>>>>>>> --<br>
> > >>>>>>>> ^C<br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>>>> On 1/15/22 8:36 AM, Ovidiu Sas wrote:<br>
> > >>>>>>>>> Hello Chad,<br>
> > >>>>>>>>><br>
> > >>>>>>>>> The floating IPs that you have, are they both private IPs or one<br>
> > >>>>>>>>> private IP and the other one a public IP?<br>
> > >>>>>>>>><br>
> > >>>>>>>>> If you have to two floating private IPs, then you need a config like this:<br>
> > >>>>>>>>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP<br>
> > >>>>>>>>> listen=FLOATING_UDP_PRIVATE2<br>
> > >>>>>>>>><br>
> > >>>>>>>>> In the config, before relaying the initial INVITE you need to detect<br>
> > >>>>>>>>> the direction of the call and set $fs accordingly:<br>
> > >>>>>>>>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {<br>
> > >>>>>>>>> $fs = udp:FLOATING_UDP_PRIVATE1<br>
> > >>>>>>>>> }<br>
> > >>>>>>>>> else {<br>
> > >>>>>>>>> $fs = udp:FLOATING_UDP_PRIVATE2<br>
> > >>>>>>>>> }<br>
> > >>>>>>>>><br>
> > >>>>>>>>> If you have a floating private IPs and a floating public IP, then you<br>
> > >>>>>>>>> need a config like this:<br>
> > >>>>>>>>> listen=FLOATING_UDP_PRIVATE<br>
> > >>>>>>>>> listen=FLOATING_UDP_PUBLIC<br>
> > >>>>>>>>><br>
> > >>>>>>>>> There should be no need to force the socket, but if you do, there's no<br>
> > >>>>>>>>> harm (actually it's better and faster).<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Hope this clarifies things and helps,<br>
> > >>>>>>>>> -ovidiu<br>
> > >>>>>>>>><br>
> > >>>>>>>>> On Sat, Jan 15, 2022 at 9:48 AM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> Ovidiu,<br>
> > >>>>>>>>>> Thank you for your response.<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> I have done that, in addition to the linux ip_nonlocal_bind I have also set the Kamailio<br>
> ip_free_bind=1<br>
> > and it does not<br>
> > >>>>>>>>>> work.<br>
> > >>>>>>>>>> Here are my relevant config lines:<br>
> > >>>>>>>>>> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060<br>
> > >>>>>>>>>> listen=LISTEN_UDP_PUBLIC<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> mhomed=1<br>
> > >>>>>>>>>> ip_free_bind=1<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been using it for a<br>
> long time<br>
> > and have<br>
> > >>>>>>>>>> rebooted as well):<br>
> > >>>>>>>>>> net.ipv4.ip_nonlocal_bind=1<br>
> > >>>>>>>>>> --<br>
> > >>>>>>>>>> ^C<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> On 1/15/22 4:55 AM, Ovidiu Sas wrote:<br>
> > >>>>>>>>>>> Hello Chad,<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> You can add a listen directive to your config for the virtual IPs<br>
> > >>>>>>>>>>> (both public and private) and then you don't need to manually modify<br>
> > >>>>>>>>>>> any headers or use force_send_socket().<br>
> > >>>>>>>>>>> You need to enable non local IP binding so kamailio can start on the<br>
> > >>>>>>>>>>> server that doesn't have the virtual IP:<br>
> > >>>>>>>>>>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind<br>
> > >>>>>>>>>>> To make the change permanent, edit your sysctl.conf file and enable it there:<br>
> > >>>>>>>>>>> net/ipv4/ip_nonlocal_bind = 1<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> Regards<br>
> > >>>>>>>>>>> Ovidiu Sas<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> On Sat, Jan 15, 2022 at 4:16 AM Chad <<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>><br>
> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a> <mailto:<a href="mailto:ccolumbu@hotmail.com" target="_blank">ccolumbu@hotmail.com</a>>>> wrote:<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup.<br>
> > >>>>>>>>>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our<br>
> > private IP asterisk<br>
> > >>>>>>>>>>>> servers (via dispatcher).<br>
> > >>>>>>>>>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs<br>
> created<br>
> > by keepalived.<br>
> > >>>>>>>>>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to<br>
> direct the<br>
> > traffic.<br>
> > >>>>>>>>>>>> We run linux Debian 10 for the OS.<br>
> > >>>>>>>>>>>> Also we do not use a DB at all, everything is done with local config files.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like:<br>
> > >>>>>>>>>>>> Contact: <sip:##########@<a href="http://10.10.10.#%23%23]:5060" rel="noreferrer" target="_blank">10.10.10.###]:5060</a> <<a href="http://10.10.10.#%23%23]:5060" rel="noreferrer" target="_blank">http://10.10.10.#%23%23]:5060</a>><br>
> <<a href="http://10.10.10.#%23%23]:5060" rel="noreferrer" target="_blank">http://10.10.10.#%23%23]:5060</a> <<a href="http://10.10.10.#%23%23]:5060" rel="noreferrer" target="_blank">http://10.10.10.#%23%23]:5060</a>>>><br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> There are 2 possible solutions to this:<br>
> > >>>>>>>>>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so<br>
> > that mhomed and<br>
> > >>>>>>>>>>>> fix_nated_contact work as usual.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> 2. Create a manual header rewrite system.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> If solution #2:<br>
> > >>>>>>>>>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out,<br>
> > and on the way back<br>
> > >>>>>>>>>>>> rewrite it back to the internal server that the call is already connected to.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with<br>
> > another persistant<br>
> > >>>>>>>>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name<br>
> field<br>
> > or something).<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> Thank you all for your time.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> --<br>
> > >>>>>>>>>>>> ^C<br>
> > >>>>>>>>>>>> Chad<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> __________________________________________________________<br>
> > >>>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions<br>
> > >>>>>>>>>>>> * <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>><br>
> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>>><br>
> > >>>>>>>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
> > >>>>>>>>>>>> Edit mailing list options or unsubscribe:<br>
> > >>>>>>>>>>>> * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>><br>
> > <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> --<br>
> > >>>>>>>>>>> VoIP Embedded, Inc.<br>
> > >>>>>>>>>>> <a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a>> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a><br>
> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> __________________________________________________________<br>
> > >>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions<br>
> > >>>>>>>>>>> * <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>><br>
> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a> <mailto:<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>>><br>
> > >>>>>>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
> > >>>>>>>>>>> Edit mailing list options or unsubscribe:<br>
> > >>>>>>>>>>> * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>><br>
> > <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>><br>
> > >>>>><br>
> > >>>>><br>
> > >>><br>
> > >>><br>
> > >>><br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> > --<br>
> > VoIP Embedded, Inc.<br>
> > <a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a>> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a>>><br>
> <br>
> -- <br>
> VoIP Embedded, Inc.<br>
> <a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a> <<a href="http://www.voipembedded.com" rel="noreferrer" target="_blank">http://www.voipembedded.com</a>><br>
<br>
__________________________________________________________<br>
Kamailio - Users Mailing List - Non Commercial Discussions<br>
* <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
Important: keep the mailing list in the recipients, do not reply only to the sender!<br>
Edit mailing list options or unsubscribe:<br>
* <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>