14 Jan
2022
14 Jan
'22
6:26 p.m.
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
15 Jan
15 Jan
3:55 p.m.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
5:48 p.m.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:36 p.m.
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(a)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(a)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(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
7:49 p.m.
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(a)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(a)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(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:05 p.m.
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(a)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(a)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(a)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(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only to
the sender!
>>>> Edit mailing list options or unsubscribe:
>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
8:14 p.m.
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only to
the sender!
>>>> Edit mailing list options or unsubscribe:
>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
9:07 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>>> Edit mailing list options or unsubscribe:
>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>>
>>>>> __________________________________________________________
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>> * sr-users(a)lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
9:09 p.m.
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(a)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(a)hotmail.com> wrote:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>>> Edit mailing list options or unsubscribe:
>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>>
>>>>> __________________________________________________________
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>> * sr-users(a)lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
8:32 p.m.
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(a)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(a)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(a)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(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only to
the sender!
>>>> Edit mailing list options or unsubscribe:
>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
9:21 p.m.
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>>> Edit mailing list options or unsubscribe:
>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>>
>>>>> __________________________________________________________
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>> * sr-users(a)lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
9:28 p.m.
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>> Important: keep the mailing list in the recipients, do not reply
only to the sender!
>>>>>> Edit mailing list options or unsubscribe:
>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> VoIP Embedded, Inc.
>>>>> http://www.voipembedded.com
>>>>>
>>>>> __________________________________________________________
>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>> * sr-users(a)lists.kamailio.org
>>>>> Important: keep the mailing list in the recipients, do not reply only
to the sender!
>>>>> Edit mailing list options or unsubscribe:
>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>
>
>
10:40 p.m.
As expected, your carrier is bogus and "thinks" it knows better.
Your carrier is treating your setup as a dumb endpoint and is
re-writing the Contact header:
You provide this contact header in 200 OK:
Contact: <sip:928#######@10.###.###.104:5060>
The carrier should set the RURI in ACK like this:
ACK sip:928#######@10.###.###.104:5060 SIP/2.0
Instead, your ACK is sent to you like this:
ACK sip:928#######@209.###.###.###:5060 SIP/2.0
The RURI in ACK should point to the private IP of the asterisk server,
not to the public IP of the kamailio server.
You need to ask the carrier to follow the SIP RFC and not treat your
endpoints like dumb SIP endpoints.
There's a high chance that they won't do it :)
Your best chance is to manually mangle the URI in Contact in the 200
OK in a way that when you receive the ACK with the mangled RURI, you
can restore the original URI and let kamailio do the proper routing to
the private IP of the asterisk serverr.
You should be able to achieve this by using one of the following functions:
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
Regards,
Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>> Important: keep the mailing list in the recipients, do
not reply only to the sender!
>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>>
>>>>>>> __________________________________________________________
>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>> Important: keep the mailing list in the recipients, do not
reply only to the sender!
>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
16 Jan
16 Jan
5:14 a.m.
Ok so in short I was not doing anything wrong (although I had some miss-configurations),
but the carrier is (i.e. they
are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense
they meant in the "to work
with us" sense. Now in order for me to get it to work with their SBC I have to mangle
the contact on the way out an
unmangle it on the return in Kamailio somehow, as I originally purposed.
However I have no idea how to do that :)
Shouldn't we (the Kamailio community) assume there are lots of bad actors out there
and possibly many Kamailio users
with this exact same issue (I personally know of at least 2 bad actor carriers right now)
and create some kind of
template or snippet that we can publicly publish on the Kamailio docs or wiki for all of
the Kamailio community to use
for this use case?
I have been fighting with carriers about this for years and they always said I was doing
it wrong and I don't know the
SIP RFC well enough to fight back. So why not build a solution for everyone out there that
has to deal with a bad actor?
--
^C
On 1/15/22 11:40 AM, Ovidiu Sas wrote:
As expected, your carrier is bogus and
"thinks" it knows better.
Your carrier is treating your setup as a dumb endpoint and is
re-writing the Contact header:
You provide this contact header in 200 OK:
Contact: <sip:928#######@10.###.###.104:5060>
The carrier should set the RURI in ACK like this:
ACK sip:928#######@10.###.###.104:5060 SIP/2.0
Instead, your ACK is sent to you like this:
ACK sip:928#######@209.###.###.###:5060 SIP/2.0
The RURI in ACK should point to the private IP of the asterisk server,
not to the public IP of the kamailio server.
You need to ask the carrier to follow the SIP RFC and not treat your
endpoints like dumb SIP endpoints.
There's a high chance that they won't do it :)
Your best chance is to manually mangle the URI in Contact in the 200
OK in a way that when you receive the ACK with the mangled RURI, you
can restore the original URI and let kamailio do the proper routing to
the private IP of the asterisk serverr.
You should be able to achieve this by using one of the following functions:
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
Regards,
Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>> Important: keep the mailing list in the recipients, do
not reply only to the sender!
>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>>
>>>>>>> __________________________________________________________
>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>> Important: keep the mailing list in the recipients, do not
reply only to the sender!
>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
noon
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/0312…
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(a)lists.kamailio.org> on behalf of Chad
<ccolumbu(a)hotmail.com>
Sent: Sunday, January 16, 2022 10:14 AM
To: Ovidiu Sas <osas(a)voipembedded.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)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.enco…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
Regards,
Ovidiu Sas
On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)hotmail.com> wrote:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>> Important: keep the mailing list in the recipients, do
not reply only to the sender!
>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> VoIP Embedded, Inc.
>>>>>>> http://www.voipembedded.com
>>>>>>>
>>>>>>> __________________________________________________________
>>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>> Important: keep the mailing list in the recipients, do not
reply only to the sender!
>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
2:32 p.m.
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/0312…
<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(a)lists.kamailio.org> on behalf of Chad
<ccolumbu(a)hotmail.com>
*Sent:* Sunday, January 16, 2022 10:14 AM
*To:* Ovidiu Sas <osas(a)voipembedded.com>
*Cc:* Kamailio (SER) - Users Mailing List <sr-users(a)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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
As expected, your carrier is bogus and
"thinks" it knows better.
Your carrier is treating your setup as a dumb endpoint and is
re-writing the Contact header:
You provide this contact header in 200 OK:
Contact: <sip:928#######@10.###.###.104:5060>
The carrier should set the RURI in ACK like this:
ACK sip:928#######@10.###.###.104:5060 SIP/2.0
Instead, your ACK is sent to you like this:
ACK sip:928#######@209.###.###.###:5060 SIP/2.0
The RURI in ACK should point to the private IP of the asterisk server,
not to the public IP of the kamailio server.
You need to ask the carrier to follow the SIP RFC and not treat your
endpoints like dumb SIP endpoints.
There's a high chance that they won't do it :)
Your best chance is to manually mangle the URI in Contact in the 200
OK in a way that when you receive the ACK with the mangled RURI, you
can restore the original URI and let kamailio do the proper routing to
the private IP of the asterisk serverr.
You should be able to achieve this by using one of the following functions:
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
<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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>> Important: keep the mailing list in the recipients, do
not reply only to the sender!
>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<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(a)lists.kamailio.org
>>>>>>> Important: keep the mailing list in the recipients, do not
reply only to the sender!
>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
7:26 p.m.
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(a)hotmail.com> wrote:
Ok so in short I was not doing anything wrong (although I had some miss-configurations),
but the carrier is (i.e. they
are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense
they meant in the "to work
with us" sense. Now in order for me to get it to work with their SBC I have to
mangle the contact on the way out an
unmangle it on the return in Kamailio somehow, as I originally purposed.
However I have no idea how to do that :)
Shouldn't we (the Kamailio community) assume there are lots of bad actors out there
and possibly many Kamailio users
with this exact same issue (I personally know of at least 2 bad actor carriers right now)
and create some kind of
template or snippet that we can publicly publish on the Kamailio docs or wiki for all of
the Kamailio community to use
for this use case?
I have been fighting with carriers about this for years and they always said I was doing
it wrong and I don't know the
SIP RFC well enough to fight back. So why not build a solution for everyone out there
that has to deal with a bad actor?
--
^C
On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> As expected, your carrier is bogus and "thinks" it knows better.
> Your carrier is treating your setup as a dumb endpoint and is
> re-writing the Contact header:
> You provide this contact header in 200 OK:
> Contact: <sip:928#######@10.###.###.104:5060>
> The carrier should set the RURI in ACK like this:
> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
> Instead, your ACK is sent to you like this:
> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>
> The RURI in ACK should point to the private IP of the asterisk server,
> not to the public IP of the kamailio server.
> You need to ask the carrier to follow the SIP RFC and not treat your
> endpoints like dumb SIP endpoints.
>
> There's a high chance that they won't do it :)
> Your best chance is to manually mangle the URI in Contact in the 200
> OK in a way that when you receive the ACK with the mangled RURI, you
> can restore the original URI and let kamailio do the proper routing to
> the private IP of the asterisk serverr.
> You should be able to achieve this by using one of the following functions:
>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>
> Regards,
> Ovidiu Sas
>
> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>> http://www.voipembedded.com
>>>>>>>>>
>>>>>>>>>
__________________________________________________________
>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>>>> Important: keep the mailing list in the recipients,
do not reply only to the sender!
>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
17 Jan
17 Jan
12:09 a.m.
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(a)hotmail.com> wrote:
Ok so in short I was not doing anything wrong (although I had some miss-configurations),
but the carrier is (i.e. they
are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense
they meant in the "to work
with us" sense. Now in order for me to get it to work with their SBC I have to
mangle the contact on the way out an
unmangle it on the return in Kamailio somehow, as I originally purposed.
However I have no idea how to do that :)
Shouldn't we (the Kamailio community) assume there are lots of bad actors out there
and possibly many Kamailio users
with this exact same issue (I personally know of at least 2 bad actor carriers right now)
and create some kind of
template or snippet that we can publicly publish on the Kamailio docs or wiki for all of
the Kamailio community to use
for this use case?
I have been fighting with carriers about this for years and they always said I was doing
it wrong and I don't know the
SIP RFC well enough to fight back. So why not build a solution for everyone out there
that has to deal with a bad actor?
--
^C
On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> As expected, your carrier is bogus and "thinks" it knows better.
> Your carrier is treating your setup as a dumb endpoint and is
> re-writing the Contact header:
> You provide this contact header in 200 OK:
> Contact: <sip:928#######@10.###.###.104:5060>
> The carrier should set the RURI in ACK like this:
> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
> Instead, your ACK is sent to you like this:
> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>
> The RURI in ACK should point to the private IP of the asterisk server,
> not to the public IP of the kamailio server.
> You need to ask the carrier to follow the SIP RFC and not treat your
> endpoints like dumb SIP endpoints.
>
> There's a high chance that they won't do it :)
> Your best chance is to manually mangle the URI in Contact in the 200
> OK in a way that when you receive the ACK with the mangled RURI, you
> can restore the original URI and let kamailio do the proper routing to
> the private IP of the asterisk serverr.
> You should be able to achieve this by using one of the following functions:
>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>
> Regards,
> Ovidiu Sas
>
> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>> http://www.voipembedded.com
>>>>>>>>>
>>>>>>>>>
__________________________________________________________
>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>>>> Important: keep the mailing list in the recipients,
do not reply only to the sender!
>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
12:38 a.m.
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(a)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:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
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(a)hotmail.com> wrote:
>
> Ok so in short I was not doing anything wrong (although I had some
miss-configurations), but the carrier is (i.e. they
> are a bad actor). When they said I was doing
it wrong, they did not
mean in the RFC sense they meant in the "to work
> with us" sense. Now in order for me to
get it to work with their SBC I
have to mangle the contact on the way out an
> unmangle it on the return in Kamailio
somehow, as I originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots of bad
actors
out there and possibly many Kamailio users
> with this exact same issue (I personally know
of at least 2 bad actor
carriers right now) and create some kind of
> template or snippet that we can publicly
publish on the Kamailio docs
or wiki for all of the Kamailio community to use
> for this use case?
>
> I have been fighting with carriers about this for years and they always
said I
was doing it wrong and I don't know the
> SIP RFC well enough to fight back. So why not
build a solution for
everyone out there that has to deal with a bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>> As expected, your carrier is bogus and "thinks" it knows better.
>> Your carrier is treating your setup as a dumb endpoint and is
>> re-writing the Contact header:
>> You provide this contact header in 200 OK:
>> Contact: <sip:928#######@10.###.###.104:5060>
>> The carrier should set the RURI in ACK like this:
>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>> Instead, your ACK is sent to you like this:
>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>
>> The RURI in ACK should point to the private IP of the asterisk server,
>> not to the public IP of the kamailio server.
>> You need to ask the carrier to follow the SIP RFC and not treat your
>> endpoints like dumb SIP endpoints.
>>
>> There's a high chance that they won't do it :)
>> Your best chance is to manually mangle the URI in Contact in the 200
>> OK in a way that when you receive the ACK with the mangled RURI, you
>> can restore the original URI and let kamailio do the proper routing to
>> the private IP of the asterisk serverr.
>> You should be able to achieve this by using one of the following
functions:
>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>>
>>> Regards,
>>> Ovidiu Sas
>>
>>> On Sat, Jan 15, 2022
at 1:28 PM Chad <ccolumbu(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not
reply only to the sender!
>>>>>>>>>>> Edit
mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
>>>>>>>>>>
>>>>>>>>>>
__________________________________________________________
>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>>> * sr-users(a)lists.kamailio.org
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not
reply only to the sender!
>>>>>>>>>> Edit
mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>
>
>
2:06 a.m.
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(a)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:
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
>
> Ok so in short I was not doing anything wrong (although I had some
miss-configurations), but the carrier is
(i.e. they
> are a bad actor). When they said I was doing
it wrong, they did not mean in the RFC sense they meant in the "to work
> with us" sense. Now in order for me to get it to work with their SBC I have to
mangle the contact on the way out an
> unmangle it on the return in Kamailio somehow, as I originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots of bad actors out
there and possibly many Kamailio users
> with this exact same issue (I personally know of at least 2 bad actor carriers right
now) and create some kind of
> template or snippet that we can publicly publish on the Kamailio docs or wiki for all
of the Kamailio community
to use
> for this use case?
>
> I have been fighting with carriers about this for years and they always said I was
doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a solution for everyone out there that has to deal with a
bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>> As expected, your carrier is bogus and "thinks" it knows better.
>> Your carrier is treating your setup as a dumb endpoint and is
>> re-writing the Contact header:
>> You provide this contact header in 200 OK:
>> Contact: <sip:928#######@10.###.###.104:5060>
>> The carrier should set the RURI in ACK like this:
>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>> Instead, your ACK is sent to you like this:
>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>
>> The RURI in ACK should point to the private IP of the asterisk server,
>> not to the public IP of the kamailio server.
>> You need to ask the carrier to follow the SIP RFC and not treat your
>> endpoints like dumb SIP endpoints.
>>
>> There's a high chance that they won't do it :)
>> Your best chance is to manually mangle the URI in Contact in the 200
>> OK in a way that when you receive the ACK with the mangled RURI, you
>> can restore the original URI and let kamailio do the proper routing to
>> the private IP of the asterisk serverr.
>> You should be able to achieve this by using one of the following functions:
>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
<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(a)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>
>>> 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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com>
>>>>>>>>>>
>>>>>>>>>>
__________________________________________________________
>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>>> * sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
2:16 a.m.
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad <ccolumbu(a)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:
seqno 102
(Critical Response) -- See
--
VoIP Embedded, Inc.
http://www.voipembedded.com
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(a)hotmail.com <mailto:
ccolumbu(a)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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
>>
>> Ok so in short I was not doing anything wrong (although I had
some
miss-configurations), but the carrier is
(i.e. they
>> are a bad actor). When they said I was doing it wrong, they did
not
mean in the RFC sense they meant in the "to work
>> with us" sense. Now in order
for me to get it to work with their
SBC I have to mangle the contact on the way out
an
>> unmangle it on the return in
Kamailio somehow, as I originally
purposed.
>> However I have no idea how to do
that :)
>>
>> Shouldn't we (the Kamailio community) assume there are lots of
bad actors out there and possibly many Kamailio users
>> with this exact same issue (I
personally know of at least 2 bad
actor carriers right now) and create some kind
of
>> template or snippet that we can
publicly publish on the Kamailio
docs or wiki for all of the Kamailio community
to use
>> for this use case?
>>
>> I have been fighting with carriers about this for years and they
always said I was doing it wrong and I don't
know the
>> SIP RFC well enough to fight back. So why not build a solution
for
everyone out there that has to deal with a
bad actor?
>>
>> --
>> ^C
>>
>>
>> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>>> As expected, your carrier is bogus and "thinks" it knows
better.
>>> Your carrier is treating your setup as a dumb endpoint and is
>>> re-writing the Contact header:
>>> You provide this contact header in 200 OK:
>>> Contact: <sip:928#######@10.###.###.104:5060>
>>> The carrier should set the RURI in ACK like this:
>>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>>> Instead, your ACK is sent to you like this:
>>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>>
>>> The RURI in ACK should point to the private IP of the asterisk
server,
>>> not to the public IP of the
kamailio server.
>>> You need to ask the carrier to follow the SIP RFC and not treat
your
>>> endpoints like dumb SIP
endpoints.
>>>
>>> There's a high chance that they won't do it :)
>>> Your best chance is to manually mangle the URI in Contact in
the
200
>>> OK in a way that when you
receive the ACK with the mangled
RURI, you
>>> can restore the original URI
and let kamailio do the proper
routing to
>>> the private IP of the asterisk
serverr.
>>> You should be able to achieve this by using one of the
following
functions:
>>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>
>>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>
>>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>
>>>
> >>>
Regards,
> >>> Ovidiu Sas
>>>
> >>>
On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>
http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060> - no
>>> 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 < >>>> 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(a)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(a)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(a)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(a)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>>
>>>>>>>>>>>>
>>>>>>>>>>>> There are 2 possible solutions to
this:
>>>>>>>>>>>> 1. Make changes to linux,
keepalived and/or Kamailio
so that Kamailio recognize the virtual IPs so
that mhomed and
>>>>>>>>>>>> fix_nated_contact work as usual.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Create a manual header rewrite
system.
>>>>>>>>>>>>
>>>>>>>>>>>> If solution #2:
>>>>>>>>>>>> What we need to do is create a way
to rewrite the
contact header to the external IP on the way out,
and on the way back
>>>>>>>>>>>> rewrite it back to the internal
server that the call
is already connected to.
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure if we will need to store
those paths on the
server or if we can do some kind of cheat with
another persistant
>>>>>>>>>>>> header like P-Preferred-Identity or
P-Asserted-Identity (i.e. store the internal IP in the name field
or something).
>>>>>>>>>>>>
>>>>>>>>>>>> If anyone out there know of a way
to do this or wants
to give it a try please reach out to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you all for your time.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> ^C
>>>>>>>>>>>> Chad
>>>>>>>>>>>>
>>>>>>>>>>>>
__________________________________________________________
>>>>>>>>>>>> Kamailio - Users Mailing List - Non
Commercial
Discussions
>>>>>>>>>>>> * sr-users(a)lists.kamailio.org
<mailto:
sr-users(a)lists.kamailio.org>
>>>>>>>>>>>> Important: keep the mailing list in the
recipients, do
not reply only to the sender!
>>>>>>>>>>>> Edit mailing list options or
unsubscribe:
>>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<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(a)lists.kamailio.org <mailto:
sr-users(a)lists.kamailio.org>
>>>>>>>>>>>
Important: keep the mailing list in the recipients, do
not reply only to the
sender!
>>>>>>>>>>>
Edit mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
>>>
>>>
>>>
> >
> >
> >
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com <http://www.voipembedded.com>
2:21 a.m.
If I use my external IP do I turn off enable_double_rr?
--
^C
On 1/16/22 3:16 PM, Ovidiu Sas wrote:
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad <ccolumbu(a)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:
the "to work
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>> - no
reach you
created
field
--
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>
Have you tried using the mask_ip param:
https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask…
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <ccolumbu(a)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(a)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 >> 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
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
> for this use case?
>
> I have been fighting with carriers about this for years and they always said I was
doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a solution for everyone out there that has to deal with a
bad actor?
>>
>> --
>> ^C
>>
>>
>> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>>> As expected, your carrier is bogus and "thinks" it knows
better.
>>> Your carrier is treating your setup as a dumb endpoint and is
>>> re-writing the Contact header:
>>> You provide this contact header in 200 OK:
>>> Contact: <sip:928#######@10.###.###.104:5060>
>>> The carrier should set the RURI in ACK like this:
>>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>>> Instead, your ACK is sent to you like this:
>>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>>
>>> The RURI in ACK should point to the private IP of the asterisk server,
>>> not to the public IP of the kamailio server.
>>> You need to ask the carrier to follow the SIP RFC and not treat your
>>> endpoints like dumb SIP endpoints.
>>>
>>> There's a high chance that they won't do it :)
>>> Your best chance is to manually mangle the URI in Contact in the 200
>>> OK in a way that when you receive the ACK with the mangled RURI, you
>>> can restore the original URI and let kamailio do the proper routing to
>>> the private IP of the asterisk serverr.
>>> You should be able to achieve this by using one of the following
functions:
>>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>>
<https://kamailio.org/docs/modules/5.5.x/modules/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>>
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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>>
>>> 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> >>>> 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(a)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 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(a)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
because
>>>>>>> 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 of the virtual
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>> wrote:
>>>>>>> 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(a)hotmail.com <mailto:ccolumbu@hotmail.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(a)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 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 or something).
>>>>>>>>>>>>
>>>>>>>>>>>> If anyone out there know of a way
to do this or wants to give it a try please reach out to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you all for your time.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> ^C
>>>>>>>>>>>> Chad
>>>>>>>>>>>>
>>>>>>>>>>>>
__________________________________________________________
>>>>>>>>>>>> Kamailio - Users Mailing List - Non
Commercial Discussions
>>>>>>>>>>>> *
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
>>>>>>>>>>>> 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(a)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>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
2:54 a.m.
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(a)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:
the "to work
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>> - no
reach you
created
field
--
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>
Have you tried using the mask_ip param:
https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask…
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>
-ovidiu
On Sun, Jan 16, 2022 at 16:09 Chad <ccolumbu(a)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(a)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 >> 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
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
> for this use case?
>
> I have been fighting with carriers about this for years and they always said I was
doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a solution for everyone out there that has to deal with a
bad actor?
>>
>> --
>> ^C
>>
>>
>> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>>> As expected, your carrier is bogus and "thinks" it knows
better.
>>> Your carrier is treating your setup as a dumb endpoint and is
>>> re-writing the Contact header:
>>> You provide this contact header in 200 OK:
>>> Contact: <sip:928#######@10.###.###.104:5060>
>>> The carrier should set the RURI in ACK like this:
>>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>>> Instead, your ACK is sent to you like this:
>>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>>
>>> The RURI in ACK should point to the private IP of the asterisk server,
>>> not to the public IP of the kamailio server.
>>> You need to ask the carrier to follow the SIP RFC and not treat your
>>> endpoints like dumb SIP endpoints.
>>>
>>> There's a high chance that they won't do it :)
>>> Your best chance is to manually mangle the URI in Contact in the 200
>>> OK in a way that when you receive the ACK with the mangled RURI, you
>>> can restore the original URI and let kamailio do the proper routing to
>>> the private IP of the asterisk serverr.
>>> You should be able to achieve this by using one of the following
functions:
>>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>>
<https://kamailio.org/docs/modules/5.5.x/modules/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>>
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)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>>
>>> 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> >>>> 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(a)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 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(a)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
because
>>>>>>> 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 of the virtual
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>> wrote:
>>>>>>> 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(a)hotmail.com <mailto:ccolumbu@hotmail.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(a)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 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 or something).
>>>>>>>>>>>>
>>>>>>>>>>>> If anyone out there know of a way
to do this or wants to give it a try please reach out to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you all for your time.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> ^C
>>>>>>>>>>>> Chad
>>>>>>>>>>>>
>>>>>>>>>>>>
__________________________________________________________
>>>>>>>>>>>> Kamailio - Users Mailing List - Non
Commercial Discussions
>>>>>>>>>>>> *
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
>>>>>>>>>>>> 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(a)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>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
11:41 a.m.
Take a look at freeSWITCH
On Mon, 17 Jan 2022 at 00:58, Chad <ccolumbu(a)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:
seqno
102 (Critical Response) -- See
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad <ccolumbu(a)hotmail.com <mailto:
ccolumbu(a)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…
> <
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(a)hotmail.com <mailto:
ccolumbu(a)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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>> wrote:
> >>
> >> Ok so in short I was not doing anything wrong (although I
had some miss-configurations), but the carrier is
> (i.e. they
> >> are a bad actor). When they said I was doing it wrong,
they did not mean in the RFC sense they meant in
the "to work
> >> with us" sense. Now in order for me to get it to work
with their SBC I have to mangle the contact on the
way out an
> >> unmangle it on the return in Kamailio somehow, as I
originally purposed.
> >> However I have no idea
how to do that :)
> >>
> >> Shouldn't we (the Kamailio community) assume there are
lots of bad actors out there and possibly many
Kamailio users
> >> with this exact same issue (I personally know of at least
2 bad actor carriers right now) and create some
kind of
> >> template or snippet that we can publicly publish on the
Kamailio docs or wiki for all of the Kamailio
community
> to use
> >> for this use case?
> >>
> >> I have been fighting with carriers about this for years
and they always said I was doing it wrong and I don't
> know the
> >> SIP RFC well enough to fight back. So why not build a
solution for everyone out there that has to deal with a
> bad actor?
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> >>> As expected, your carrier is bogus and "thinks" it
knows
better.
> >>> Your carrier is
treating your setup as a dumb endpoint
and is
> >>> re-writing the
Contact header:
> >>> You provide this contact header in 200 OK:
> >>> Contact: <sip:928#######@10.###.###.104:5060>
> >>> The carrier should set the RURI in ACK like this:
> >>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
> >>> Instead, your ACK is sent to you like this:
> >>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
> >>>
> >>> The RURI in ACK should point to the private IP of the
asterisk server,
> >>> not to the public IP
of the kamailio server.
> >>> You need to ask the carrier to follow the SIP RFC and
not treat your
> >>> endpoints like dumb
SIP endpoints.
> >>>
> >>> There's a high chance that they won't do it :)
> >>> Your best chance is to manually mangle the URI in
Contact in the 200
> >>> OK in a way that when
you receive the ACK with the
mangled RURI, you
> >>> can restore the
original URI and let kamailio do the
proper routing to
> >>> the private IP of the
asterisk serverr.
> >>> You should be able to achieve this by using one of the
following functions:
> >>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>
> <
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
>>
> >>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>
> <
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
>>
> >>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>
> <
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
<
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
>>
> >>>
> >
>>> Regards,
> > >>> Ovidiu Sas
> >>>
> >
>>> On Sat, Jan 15, 2022 at 1:28 PM Chad <
ccolumbu(a)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 > >>>>
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
> >>>> 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(a)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
> >>>> 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(a)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(a)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(a)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(a)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(a)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>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> There are 2 possible
solutions to this:
> >>>>>>>>>>>> 1. Make changes to linux,
keepalived and/or
Kamailio so that Kamailio recognize the virtual IPs so
> that mhomed and
> >>>>>>>>>>>> fix_nated_contact work as
usual.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2. Create a manual header
rewrite system.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If solution #2:
> >>>>>>>>>>>> What we need to do is
create a way to rewrite
the contact header to the external IP on the way out,
> and on the way back
> >>>>>>>>>>>> rewrite it back to the
internal server that the
call is already connected to.
>
>>>>>>>>>>>>
> >>>>>>>>>>>> Not sure if we will need
to store those paths
on the server or if we can do some kind of cheat with
> another persistant
> >>>>>>>>>>>> header like
P-Preferred-Identity or
P-Asserted-Identity (i.e. store the internal IP in the
name
field
> or something).
> >>>>>>>>>>>>
> >>>>>>>>>>>> If anyone out there know
of a way to do this or
wants to give it a try please reach out to me.
>
>>>>>>>>>>>>
> >>>>>>>>>>>> Thank you all for your
time.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> ^C
> >>>>>>>>>>>> Chad
> >>>>>>>>>>>>
> >>>>>>>>>>>>
__________________________________________________________
>
>>>>>>>>>>>> Kamailio - Users Mailing List - Non
Commercial
Discussions
>
>>>>>>>>>>>> * sr-users(a)lists.kamailio.org
<mailto:
sr-users(a)lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org
<mailto:
sr-users(a)lists.kamailio.org>>
>
>>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>
>>>>>>>>>>>> Edit mailing list options or
unsubscribe:
> >>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
http://www.voipembedded.com> <http://www.voipembedded.com
<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(a)lists.kamailio.org
<mailto:
sr-users(a)lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org
<mailto:
sr-users(a)lists.kamailio.org>>
>
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>
>>>>>>>>>>> Edit mailing list options or unsubscribe:
> >>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:05 p.m.
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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
Hmm, it did not fix it (calls still work with my other carriers).
It looks to me like it should work, it does use the external IP for everything.
It generates an error in the log about making your existing address:
topoh [topoh_mod.c:179]: mod_init(): mask address matches myself [209.###.###.###]
Here is ther 200 and ACK.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.0
Via: SIP/2.0/UDP
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKrs8bqi00cg14535baf70.1
Record-Route:
<sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*>
Record-Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75>
Record-Route: <sip:64.###.###.###;lr;ftag=as471a1f75>
From: "Anonymous"
<sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75
To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1
Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@10.44.###.###:5060
CSeq: 102 INVITE
Server: Asterisk PBX 16.18.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Contact:
<sip:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF*>
Content-Type: application/sdp
Content-Length: 274
v=0
o=root 1644013823 1644013823 IN IP4 209.###.###.###
s=Asterisk PBX 16.18.0
c=IN IP4 209.###.###.###
t=0 0
m=audio 19180 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=nortpproxy:yes
ACK sip:209.###.###.###;line=sr-1RaGXx7VX8CAKx1yp8oFKfFqKfFqKfFqKfFVXx9GpxF* SIP/2.0
Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bKf229.9bb425c2.2
Via: SIP/2.0/UDP
206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bKvtgb6f1048h1g6l9s890.1
Max-Forwards: 67
From: "Anonymous"
<sip:anonymous@anonymous.invalid:5060>;tag=as471a1f75
To: <sip:928#######@64.###.###.###:5060>;tag=as199dc3d1
Contact: <sip:anonymous@206.###.###.###:5060;transport=udp>
Call-ID: 3510f7167e1a0f6a5423234b1d176a8b@10.44.###.###:5060
CSeq: 102 ACK
User-Agent: packetrino
Content-Length: 0
Route: <sip:209.###.###.###;r2=on;lr=on;ftag=as471a1f75>
Route:
<sip:209.###.###.###;line=sr-1RaGXxdGcxdGcxdGcxgTp8eVKxT-jxeE1xT-jxehH02vI52Ap81.Nf2hpA9*>
--
^C
On 1/16/22 3:16 PM, Ovidiu Sas wrote:
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad <ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>> wrote:
Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but again
because 172.16.x.x is also a
private IP
it is the same as using my real 10.x.x.x IP.
The carrier's ACK throws away the local IP and sends the
response to my
209.x external IP.
--
^C
On 1/16/22 1:38 PM, Ovidiu Sas wrote:
> Have you tried using the mask_ip param:
> https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask…
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>
>
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
<https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip>>>
>
> -ovidiu
>
> On Sun, Jan 16, 2022 at 16:09 Chad <ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>>> wrote:
>
> I found a sample config file using topoh, which I copied (with some
changes) and added the topoh
module to my
config.
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
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(a)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
create some
>> 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 kind of
and I don't
>> 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 > know the
> >> SIP RFC well enough to fight back. So why not build a solution
for everyone out there that has to
deal with a
> bad actor?
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> >>> As expected, your carrier is bogus and "thinks" it
knows better.
> >>> Your carrier is treating your setup as a dumb endpoint and
is
> >>> re-writing the Contact header:
> >>> You provide this contact header in 200 OK:
> >>> Contact: <sip:928#######@10.###.###.104:5060>
> >>> The carrier should set the RURI in ACK like this:
> >>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
> >>> Instead, your ACK is sent to you like this:
> >>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
> >>>
> >>> The RURI in ACK should point to the private IP of the
asterisk server,
> >>> not to the public IP of the kamailio server.
> >>> You need to ask the carrier to follow the SIP RFC and not
treat your
> >>> endpoints like dumb SIP endpoints.
> >>>
> >>> There's a high chance that they won't do it :)
> >>> Your best chance is to manually mangle the URI in Contact in
the 200
> >>> OK in a way that when you receive the ACK with the mangled
RURI, you
> >>> can restore the original URI and let kamailio do the proper
routing to
> >>> the private IP of the asterisk serverr.
> >>> You should be able to achieve this by using one of the
following functions:
> >>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>>
>
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>>>
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.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>>>
> >>>
> >>> Regards,
> >>> Ovidiu Sas
> >>>
> >>> On Sat, Jan 15, 2022 at 1:28 PM Chad <ccolumbu(a)hotmail.com
<mailto:ccolumbu@hotmail.com>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>>> wrote:
> >>>>
> >>>> I changed the listen per your advice and here is the 200
and ACK.
> >>>> I get no audio and the the call disconnects and I see
this is the Asterisk log:
> >>>> [Jan 15 10:17:13] WARNING[29953] chan_sip.c:
Retransmission timeout reached on transmission
> >>>> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>
>
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060
<http://5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060>>> for seqno 102
(Critical Response) -- See
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>>
>
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
<https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions>>>
> >>>> 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(a)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(a)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(a)hotmail.com <mailto:ccolumbu@hotmail.com>
<mailto:ccolumbu@hotmail.com <mailto:ccolumbu@hotmail.com>>
<mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com> <mailto:ccolumbu@hotmail.com
<mailto:ccolumbu@hotmail.com>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Ovidiu,
>>>>>>>>>> Thank you for your response.
>>>>>>>>>>
>>>>>>>>>> I have done that, in addition to the linux
ip_nonlocal_bind I have also set the Kamailio
ip_free_bind=1
and it does not
>>>>>>>>>> work.
>>>>>>>>>> Here are my relevant config lines:
>>>>>>>>>> listen=LISTEN_UDP_PRIVATE advertise
MY_PUBLIC_IP:5060
>>>>>>>>>> listen=LISTEN_UDP_PUBLIC
>>>>>>>>>>
>>>>>>>>>> mhomed=1
>>>>>>>>>> ip_free_bind=1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In my /etc/sysctl.conf I have (yes I
applied it with sysctl -p, and I have been using it for a
long time
> and have
> >>>>>>>>>> rebooted as well):
> >>>>>>>>>> net.ipv4.ip_nonlocal_bind=1
> >>>>>>>>>> --
> >>>>>>>>>> ^C
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 1/15/22 4:55 AM, Ovidiu Sas
wrote:
> >>>>>>>>>>> Hello Chad,
> >>>>>>>>>>>
> >>>>>>>>>>> You can add a listen
directive to your config for the virtual IPs
> >>>>>>>>>>> (both public and private) and
then you don't need to manually modify
> >>>>>>>>>>> any headers or use
force_send_socket().
> >>>>>>>>>>> You need to enable non local
IP binding so kamailio can start on the
> >>>>>>>>>>> server that doesn't have
the virtual IP:
> >>>>>>>>>>> echo 1 >
/proc/sys/net/ipv4/ip_nonlocal_bind
> >>>>>>>>>>> To make the change permanent,
edit your sysctl.conf file and enable it there:
> >>>>>>>>>>> net/ipv4/ip_nonlocal_bind =
1
> >>>>>>>>>>>
> >>>>>>>>>>> Regards
> >>>>>>>>>>> Ovidiu Sas
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Sat, Jan 15, 2022 at 4:16
AM Chad <ccolumbu(a)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
<http://10.10.10.#%23%23]:5060 <http://10.10.10.#%23%23]:5060>>
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>>>>
>
>>>>>>>>>>>>
> >>>>>>>>>>>> There are 2 possible
solutions to this:
> >>>>>>>>>>>> 1. Make changes to linux,
keepalived and/or Kamailio so that Kamailio recognize the
virtual IPs so
> that mhomed and
> >>>>>>>>>>>> fix_nated_contact work as
usual.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2. Create a manual header
rewrite system.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If solution #2:
> >>>>>>>>>>>> What we need to do is
create a way to rewrite the contact header to the external IP on
the way out,
> and on the way back
> >>>>>>>>>>>> rewrite it back to the
internal server that the call is already connected to.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Not sure if we will need
to store those paths on the server or if we can do some kind of
cheat with
> another persistant
> >>>>>>>>>>>> header like
P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in
the
name
field
> or something).
> >>>>>>>>>>>>
> >>>>>>>>>>>> If anyone out there know
of a way to do this or wants to give it a try please reach out
to me.
>
>>>>>>>>>>>>
> >>>>>>>>>>>> Thank you all for your
time.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> ^C
> >>>>>>>>>>>> Chad
> >>>>>>>>>>>>
> >>>>>>>>>>>>
__________________________________________________________
> >>>>>>>>>>>> Kamailio - Users Mailing
List - Non Commercial Discussions
> >>>>>>>>>>>> *
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
<mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>>
>
>>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
> >>>>>>>>>>>> Edit mailing list options
or unsubscribe:
> >>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>>
>
>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> VoIP Embedded, Inc.
> >>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com> <http://www.voipembedded.com
<http://www.voipembedded.com>> <http://www.voipembedded.com
<http://www.voipembedded.com>
<http://www.voipembedded.com
<http://www.voipembedded.com>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
__________________________________________________________
> >>>>>>>>>>> Kamailio - Users Mailing List
- Non Commercial Discussions
> >>>>>>>>>>> *
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
<mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>>
>
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
> >>>>>>>>>>> Edit mailing list options or
unsubscribe:
> >>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>>
>
>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com <http://www.voipembedded.com>
<http://www.voipembedded.com
<http://www.voipembedded.com>>
<http://www.voipembedded.com <http://www.voipembedded.com>
<http://www.voipembedded.com <http://www.voipembedded.com>>>
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
<http://www.voipembedded.com <http://www.voipembedded.com>>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com <mailto:david.villasmil.work@gmail.com>
phone: +34669448337
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:20 a.m.
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(a)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:
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
>
> Ok so in short I was not doing anything wrong (although I had some
miss-configurations), but the carrier is
(i.e. they
> are a bad actor). When they said I was doing
it wrong, they did not mean in the RFC sense they meant in the "to work
> with us" sense. Now in order for me to get it to work with their SBC I have to
mangle the contact on the way out an
> unmangle it on the return in Kamailio somehow, as I originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots of bad actors out
there and possibly many Kamailio users
> with this exact same issue (I personally know of at least 2 bad actor carriers right
now) and create some kind of
> template or snippet that we can publicly publish on the Kamailio docs or wiki for all
of the Kamailio community
to use
> for this use case?
>
> I have been fighting with carriers about this for years and they always said I was
doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a solution for everyone out there that has to deal with a
bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>> As expected, your carrier is bogus and "thinks" it knows better.
>> Your carrier is treating your setup as a dumb endpoint and is
>> re-writing the Contact header:
>> You provide this contact header in 200 OK:
>> Contact: <sip:928#######@10.###.###.104:5060>
>> The carrier should set the RURI in ACK like this:
>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>> Instead, your ACK is sent to you like this:
>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>
>> The RURI in ACK should point to the private IP of the asterisk server,
>> not to the public IP of the kamailio server.
>> You need to ask the carrier to follow the SIP RFC and not treat your
>> endpoints like dumb SIP endpoints.
>>
>> There's a high chance that they won't do it :)
>> Your best chance is to manually mangle the URI in Contact in the 200
>> OK in a way that when you receive the ACK with the mangled RURI, you
>> can restore the original URI and let kamailio do the proper routing to
>> the private IP of the asterisk serverr.
>> You should be able to achieve this by using one of the following functions:
>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
<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(a)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>
>>> 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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com>
>>>>>>>>>>
>>>>>>>>>>
__________________________________________________________
>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>>> * sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
3:02 a.m.
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(a)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:
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only
to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
>
> Ok so in short I was not doing anything wrong (although I had
some
miss-configurations), but the carrier is
(i.e. they
> are a bad actor). When they said I was doing
it wrong, they
did not mean in the RFC sense they meant in the "to work
> with us" sense. Now in order for me to
get it to work with
their SBC I have to mangle the contact on the way out an
> unmangle it on the return in Kamailio
somehow, as I
originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots
of bad actors
out there and possibly many Kamailio users
> with this exact same issue (I personally know
of at least 2
bad actor carriers right now) and create some kind of
> template or snippet that we can publicly
publish on the
Kamailio docs or wiki for all of the Kamailio community
to use
> for this use case?
>
> I have been fighting with carriers about this for years and
they always said
I was doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a
solution for everyone out there that has to deal with a
bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>> As expected, your carrier is bogus and "thinks" it knows
better.
>> Your carrier is treating your setup as a
dumb endpoint and is
>> re-writing the Contact header:
>> You provide this contact header in 200 OK:
>> Contact: <sip:928#######@10.###.###.104:5060>
>> The carrier should set the RURI in ACK like this:
>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>> Instead, your ACK is sent to you like this:
>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>
>> The RURI in ACK should point to the private IP of the
asterisk server,
>> not to the public IP of the kamailio
server.
>> You need to ask the carrier to follow the SIP RFC and not
treat your
>> endpoints like dumb SIP endpoints.
>>
>> There's a high chance that they won't do it :)
>> Your best chance is to manually mangle the URI in Contact in
the 200
>> OK in a way that when you receive the ACK
with the mangled
RURI, you
>> can restore the original URI and let
kamailio do the proper
routing to
>> the private IP of the asterisk serverr.
>> You should be able to achieve this by using one of the
following
functions:
>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.en…
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
>>
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.co…
<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(a)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>
>>> 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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>>
Important: keep the mailing list in the recipients,
do not reply only to the
sender!
>>>>>>>>>>> Edit
mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com>
>>>>>>>>>>
>>>>>>>>>>
__________________________________________________________
>>>>>>>>>> Kamailio
- Users Mailing List - Non Commercial
Discussions
>>>>>>>>>> *
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>
Important: keep the mailing list in the recipients,
do not reply only to the
sender!
>>>>>>>>>> Edit
mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
5:05 p.m.
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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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(a)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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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(a)hotmail.com
<mailto:ccolumbu@hotmail.com>> wrote:
>
> Ok so in short I was not doing anything wrong (although I had some
miss-configurations), but the carrier is
(i.e. they
> are a bad actor). When they said I was doing
it wrong, they did not mean in the RFC sense they meant in the
"to work
> with us" sense. Now in order for me to
get it to work with their SBC I have to mangle the contact on the way
out an
> unmangle it on the return in Kamailio
somehow, as I originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots of bad actors out
there and possibly many
Kamailio users
> with this exact same issue (I personally know
of at least 2 bad actor carriers right now) and create some
kind of
> template or snippet that we can publicly
publish on the Kamailio docs or wiki for all of the Kamailio community
to use
> for this use case?
>
> I have been fighting with carriers about this for years and they always said I was
doing it wrong and I don't
know the
> SIP RFC well enough to fight back. So why not
build a solution for everyone out there that has to deal with a
bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
>> As expected, your carrier is bogus and "thinks" it knows better.
>> Your carrier is treating your setup as a dumb endpoint and is
>> re-writing the Contact header:
>> You provide this contact header in 200 OK:
>> Contact: <sip:928#######@10.###.###.104:5060>
>> The carrier should set the RURI in ACK like this:
>> ACK sip:928#######@10.###.###.104:5060 SIP/2.0
>> Instead, your ACK is sent to you like this:
>> ACK sip:928#######@209.###.###.###:5060 SIP/2.0
>>
>> The RURI in ACK should point to the private IP of the asterisk server,
>> not to the public IP of the kamailio server.
>> You need to ask the carrier to follow the SIP RFC and not treat your
>> endpoints like dumb SIP endpoints.
>>
>> There's a high chance that they won't do it :)
>> Your best chance is to manually mangle the URI in Contact in the 200
>> OK in a way that when you receive the ACK with the mangled RURI, you
>> can restore the original URI and let kamailio do the proper routing to
>> the private IP of the asterisk serverr.
>> You should be able to achieve this by using one of the following functions:
>>
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.enco…
<https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact>
<https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact>
<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(a)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>
>>> 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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> VoIP Embedded, Inc.
>>>>>>>>>> http://www.voipembedded.com
<http://www.voipembedded.com>
>>>>>>>>>>
>>>>>>>>>>
__________________________________________________________
>>>>>>>>>> Kamailio - Users Mailing List - Non Commercial
Discussions
>>>>>>>>>> * sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
>>>>>>>>>> Important: keep the mailing list in the
recipients, do not reply only to the sender!
>>>>>>>>>> Edit mailing list options or unsubscribe:
>>>>>>>>>> *
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
--
VoIP Embedded, Inc.
http://www.voipembedded.com <http://www.voipembedded.com>
1040
days inactive
1043
days old
27 comments
5 participants
participants (5)
-
Chad -
David Villasmil -
Michael Young -
Ovidiu Sas -
Shah Hussain Khattak