17 Jan
2022
17 Jan
'22
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>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>