We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this: 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and fix_nated_contact work as usual.
2. Create a manual header rewrite system.
If solution #2: What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back rewrite it back to the internal server that the call is already connected to.
Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something).
If anyone out there know of a way to do this or wants to give it a try please reach out to me.
Thank you all for your time.
-- ^C Chad
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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- VoIP Embedded, Inc. http://www.voipembedded.com
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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- VoIP Embedded, Inc. 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:
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 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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- VoIP Embedded, Inc. 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:
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 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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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 Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
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 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 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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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 Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
It would be great if you are right and I am simply doing something else wrong in the config file!
Here is the 200 OK (note I have enable_double_rr enabled): SIP/2.0 200 OK Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0 Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0 Record-Route: sip:209.###.###.###:5060;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:209.###.###.###;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:18.###.###.###;lr;ftag=gK0e16642e;did=6dc.283659a3 From: sip:+1202#######@66.###.###.###:5060;tag=gK0e16642e To: sip:+1845#######@sip-us-west-2a.numberaccess.net:5060;tag=as488a6fb4 Call-ID: 202251204_54250714@206.###.###.### CSeq: 710596 INVITE Server: Asterisk PBX 16.18.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:1845#######@10.###.###.###:5060 Content-Type: application/sdp Require: timer Content-Length: 272
v=0 o=root 153822920 153822920 IN IP4 209.###.###.### s=Asterisk PBX 16.18.0 c=IN IP4 209.###.###.### t=0 0 m=audio 17198 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv a=nortpproxy:yes
-- ^C
On 1/15/22 9:05 AM, Ovidiu Sas wrote:
You have a different problem then. Having private IPs in Contact is fine. You need to lose route the calls (kamailio will add two Record-Route headers) and the origination server will set the RURI to the private IP from Contact, but it will send the in-dialog requests to the public IP of kamailio. This has nothing to do with virtual IPs. Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad ccolumbu@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 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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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 Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
It doesn't look good because you have the public IP twice in the Record-Route header. You need to replace the listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 with listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 and all should be good.
If your carrier is telling you that the IP address in Contact should be public, then you need to find an RFC compliant carrier (or mangle the Contact to make them happy). Most of the time I fight with them until they have this fixed. Sometimes it's a lost battle and you just need to hack your config to make it work.
I have deployed kamailio using this setup and if you deal with RFC compliant end-point (carriers, softphones, hardphones) then all is good.
-ovidiu
On Sat, Jan 15, 2022 at 12:14 PM Chad ccolumbu@hotmail.com wrote:
It would be great if you are right and I am simply doing something else wrong in the config file!
Here is the 200 OK (note I have enable_double_rr enabled): SIP/2.0 200 OK Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0 Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0 Record-Route: sip:209.###.###.###:5060;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:209.###.###.###;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:18.###.###.###;lr;ftag=gK0e16642e;did=6dc.283659a3 From: sip:+1202#######@66.###.###.###:5060;tag=gK0e16642e To: sip:+1845#######@sip-us-west-2a.numberaccess.net:5060;tag=as488a6fb4 Call-ID: 202251204_54250714@206.###.###.### CSeq: 710596 INVITE Server: Asterisk PBX 16.18.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:1845#######@10.###.###.###:5060 Content-Type: application/sdp Require: timer Content-Length: 272
v=0 o=root 153822920 153822920 IN IP4 209.###.###.### s=Asterisk PBX 16.18.0 c=IN IP4 209.###.###.### t=0 0 m=audio 17198 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv a=nortpproxy:yes
-- ^C
On 1/15/22 9:05 AM, Ovidiu Sas wrote:
You have a different problem then. Having private IPs in Contact is fine. You need to lose route the calls (kamailio will add two Record-Route headers) and the origination server will set the RURI to the private IP from Contact, but it will send the in-dialog requests to the public IP of kamailio. This has nothing to do with virtual IPs. Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad ccolumbu@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 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 wrote: > > We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. > To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk > servers (via dispatcher). > However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. > Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. > We run linux Debian 10 for the OS. > Also we do not use a DB at all, everything is done with local config files. > > The problem is that when traffic goes out the Contact header has a private IP in it, like: > Contact: sip:##########@10.10.10.###]:5060 > > There are 2 possible solutions to this: > 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and > fix_nated_contact work as usual. > > 2. Create a manual header rewrite system. > > If solution #2: > What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back > rewrite it back to the internal server that the call is already connected to. > > Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant > header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). > > If anyone out there know of a way to do this or wants to give it a try please reach out to me. > > Thank you all for your time. > > -- > ^C > Chad > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
Oops ... copy/paste mistake: You need to replace: listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 with listen=LISTEN_UDP_PRIVATE
-ovidiu
On Sat, Jan 15, 2022 at 1:07 PM Ovidiu Sas osas@voipembedded.com wrote:
It doesn't look good because you have the public IP twice in the Record-Route header. You need to replace the listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 with listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 and all should be good.
If your carrier is telling you that the IP address in Contact should be public, then you need to find an RFC compliant carrier (or mangle the Contact to make them happy). Most of the time I fight with them until they have this fixed. Sometimes it's a lost battle and you just need to hack your config to make it work.
I have deployed kamailio using this setup and if you deal with RFC compliant end-point (carriers, softphones, hardphones) then all is good.
-ovidiu
On Sat, Jan 15, 2022 at 12:14 PM Chad ccolumbu@hotmail.com wrote:
It would be great if you are right and I am simply doing something else wrong in the config file!
Here is the 200 OK (note I have enable_double_rr enabled): SIP/2.0 200 OK Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0 Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0 Record-Route: sip:209.###.###.###:5060;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:209.###.###.###;r2=on;lr=on;ftag=gK0e16642e Record-Route: sip:18.###.###.###;lr;ftag=gK0e16642e;did=6dc.283659a3 From: sip:+1202#######@66.###.###.###:5060;tag=gK0e16642e To: sip:+1845#######@sip-us-west-2a.numberaccess.net:5060;tag=as488a6fb4 Call-ID: 202251204_54250714@206.###.###.### CSeq: 710596 INVITE Server: Asterisk PBX 16.18.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:1845#######@10.###.###.###:5060 Content-Type: application/sdp Require: timer Content-Length: 272
v=0 o=root 153822920 153822920 IN IP4 209.###.###.### s=Asterisk PBX 16.18.0 c=IN IP4 209.###.###.### t=0 0 m=audio 17198 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv a=nortpproxy:yes
-- ^C
On 1/15/22 9:05 AM, Ovidiu Sas wrote:
You have a different problem then. Having private IPs in Contact is fine. You need to lose route the calls (kamailio will add two Record-Route headers) and the origination server will set the RURI to the private IP from Contact, but it will send the in-dialog requests to the public IP of kamailio. This has nothing to do with virtual IPs. Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad ccolumbu@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 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 wrote: >> >> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >> servers (via dispatcher). >> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >> We run linux Debian 10 for the OS. >> Also we do not use a DB at all, everything is done with local config files. >> >> The problem is that when traffic goes out the Contact header has a private IP in it, like: >> Contact: sip:##########@10.10.10.###]:5060 >> >> There are 2 possible solutions to this: >> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >> fix_nated_contact work as usual. >> >> 2. Create a manual header rewrite system. >> >> If solution #2: >> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >> rewrite it back to the internal server that the call is already connected to. >> >> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >> >> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >> >> Thank you all for your time. >> >> -- >> ^C >> Chad >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
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 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 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 wrote:
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: sip:##########@10.10.10.###]:5060
There are 2 possible solutions to this:
- 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.
- 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 Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
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 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 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 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 wrote: > > We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. > To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk > servers (via dispatcher). > However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. > Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. > We run linux Debian 10 for the OS. > Also we do not use a DB at all, everything is done with local config files. > > The problem is that when traffic goes out the Contact header has a private IP in it, like: > Contact: sip:##########@10.10.10.###]:5060 > > There are 2 possible solutions to this: > 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and > fix_nated_contact work as usual. > > 2. Create a manual header rewrite system. > > If solution #2: > What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back > rewrite it back to the internal server that the call is already connected to. > > Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant > header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). > > If anyone out there know of a way to do this or wants to give it a try please reach out to me. > > Thank you all for your time. > > -- > ^C > Chad > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- VoIP Embedded, Inc. http://www.voipembedded.com
Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >> >> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >> servers (via dispatcher). >> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >> We run linux Debian 10 for the OS. >> Also we do not use a DB at all, everything is done with local config files. >> >> The problem is that when traffic goes out the Contact header has a private IP in it, like: >> Contact: sip:##########@10.10.10.###]:5060 >> >> There are 2 possible solutions to this: >> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >> fix_nated_contact work as usual. >> >> 2. Create a manual header rewrite system. >> >> If solution #2: >> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >> rewrite it back to the internal server that the call is already connected to. >> >> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >> >> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >> >> Thank you all for your time. >> >> -- >> ^C >> Chad >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@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
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.encod... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>> >>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>> servers (via dispatcher). >>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>> We run linux Debian 10 for the OS. >>> Also we do not use a DB at all, everything is done with local config files. >>> >>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>> Contact: sip:##########@10.10.10.###]:5060 >>> >>> There are 2 possible solutions to this: >>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>> fix_nated_contact work as usual. >>> >>> 2. Create a manual header rewrite system. >>> >>> If solution #2: >>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>> rewrite it back to the internal server that the call is already connected to. >>> >>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>> >>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>> >>> Thank you all for your time. >>> >>> -- >>> ^C >>> Chad >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> * sr-users@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>> Edit mailing list options or unsubscribe: >>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> -- >> VoIP Embedded, Inc. >> http://www.voipembedded.com >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@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
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.encod... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>>> >>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>>> servers (via dispatcher). >>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>>> We run linux Debian 10 for the OS. >>>> Also we do not use a DB at all, everything is done with local config files. >>>> >>>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>>> Contact: sip:##########@10.10.10.###]:5060 >>>> >>>> There are 2 possible solutions to this: >>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>>> fix_nated_contact work as usual. >>>> >>>> 2. Create a manual header rewrite system. >>>> >>>> If solution #2: >>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>>> rewrite it back to the internal server that the call is already connected to. >>>> >>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>>> >>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>>> >>>> Thank you all for your time. >>>> >>>> -- >>>> ^C >>>> Chad >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> * sr-users@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>> Edit mailing list options or unsubscribe: >>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> -- >>> VoIP Embedded, Inc. >>> http://www.voipembedded.com >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> * sr-users@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 > > >
Hi There,
If I look at the latest SIP trace you shared:
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
The ACK is getting sent to the Kamailio with correct Route information:
Route: sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0 Route: sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0
The Kamailio server should strip the 1st and 2nd Route(s) header from the ACK and should relay it towards the next-hop as per the request URI. Please note that Kamailio is sending Double RR headers ( When a Proxy receives a request on one network interface and sends it onwards using a different interface e.g. WAN to LAN, this will normally require the addition of an extra Record-Route header. i.e. the Proxy must add two RR headers where you might normally expect it to add one.)
Record-Route: sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0 Record-Route: sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0
The problem is, the peer behavior is not compliant with the specs. It is sending the ACK with RURI set to:
ACK sip:928#######@209.###.###.###:5060 SIP/2.0
Ideally, it should have sent the ACK with the following Request-URI:
ACK sip:928#######@10.###.###.104:5060 SIP/2.0
Once this ACK will be received on Kamailio, it will relay it towards the Asterisk IP, which is 10.###.###.104.
For further understanding of the ACK routing, you can refer to the following post:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2019-February/03122...
The peer is not copying the 200 OK Contact header URI into the ACK message and it is a problem.
Lastly, the trace might be showing only part of the puzzle, it is also suggested to get a capture on the remote peer end, because it is sending the 209.###.###.### IP in the ACK, which seems to be the public interface of the Kamailio server. I am not sure if there is some device in the path, that is changing the contact IP in the 200 OK to the Kamailio public IP?
Ovidiu also explained the same point, I just added a little bit more information for you to fight with your SIP provider. It is better to ask what RFC they are following on the basis of which they are writing the Kamailio public IP in the 200 OK ACK message?
Regards, Shah Hussain
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Chad ccolumbu@hotmail.com Sent: Sunday, January 16, 2022 10:14 AM To: Ovidiu Sas osas@voipembedded.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Help with rewriting headers for NAT manually
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.encod... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>>> >>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>>> servers (via dispatcher). >>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>>> We run linux Debian 10 for the OS. >>>> Also we do not use a DB at all, everything is done with local config files. >>>> >>>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>>> Contact: sip:##########@10.10.10.###]:5060 >>>> >>>> There are 2 possible solutions to this: >>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>>> fix_nated_contact work as usual. >>>> >>>> 2. Create a manual header rewrite system. >>>> >>>> If solution #2: >>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>>> rewrite it back to the internal server that the call is already connected to. >>>> >>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>>> >>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>>> >>>> Thank you all for your time. >>>> >>>> -- >>>> ^C >>>> Chad >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> * sr-users@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>> Edit mailing list options or unsubscribe: >>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> -- >>> VoIP Embedded, Inc. >>> http://www.voipembedded.com >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> * sr-users@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 > > >
__________________________________________________________ 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
Shah, Thank you for your time and effort. Of course you and Ovidiu are right in that the carrier should be RFC compliant, but getting away from the technical and looking at it more from a practical point of view: 1. Fighting the carrier is problematic, they think they are right.
2. Even if they agree right now it will take time for them to make the change, test it, and release it (could be weeks or months), because they don't want to break their production system for other clients.
3. There are other bad actors out there including upstream providers (i.e. a reinvite) and other carriers we all use. Which means fighting the fight over and over with every carrier you deal with even some that you are not a direct client of (in the case of upstream)
So if we (the Kamailio/OpenSIPs community) have a solution that we can implement on our end that solves these problems in all cases and does not hurt any RFC compliant carriers (except for a small resource hit) we overcome all the above problems from our side.
I look at is as: if we rewrite (mangle) the Contact header to the external routable IP in all cases and reverse the Contact rewrite (unmangle) the return traffic the proxy becomes invisible to the carriers and we have 1 less thing to worry about breaking. BTW this idea comes from linux firewalls/load balancers, they have a similar solution for iptables/nftables/LVS and forwarding http traffic to a private cluster. It makes the server stack's internals invisible to the end user's browser. All they see is the single external IP and all traffic is 1-to-1 from the end user's perspective.
I am happy to pitch in some financial incentive to getting a solution to my immediate problem, but I want the solution to be open source for the whole community.
Thanks again!
-- ^C Chad
On 1/16/22 1:00 AM, Shah Hussain Khattak wrote:
Hi There,
If I look at the latest SIP trace you shared:
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
The ACK is getting sent to the Kamailio with correct Route information:
Route: sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0 Route: sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0
The Kamailio server should strip the 1^st and 2^nd Route(s) header from the ACK and should relay it towards the next-hop as per the request URI. Please note that Kamailio is sending Double RR headers ( When a Proxy receives a request on one network interface and sends it onwards using a different interface e.g. WAN to LAN, this will normally require the addition of an extra Record-Route header. i.e. the Proxy must add two RR headers where you might normally expect it to add one.)
Record-Route: sip:10.###.###.254;r2=on;lr=on;ftag=as04035ef0 Record-Route: sip:209.###.###.###;r2=on;lr=on;ftag=as04035ef0
The problem is, the peer behavior is not compliant with the specs. It is sending the ACK with RURI set to:
ACK sip:928#######@209.###.###.###:5060SIP/2.0
Ideally, it should have sent the ACK with the following Request-URI:
ACK sip:928#######@10.###.###.104:5060SIP/2.0
Once this ACK will be received on Kamailio, it will relay it towards the Asterisk IP, which is 10.###.###.104.
For further understanding of the ACK routing, you can refer to the following post:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2019-February/03122... https://lists.cs.columbia.edu/pipermail/sip-implementors/2019-February/031229.html
The peer is not copying the 200 OK Contact header URI into the ACK message and it is a problem.
Lastly, the trace might be showing only part of the puzzle, it is also suggested to get a capture on the remote peer end, because it is sending the 209.###.###.### IP in the ACK, which seems to be the public interface of the Kamailio server. I am not sure if there is some device in the path, that is changing the contact IP in the 200 OK to the Kamailio public IP?
Ovidiu also explained the same point, I just added a little bit more information for you to fight with your SIP provider. It is better to ask what RFC they are following on the basis of which they are writing the Kamailio public IP in the 200 OK ACK message?
Regards, Shah Hussain
*From:* sr-users sr-users-bounces@lists.kamailio.org on behalf of Chad ccolumbu@hotmail.com *Sent:* Sunday, January 16, 2022 10:14 AM *To:* Ovidiu Sas osas@voipembedded.com *Cc:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] Help with rewriting headers for NAT manually 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.encod...
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.enc...
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.con...
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 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>>>> >>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>>>> servers (via dispatcher). >>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>>>> We run linux Debian 10 for the OS. >>>>> Also we do not use a DB at all, everything is done with local config files. >>>>> >>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>>>> Contact: sip:##########@10.10.10.###]:5060 >>>>> >>>>> There are 2 possible solutions to this: >>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>>>> fix_nated_contact work as usual. >>>>> >>>>> 2. Create a manual header rewrite system. >>>>> >>>>> If solution #2: >>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>>>> rewrite it back to the internal server that the call is already connected to. >>>>> >>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>>>> >>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>>>> >>>>> Thank you all for your time. >>>>> >>>>> -- >>>>> ^C >>>>> Chad >>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> * sr-users@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 >>>> >>>> >>>> >>>> -- >>>> 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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >>
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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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:
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 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.encod... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>>>> >>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>>>> servers (via dispatcher). >>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>>>> We run linux Debian 10 for the OS. >>>>> Also we do not use a DB at all, everything is done with local config files. >>>>> >>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>>>> Contact: sip:##########@10.10.10.###]:5060 >>>>> >>>>> There are 2 possible solutions to this: >>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>>>> fix_nated_contact work as usual. >>>>> >>>>> 2. Create a manual header rewrite system. >>>>> >>>>> If solution #2: >>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>>>> rewrite it back to the internal server that the call is already connected to. >>>>> >>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>>>> >>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>>>> >>>>> Thank you all for your time. >>>>> >>>>> -- >>>>> ^C >>>>> Chad >>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> * sr-users@lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> >>>> >>>> -- >>>> VoIP Embedded, Inc. >>>> http://www.voipembedded.com >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> * sr-users@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 >> >> >>
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 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.encod... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc... https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102 (Critical Response) -- See 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 - no reply to our critical packet (see 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 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 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 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 wrote: >>>>>> >>>>>> We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. >>>>>> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk >>>>>> servers (via dispatcher). >>>>>> However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. >>>>>> Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. >>>>>> We run linux Debian 10 for the OS. >>>>>> Also we do not use a DB at all, everything is done with local config files. >>>>>> >>>>>> The problem is that when traffic goes out the Contact header has a private IP in it, like: >>>>>> Contact: sip:##########@10.10.10.###]:5060 >>>>>> >>>>>> There are 2 possible solutions to this: >>>>>> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and >>>>>> fix_nated_contact work as usual. >>>>>> >>>>>> 2. Create a manual header rewrite system. >>>>>> >>>>>> If solution #2: >>>>>> What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back >>>>>> rewrite it back to the internal server that the call is already connected to. >>>>>> >>>>>> Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant >>>>>> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). >>>>>> >>>>>> If anyone out there know of a way to do this or wants to give it a try please reach out to me. >>>>>> >>>>>> Thank you all for your time. >>>>>> >>>>>> -- >>>>>> ^C >>>>>> Chad >>>>>> >>>>>> __________________________________________________________ >>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>> * sr-users@lists.kamailio.org >>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>>> Edit mailing list options or unsubscribe: >>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>>> >>>>> >>>>> -- >>>>> VoIP Embedded, Inc. >>>>> http://www.voipembedded.com >>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> * sr-users@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 >>> >>> >>> > > >
Have you tried using the mask_ip param: https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_...
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad 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 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.encod...
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
Regards, Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad 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 for seqno 102
(Critical Response) -- See
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 - no
reply to our critical packet (see 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 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
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
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
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>
>>>>>>> >>>>>>> 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 >>>>>>> Important: keep the mailing list in the recipients, do not
reply only to the sender!
>>>>>>> Edit mailing list options or unsubscribe: >>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> VoIP Embedded, Inc. >>>>>> http://www.voipembedded.com >>>>>> >>>>>> __________________________________________________________ >>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>> * sr-users@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
>>>> >>>> >>>> >> >> >>
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
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <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>> 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/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> >>> >>> Regards, >>> Ovidiu Sas >>> >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <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> for seqno 102 (Critical Response) -- See >>>> 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> - no >>>> reply to our critical packet (see 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>> 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>> 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>> 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>> 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>> >>>>>>>>>>>> >>>>>>>>>>>> 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> >>>>>>>>>>>> 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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> VoIP Embedded, Inc. >>>>>>>>>>> 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> >>>>>>>>>>> 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> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >-- VoIP Embedded, Inc. http://www.voipembedded.com http://www.voipembedded.com
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad 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_...
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <ccolumbu@hotmail.com <mailto:
ccolumbu@hotmail.com>> wrote:
I found a sample config file using topoh, which I copied (with somechanges) 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 moduledoes 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 callis still broken in the exact same way.
It was super easy to add, but does not work, 1 possible solutiondown.
-- ^C On 1/16/22 8:26 AM, Ovidiu Sas wrote: > Most of the time, if you get the right person on the carrier'sside
> 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 counterparttheir 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 isexactly 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 withthe
> chosen solution to be able to maintain it. > > -ovidiu > > On Sat, Jan 15, 2022 at 9:14 PM Chad <ccolumbu@hotmail.commailto:ccolumbu@hotmail.com> wrote:
>> >> Ok so in short I was not doing anything wrong (although I hadsome miss-configurations), but the carrier is
(i.e. they >> are a bad actor). When they said I was doing it wrong, they didnot 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 theirSBC I have to mangle the contact on the way out an
>> unmangle it on the return in Kamailio somehow, as I originallypurposed.
>> However I have no idea how to do that :) >> >> Shouldn't we (the Kamailio community) assume there are lots ofbad actors out there and possibly many Kamailio users
>> with this exact same issue (I personally know of at least 2 badactor carriers right now) and create some kind of
>> template or snippet that we can publicly publish on the Kamailiodocs 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 theyalways said I was doing it wrong and I don't
know the >> SIP RFC well enough to fight back. So why not build a solutionfor 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 asteriskserver,
>>> not to the public IP of the kamailio server. >>> You need to ask the carrier to follow the SIP RFC and not treatyour
>>> 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 inthe 200
>>> OK in a way that when you receive the ACK with the mangledRURI, you
>>> can restore the original URI and let kamailio do the properrouting to
>>> the private IP of the asterisk serverr. >>> You should be able to achieve this by using one of thefollowing functions:
>>>https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
>>>https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
>>>https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
>>> >>> Regards, >>> Ovidiu Sas >>> >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu@hotmail.commailto:ccolumbu@hotmail.com> wrote:
>>>> >>>> I changed the listen per your advice and here is the 200 andACK.
>>>> I get no audio and the the call disconnects and I see this isthe Asterisk log:
>>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmissiontimeout reached on transmission
>>>> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060> forseqno 102 (Critical Response) -- See
>>>> 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%3E - no
>>>> reply to our critical packet (seehttps://wiki.asterisk.org/wik https://wiki.asterisk.org/wik
>>>> >>>> FYI 10.###.###.254 is the private virtual IP on the Kamailioserver and 10.###.###.104 is the asterisk box.
>>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/UDP64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0
>>>> Via: SIP/2.0/UDP206.###.###.###: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/UDP64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2
>>>> Via: SIP/2.0/UDP206.###.###.###: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 routableby the
>>>>> SIP hop from the top Record-Route header in the reply. >>>>> The carrier (and it seems that they have a PROXY also) mustbe able to
>>>>> route to their adjacent SIP hop, which is your public IP (theIP in
>>>>> the second Record-Route header). >>>>> It seems that the carrier is not taking into account thatthey might
>>>>> interface with other proxies. >>>>> Most likely, your carrier expects to interface with a simpleSIP UA,
>>>>> not with another proxy. This is a pretty common setup formost of the
>>>>> carriers, although many new carrier implementations aretaking care of
>>>>> the proxy to proxy calls. >>>>> >>>>> It would be helpful to see the ACK that is sent by thecarrier in
>>>>> response to your 200ok (after you fix your config and youhave your
>>>>> private IP listed in the Record-Route header). >>>>> >>>>> -ovidiu >>>>> >>>>> On Sat, Jan 15, 2022 at 12:33 PM Chad <ccolumbu@hotmail.commailto:ccolumbu@hotmail.com> wrote:
>>>>>> >>>>>> Hmm, I don't think you are right that the Contact header canbe a private IP even if the RR is correct.
>>>>>> I did some research on it and I found several places sayingit must be a routable IP which is what the
carrier also said. >>>>>> >>>>>> "The Contact header contains the SIP URI where the clientwants to be contacted for subsequent requests.
That means that >>>>>> the host part of the URI must be globally reachable byanyone.
>>>>>> If your contact contains a private IP (behind a NAT?) thenit 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 loseroute the
>>>>>>> calls (kamailio will add two Record-Route headers) and theorigination
>>>>>>> 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 looserouting.
>>>>>>> >>>>>>> -ovidiu >>>>>>> >>>>>>> On Sat, Jan 15, 2022 at 11:50 AM Chad <ccolumbu@hotmail.commailto:ccolumbu@hotmail.com> wrote:
>>>>>>>> >>>>>>>> Ovidiu, >>>>>>>> Thank you again for your response. >>>>>>>> One is public (an internet IP) and one is private (a 10.xip).
>>>>>>>> Apparently this is a known problem with virtual IPs, itdoes not work.
>>>>>>>> When the asterisk server responds to the invite it sends acontact header with the private IP and Kamailio
does not >>>>>>>> rewrite it to the advertised public IP. So the originatingserver 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 somethingto 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 IPsor one
>>>>>>>>> private IP and the other one a public IP? >>>>>>>>> >>>>>>>>> If you have to two floating private IPs, then you need aconfig like this:
>>>>>>>>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP >>>>>>>>> listen=FLOATING_UDP_PRIVATE2 >>>>>>>>> >>>>>>>>> In the config, before relaying the initial INVITE youneed 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 publicIP, 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 youdo, 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> wrote:
>>>>>>>>>> >>>>>>>>>> Ovidiu, >>>>>>>>>> Thank you for your response. >>>>>>>>>> >>>>>>>>>> I have done that, in addition to the linuxip_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 withsysctl -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 thevirtual IPs
>>>>>>>>>>> (both public and private) and then you don't need tomanually modify
>>>>>>>>>>> any headers or use force_send_socket(). >>>>>>>>>>> You need to enable non local IP binding so kamailio canstart 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.conffile 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> wrote:
>>>>>>>>>>>> >>>>>>>>>>>> We are looking for some help (possibly a paidconsultant) to help us with our Kamailio setup.
>>>>>>>>>>>> To keep this as short as possible: we use Kamailio asa NAT proxy to bridge our external IP and our
private IP asterisk >>>>>>>>>>>> servers (via dispatcher). >>>>>>>>>>>> However both the external IP and the internal IP thatthe Kamailio server uses are virtual IPs created
by keepalived. >>>>>>>>>>>> Because of that neither mhomed nor fix_nated_contactwork, 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 donewith local config files.
>>>>>>>>>>>> >>>>>>>>>>>> The problem is that when traffic goes out the Contactheader has a private IP in it, like:
>>>>>>>>>>>> Contact: <sip:##########@10.10.10.###]:5060http://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 Kamailioso 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 thecontact header to the external IP on the way out,
and on the way back >>>>>>>>>>>> rewrite it back to the internal server that the callis already connected to.
>>>>>>>>>>>> >>>>>>>>>>>> Not sure if we will need to store those paths on theserver or if we can do some kind of cheat with
another persistant >>>>>>>>>>>> header like P-Preferred-Identity orP-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 wantsto give it a try please reach out to me.
>>>>>>>>>>>> >>>>>>>>>>>> Thank you all for your time. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ^C >>>>>>>>>>>> Chad >>>>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>>>>> Kamailio - Users Mailing List - Non CommercialDiscussions
>>>>>>>>>>>> * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>>> Important: keep the mailing list in the recipients, donot 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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> VoIP Embedded, Inc. >>>>>>>>>>> http://www.voipembedded.com <http://www.voipembedded.com%3E
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>> Kamailio - Users Mailing List - Non CommercialDiscussions
>>>>>>>>>>> * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>> Important: keep the mailing list in the recipients, donot 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> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >-- VoIP Embedded, Inc. http://www.voipembedded.com http://www.voipembedded.com
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
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 <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
Take a look at freeSWITCH
On Mon, 17 Jan 2022 at 00:58, Chad 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 <ccolumbu@hotmail.com <mailto:
ccolumbu@hotmail.com>> wrote:
Yes I am using a 172.16.x.x IP and it works, it rewrites theheaders, 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 ACKthrows 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_...
> <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_...
> > -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 topohmodule 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 thecall is still broken in the exact same way.
> It was super easy to add, but does not work, 1 possiblesolution down.
> > -- > ^C > > > On 1/16/22 8:26 AM, Ovidiu Sas wrote: > > Most of the time, if you get the right person on thecarrier's side
> > and you explain the situation, they will come up with asolution.
> > If not, you need to break the RFC in a way that willcounterpart their breakage.
> > > > The carrier is also using a SIP proxy (maybe kamailio, whoknows).
> > In the old days, the default kamailio config was using > > fix_nated_contact() to deal with NATed devices and this isexactly 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 RFCcompliant.
> > > > There are several solution for this scenario: > > - mangle the signaling to allow proper routing on yourend
> > - use a B2BUA in between your kamailio and carrier > > - configure kamailio to use one of the topology hidingmodules:
> > topoh, topos, topos_redis > > - maybe something else ... :) > > > > There's no right or wrong approach, one must becomfortable 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>>> wrote: > >> > >> Ok so in short I was not doing anything wrong (although Ihad 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 workwith their SBC I have to mangle the contact on the
way out an > >> unmangle it on the return in Kamailio somehow, as Ioriginally purposed.
> >> However I have no idea how to do that :) > >> > >> Shouldn't we (the Kamailio community) assume there arelots of bad actors out there and possibly many
Kamailio users > >> with this exact same issue (I personally know of at least2 bad actor carriers right now) and create some
kind of > >> template or snippet that we can publicly publish on theKamailio docs or wiki for all of the Kamailio
community > to use > >> for this use case? > >> > >> I have been fighting with carriers about this for yearsand 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 asolution 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 knowsbetter.
> >>> Your carrier is treating your setup as a dumb endpointand 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 theasterisk server,
> >>> not to the public IP of the kamailio server. > >>> You need to ask the carrier to follow the SIP RFC andnot 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 inContact in the 200
> >>> OK in a way that when you receive the ACK with themangled RURI, you
> >>> can restore the original URI and let kamailio do theproper routing to
> >>> the private IP of the asterisk serverr. > >>> You should be able to achieve this by using one of thefollowing functions:
> >>>https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
> <https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encod...
> >>>https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
> <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.enc...
> >>>https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
> <https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.con...
> >>> > >>> 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 the200 and ACK.
> >>>> I get no audio and the the call disconnects and I seethis 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>> forseqno 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 upcall
> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060%3E
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 <http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>> - no > >>>> reply to our critical packet (seehttps://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 theKamailio server and 10.###.###.104 is the asterisk box.
> >>>> > >>>> SIP/2.0 200 OK > >>>> Via: SIP/2.0/UDP64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0
> >>>> Via: SIP/2.0/UDP206.###.###.###: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/UDP64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2
> >>>> Via: SIP/2.0/UDP206.###.###.###: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 beroutable 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 publicIP (the IP in
> >>>>> the second Record-Route header). > >>>>> It seems that the carrier is not taking into accountthat they might
> >>>>> interface with other proxies. > >>>>> Most likely, your carrier expects to interface with asimple SIP UA,
> >>>>> not with another proxy. This is a pretty common setupfor most of the
> >>>>> carriers, although many new carrier implementationsare taking care of
> >>>>> the proxy to proxy calls. > >>>>> > >>>>> It would be helpful to see the ACK that is sent by thecarrier in
> >>>>> response to your 200ok (after you fix your config andyou 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 Contactheader can be a private IP even if the RR is correct.
> >>>>>> I did some research on it and I found several placessaying it must be a routable IP which is what the
> carrier also said. > >>>>>> > >>>>>> "The Contact header contains the SIP URI where theclient wants to be contacted for subsequent requests.
> That means that > >>>>>> the host part of the URI must be globally reachableby 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 tolose route the
> >>>>>>> calls (kamailio will add two Record-Route headers)and the origination
> >>>>>>> server will set the RURI to the private IP fromContact, but it will
> >>>>>>> send the in-dialog requests to the public IP ofkamailio. This has
> >>>>>>> nothing to do with virtual IPs. > >>>>>>> Maybe you have a buggy client that doesn't do properloose 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 virtualIPs, it does not work.
> >>>>>>>> When the asterisk server responds to the invite itsends a contact header with the private IP and
Kamailio > does not > >>>>>>>> rewrite it to the advertised public IP. So theoriginating server sees the private IP in the Contact
> header and tries to > >>>>>>>> send the traffic to the 10.x IP (which isnon-routable) and the call dies.
> >>>>>>>> I have been trying things for a long time to fixthis (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 hassomething 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 bothprivate IPs or one
> >>>>>>>>> private IP and the other one a public IP? > >>>>>>>>> > >>>>>>>>> If you have to two floating private IPs, then youneed a config like this:
> >>>>>>>>> listen=FLOATING_UDP_PRIVATE1 advertisePUBLIC_UDP_IP
> >>>>>>>>> listen=FLOATING_UDP_PRIVATE2 > >>>>>>>>> > >>>>>>>>> In the config, before relaying the initial INVITEyou 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 floatingpublic 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, butif 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 linuxip_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 advertiseMY_PUBLIC_IP:5060
> >>>>>>>>>> listen=LISTEN_UDP_PUBLIC > >>>>>>>>>> > >>>>>>>>>> mhomed=1 > >>>>>>>>>> ip_free_bind=1 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> In my /etc/sysctl.conf I have (yes I applied itwith 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 configfor the virtual IPs
> >>>>>>>>>>> (both public and private) and then you don'tneed to manually modify
> >>>>>>>>>>> any headers or use force_send_socket(). > >>>>>>>>>>> You need to enable non local IP binding sokamailio 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 yoursysctl.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 paidconsultant) to help us with our Kamailio setup.
> >>>>>>>>>>>> To keep this as short as possible: we useKamailio as a NAT proxy to bridge our external IP and our
> private IP asterisk > >>>>>>>>>>>> servers (via dispatcher). > >>>>>>>>>>>> However both the external IP and the internalIP that the Kamailio server uses are virtual IPs
created > by keepalived. > >>>>>>>>>>>> Because of that neither mhomed norfix_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 isdone with local config files.
> >>>>>>>>>>>> > >>>>>>>>>>>> The problem is that when traffic goes out theContact header has a private IP in it, like:
> >>>>>>>>>>>> Contact: <sip:##########@10.10.10.###]:5060http://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/orKamailio 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 rewritethe contact header to the external IP on the way out,
> and on the way back > >>>>>>>>>>>> rewrite it back to the internal server that thecall is already connected to.
> >>>>>>>>>>>> > >>>>>>>>>>>> Not sure if we will need to store those pathson the server or if we can do some kind of cheat with
> another persistant > >>>>>>>>>>>> header like P-Preferred-Identity orP-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 orwants to give it a try please reach out to me.
> >>>>>>>>>>>> > >>>>>>>>>>>> Thank you all for your time. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> ^C > >>>>>>>>>>>> Chad > >>>>>>>>>>>> > >>>>>>>>>>>>
> >>>>>>>>>>>> Kamailio - Users Mailing List - Non CommercialDiscussions
> >>>>>>>>>>>> * 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 therecipients, 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%3E <http://www.voipembedded.com
<http://www.voipembedded.com>> > >>>>>>>>>>> > >>>>>>>>>>>
> >>>>>>>>>>> Kamailio - Users Mailing List - Non CommercialDiscussions
> >>>>>>>>>>> * 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 therecipients, 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:
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 <ccolumbu@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 <ccolumbu@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_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 <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>> > <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 <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 <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/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.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>> > > <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>> > <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 <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 <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>> > <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 <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 <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>> > <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@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@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@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@gmail.com mailto:david.villasmil.work@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:
I have been reading a lot more about the problem and it seems my mangle/unmangle solution is basically B2BUA. So I need a B2BUA solution and it seems like Kamailio does not really do B2BUA. Instead of installing something else I don't know (SEMS or Sippy), it makes more sense to find something that can handle it all. I have read that opensips has B2BUA functionality built in, so I am seriously considering simply replacing Kamailio with opensips. In reality my system has such a low load I can probably replace Kamailio with Asterisk as a B2BUA and it would be fine, but from what I have read Asterisk is very inefficient for B2BUA.
-- ^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
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <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>> 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/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> >>> >>> Regards, >>> Ovidiu Sas >>> >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <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> for seqno 102 (Critical Response) -- See >>>> 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> - no >>>> reply to our critical packet (see 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>> 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>> 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>> 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>> 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>> >>>>>>>>>>>> >>>>>>>>>>>> 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> >>>>>>>>>>>> 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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> VoIP Embedded, Inc. >>>>>>>>>>> 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> >>>>>>>>>>> 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> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >-- VoIP Embedded, Inc. http://www.voipembedded.com http://www.voipembedded.com
Chad,
In my experience, if you carrier partner is one of the bigger carriers, and\or you use multiple carriers, Kamailio is the best solution available. With some of the smaller carriers\resellers it just makes more sense to use Asterisk rather than argue with them about how they are ignoring and breaking RFCs. While Asterisk can be inefficient, it generally "just works" in those situations. Based on what I have read of your situation in the list I think I can guess which company you are working with. Their "SBC" is Freeswitch-based. I have had a similar debate with them about RFCs, and yes, you are better off with Asterisk in that case.
Michael
On 1/16/2022 5:20 PM, Chad wrote:
I have been reading a lot more about the problem and it seems my mangle/unmangle solution is basically B2BUA. So I need a B2BUA solution and it seems like Kamailio does not really do B2BUA. Instead of installing something else I don't know (SEMS or Sippy), it makes more sense to find something that can handle it all. I have read that opensips has B2BUA functionality built in, so I am seriously considering simply replacing Kamailio with opensips. In reality my system has such a low load I can probably replace Kamailio with Asterisk as a B2BUA and it would be fine, but from what I have read Asterisk is very inefficient for B2BUA.
-- ^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
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <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> 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.encod... 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.enc... 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.con... 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> 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 for seqno 102 (Critical Response) -- See >>>> 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 - no >>>> reply to our critical packet (see 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> 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> 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> 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> 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> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> VoIP Embedded, Inc. >>>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
-- 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
Michael, Thank you for the feedback.
-- ^C
On 1/16/22 4:02 PM, Michael Young wrote:
Chad,
In my experience, if you carrier partner is one of the bigger carriers, and\or you use multiple carriers, Kamailio is the best solution available. With some of the smaller carriers\resellers it just makes more sense to use Asterisk rather than argue with them about how they are ignoring and breaking RFCs. While Asterisk can be inefficient, it generally "just works" in those situations. Based on what I have read of your situation in the list I think I can guess which company you are working with. Their "SBC" is Freeswitch-based. I have had a similar debate with them about RFCs, and yes, you are better off with Asterisk in that case.
Michael
On 1/16/2022 5:20 PM, Chad wrote:
I have been reading a lot more about the problem and it seems my mangle/unmangle solution is basically B2BUA. So I need a B2BUA solution and it seems like Kamailio does not really do B2BUA. Instead of installing something else I don't know (SEMS or Sippy), it makes more sense to find something that can handle it all. I have read that opensips has B2BUA functionality built in, so I am seriously considering simply replacing Kamailio with opensips. In reality my system has such a low load I can probably replace Kamailio with Asterisk as a B2BUA and it would be fine, but from what I have read Asterisk is very inefficient for B2BUA.
-- ^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
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <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> 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.encod... 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.enc... 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.con... 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> 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 for seqno 102 (Critical Response) -- See >>>> 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
- no
>>>> reply to our critical packet (see 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> 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> 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> 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> 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> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> VoIP Embedded, Inc. >>>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
-- 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
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
-
Chad -
David Villasmil -
Michael Young -
Ovidiu Sas -
Shah Hussain Khattak