14 Feb
2014
14 Feb
'14
11:18 a.m.
Hi there.
So I'm fighting what must be a bit of a common problem here but the usual googling
isn't really helping me out.
A bit of background:
Classic Nat scenario of a sip handset behind a NAT firewall over the internet to VoIP SBC
setup using Kamailio 3.3 and RTPProxy and Freeswitch as the registrar / calls server
behind kamailio.
(please excuse the beautiful ASCI art)
--------------
---- ----| RTPproxy |-------
--------------- ------------ |
-------------- | ---------------
|SIP Phone|--------|Firewall |---------internet-------------| kamailio
|-----------|Freeswitch|
--------------- ------------
-------------- ---------------
SIP Phones can register fine (over TCP or TLS, Kam offloads TLS if used) however when
establishing a call the SIPPhone sends its local network IP address within the SDP
instead of the firewalls external address. Causing media to me miss directed by the RTP
Proxy.
I've put a phone in with STUN to check that this is the only issue and that phone
works fine .Usually in this situation we would just use STUN or TURN / ICE to get around
the issue however the handsets that we are working with (and have to work with for other
reasons) do not support any of these technologies. So I've been forced to try and find
another solution.
I was hoping to find some method within kamailio / RTPproxy to resolve this. I could just
rewrite the SDP in certain situations but that feels a little bit brutal if I'm
honest. I've heard of RTPproxy being able to do some sort of rtp latching where it
can correct its destination ip address after it receives its first rtp packets from the
SIP Phone after being forwarded by the onsite firewall but other than this 'word of
mouth' suggestion I've not managed to find any detail of this functionality in
the usual online resources.
Can anyone suggest any other potential methods for getting around this problem?
Many Thanks
Rob
14 Feb
14 Feb
11:44 a.m.
On Friday 14 February 2014 10:18:07 Rob Moore wrote:
(please excuse the beautiful ASCI art)
You failed, it's not beatifull, it's a mess (be sure to use a monospaced font
and spaces when drawing ASCII art (since not all clients use monospaced to
display it will always fail in some clients)). See
http://lists.sip-router.org/pipermail/sr-users/2014-February/081601.html
for the result as I've seen your art :)
Can anyone suggest any other potential methods for
getting around this
problem?
I learned to never trust anything a client tells me in a SIP message, forcing
all rtp through the rtpproxy only leaves firewall issues at the client IMHO.
On an SBC kind of setup just always call rtpproxy_manage() regardless wheter
you detect a natted client.
In the "default" kamailio.conf just move rtpproxy_manage in the
route[NATMANAGE] to the beginning of the route (the f to use the local
rtpproxy even if an other rtpproxy is detected)
# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
rtpproxy_manage("f");
if (is_request()) {
....
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
5:31 p.m.
Lol,
Thanks Daniel! I was concerned my art may get munged, I was using a mobile device to write
the original message and was kind of hoping it would have used a monospaced fonts.... go
windows phone.
Anyway, I've had a look at the change you've suggested, unfortunately it seems to
have made little difference and the RTP proxy is still trying to send traffic to the
client SIPPhones private ip address and not the firewall.
It's probably worth clarifying (seen as the diagram got mangled) that I don't
have an RTPproxy at our client site only in our data centre paid with our kamailio.
Here's another attempt at the diagram this looks like it's going in munged but
we'll see I guess:
-------------
-------| RTPproxy |------
--------- --------- | ------------- |
----------
|SIP Phone|--------|Firewall |---------internet-------------| kamailio
|-----------|Freeswitch|
--------- --------- -------------
----------
Any other suggestions?
-----Original Message-----
From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
On Behalf Of Daniel Tryba
Sent: 14 February 2014 09:45
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] FW: Client site NAT negotiation with no STUN.
On Friday 14 February 2014 10:18:07 Rob Moore wrote:
(please excuse the beautiful ASCI art)
You failed, it's not beatifull, it's a mess (be sure to use a monospaced font and
spaces when drawing ASCII art (since not all clients use monospaced to display it will
always fail in some clients)). See
http://lists.sip-router.org/pipermail/sr-users/2014-February/081601.html
for the result as I've seen your art :)
Can anyone suggest any other potential methods for
getting around this
problem?
I learned to never trust anything a client tells me in a SIP message, forcing all rtp
through the rtpproxy only leaves firewall issues at the client IMHO.
On an SBC kind of setup just always call rtpproxy_manage() regardless wheter you detect a
natted client.
In the "default" kamailio.conf just move rtpproxy_manage in the route[NATMANAGE]
to the beginning of the route (the f to use the local rtpproxy even if an other rtpproxy
is detected)
# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
rtpproxy_manage("f");
if (is_request()) {
....
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:24 p.m.
On Friday 14 February 2014 16:31:20 Rob Moore wrote:
Anyway, I've had a look at the change you've
suggested, unfortunately it
seems to have made little difference and the RTP proxy is still trying to
send traffic to the client SIPPhones private ip address and not the
firewall.
It's probably worth clarifying (seen as the diagram got mangled) that I
don't have an RTPproxy at our client site only in our data centre paid
with our kamailio.
Well, we have the same setup:
U 109.235.34.226:42259 -> 109.235.32.42:5060
INVITE sip:0880100705@pisco.pocos.nl SIP/2.0.
Via: SIP/2.0/UDP 10.0.3.175:5062;branch=z9hG4bK-54389de.
From: "tryba" <sip:tryba@pisco.pocos.nl>;tag=ea2052858ec448f9o2.
To: <sip:0880100705@pisco.pocos.nl>.
Call-ID: 20654a75-2dca31c9(a)10.0.3.175.
CSeq: 101 INVITE.
Max-Forwards: 70.
Contact: "tryba" <sip:tryba@10.0.3.175:5062>.
Expires: 240.
User-Agent: Linksys/SPA962-6.1.3(a).
Content-Length: 205.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Supported: replaces.
Content-Type: application/sdp.
.
v=0.
o=- 872251 872251 IN IP4 10.0.3.175.
s=-.
c=IN IP4 10.0.3.175.
t=0 0.
m=audio 16404 RTP/AVP 2 101.
a=rtpmap:2 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
...
U 109.235.32.42:5060 -> 109.235.34.226:42259
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
10.0.3.175:5062;rport=42259;received=109.235.34.226;branch=z9hG4bK-54389de.
Record-Route:
<sip:109.235.32.42;lr=on;ftag=ea2052858ec448f9o2;vsf=AAAAAF9BSFZRc0RZQ1NfHjAfChwQQUAcb2Nvcy5ubA--;nat=yes;vsf=Q2lwOnRyeWJhQHBpc2NvLnBvY29zLm5s;nat=yes>.
From: "tryba" <sip:tryba@pisco.pocos.nl>;tag=ea2052858ec448f9o2.
To: <sip:0880100705@pisco.pocos.nl>;tag=as15267783.
Call-ID: 20654a75-2dca31c9(a)10.0.3.175.
CSeq: 101 INVITE.
Server: Pocos.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces, timer.
Contact: <sip:+31880100705@109.235.32.xx>.
Content-Type: application/sdp.
Content-Length: 211.
.
v=0.
o=root 87313901 87313901 IN IP4 109.235.32.42.
s=Asterisk PBX 1.6.2.9-2+squeeze11.
c=IN IP4 109.235.32.42.
t=0 0.
m=audio 45940 RTP/AVP 2.
a=rtpmap:2 G726-32/8000.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.
The natted client will start the RTP stream towards 109.235.32.42:45940 and
after about 5-10 packets kamailio/rtpproxy will start sending to the source of
the incoming steam.
Attached a flow from an other test call.
As far as I know the only change I made was moving the rtpproxy_manage() a
bit.
Maybe I'll have some time monday to generate a small proof of concept config,
if nobody gives the answer before that time.
--
POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/ - http://www.sipo.nl/
K.v.K. Eindhoven 17097024
3934
days inactive
3934
days old
3 comments
2 participants
participants (2)
-
Daniel Tryba -
Rob Moore