Take a look at freeSWITCH On Mon, 17 Jan 2022 at 00:58, Chad <ccolu...@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 <ccolu...@hotmail.com <mailto: > ccolu...@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_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 <ccolu...@hotmail.com <mailto: > ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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 <ccolu...@hotmail.com > <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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.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.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.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 < > ccolu...@hotmail.com <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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>> 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>> > > > >>>> 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>> - 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>> > > > >>>> > > > >>>> 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 < > ccolu...@hotmail.com <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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 < > ccolu...@hotmail.com <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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 < > ccolu...@hotmail.com <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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 < > ccolu...@hotmail.com <mailto:ccolu...@hotmail.com> > > <mailto:ccolu...@hotmail.com <mailto:ccolu...@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>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> 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@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>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> -- > > > >>>>>>>>>>> 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@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>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > -- > > > VoIP Embedded, Inc. > > > 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> > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * 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 > -- Regards, David Villasmil email: david.villasmil.w...@gmail.com phone: +34669448337
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * 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