16 Jan
2022
16 Jan
'22
11:21 p.m.
If I use my external IP do I turn off enable_double_rr?
-- ^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 <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_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 <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 <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.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 <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>> 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 <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 <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 <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 <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>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 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