[SR-Users] Kamailio / rtpproxy behaviour on dual-homed box

Fri Aug 16 16:29:36 CEST 2013

Hi all,

I have a fresh install of Kamailio 4.0.3 - built from source - and
rtpproxy, version:

Basic version: 20040107
Extension 20050322: Support for multiple RTP streams and MOH
Extension 20060704: Support for extra parameter in the V command
Extension 20071116: Support for RTP re-packetization
Extension 20071218: Support for forking (copying) RTP stream
Extension 20080403: Support for RTP statistics querying
Extension 20081102: Support for setting codecs in the update/lookup command
Extension 20081224: Support for session timeout notifications

My system is Ubuntu 13.04.

My box is dual homed - eth0 is 10.64.5.16/24, eth1 is 172.16.230.128/24

My rtpproxy command line is:

/usr/sbin/rtpproxy -s udp:127.0.0.1:7722 -u rtpproxy:rtpproxy -p
/var/run/rtpproxy/rtpproxy.pid -l 172.16.230.128/10.64.5.16

My Kamalio config is "out of the box", except that I defined "WITH_NAT",
added "mhomed=1" and added a couple of aliases.

I have a soft phone running on another box.  Also dual homed on 10.64.5.146
and 172.16.230.1.

The soft phone is configured to register to a server that is here called "
xxx.connection-telecom.com".   That server is an OpenSIPs instance with
Asterisk behind it.  No rtpproxy on that side, but nathelper is used.

There is no NAT between the 10.64.5.0/24 network and the
xxx.connection-telecom.com server.
>From xxx.connection-telecom.com 172.16.230.0/24 cannot be reached.

The soft phone uses 172.16.230.128 as its outbound proxy.

The idea is to test outbound calling from the soft phone via
Kamailio/RTPProxy.  I'm expecting "bridge mode" - IE for rtp to get passed
through rtpproxy, passing the RTP between the two interfaces.

What I actually get is one way audio - audio from 172.16.230.1 gets to
xxx.connection-telecom.com; audio back does not.
Also, the call drops after 30 seconds.

I'll pick up the trace with the authenticated INVITE from the phone:

So here is the invite from the phone:

U 172.16.230.1:61762 -> 172.16.230.128:5060
INVITE sip:7171001 at xxx.connection-telecom.com;transport=udp SIP/2.0.
Via: SIP/2.0/UDP 172.16.230.1:61762
;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:2686959 at 172.16.230.1:61762;transport=udp>.
To: <sip:7171001 at xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959 at xxx.connection-telecom.com>;tag=c601fd36.
Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU.
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
Content-Type: application/sdp.
Proxy-Authorization: Digest username="2686959",realm="
xxx.connection-telecom.com
",nonce="520e1e50ef047461c3b0dbc731ccdc19e99990ce",uri="
sip:7171001 at xxx.connection-telecom.com
;transport=udp",response="yyyyyyy",algorithm=MD5.
Supported: replaces.
User-Agent: Bria 3 release 3.5.3 stamp 70600.
Content-Length: 256.
.
v=0.
o=- 1376656946792420 1 IN IP4 172.16.230.1.
s=Bria 3 release 3.5.3 stamp 70600.
c=IN IP4 172.16.230.1.
t=0 0.
m=audio 59984 RTP/AVP 8 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=yes.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.

"Trying" from Kamailio:

#
U 172.16.230.128:5060 -> 172.16.230.1:61762
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.230.1:61762
;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762.
To: <sip:7171001 at xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959 at xxx.connection-telecom.com>;tag=c601fd36.
Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU.
CSeq: 2 INVITE.
Server: kamailio (4.0.3 (i386/linux)).
Content-Length: 0.

Here's what Kamailio sent to the remote server.

* The from address is set to the eth0 interface address thanks to mhomed=1
(without that it uses the 172.16 address)
* But In sdp, wrong address is used.  It is changed to "our" address, but
our address on the eth1 interface.
  Surely since we are talking on the eth0 side, 10.64.5.16 should have been
used?
* Contact is not changed (not sure if it should be?)

U 10.64.5.16:5060 -> 41.000.000.60:5060
INVITE sip:7171001 at xxx.connection-telecom.com;transport=udp SIP/2.0.
Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>.
Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>.
Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK9b0c.951b94b1.0.
Via: SIP/2.0/UDP 172.16.230.1:61762
;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762.
Max-Forwards: 16.
Contact: <sip:2686959 at 172.16.230.1:61762;transport=udp>.
To: <sip:7171001 at xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959 at xxx.connection-telecom.com>;tag=c601fd36.
Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU.
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
Content-Type: application/sdp.
Proxy-Authorization: Digest username="2686959",realm="
xxx.connection-telecom.com
",nonce="520e1e50ef047461c3b0dbc731ccdc19e99990ce",uri="
sip:7171001 at xxx.connection-telecom.com
;transport=udp",response="yyyyyyy",algorithm=MD5.
Supported: replaces.
User-Agent: Bria 3 release 3.5.3 stamp 70600.
Content-Length: 278.
P-hint: outbound.
.
v=0.
o=- 1376656946792420 1 IN IP4 172.16.230.128.
s=Bria 3 release 3.5.3 stamp 70600.
c=IN IP4 172.16.230.128.
t=0 0.
m=audio 44320 RTP/AVP 8 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=yes.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=nortpproxy:yes.

U 41.000.000.60:5060 -> 10.64.5.16:5060
SIP/2.0 100 Giving a try.
<detail skipped>

U 41.000.000.60:5060 -> 10.64.5.16:5060
SIP/2.0 180 Ringing.
<detail skipped>

OK comes back:

U 41.000.000.60:5060 -> 10.64.5.16:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
10.64.5.16;rport=5060;received=10.64.5.16;branch=z9hG4bK9b0c.951b94b1.0.
Via: SIP/2.0/UDP 172.16.230.1:61762
;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762.
Record-Route: <sip:41.000.000.60;lr=on;ftag=c601fd36>.
Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>.
Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>.
From: "vc2 2686959"<sip:2686959 at xxx.connection-telecom.com>;tag=c601fd36.
To: <sip:7171001 at xxx.connection-telecom.com>;tag=as2a8e6d98.
Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU.
CSeq: 2 INVITE.
Server: Enswitch.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Contact: <sip:7171001 at 41.000.000.60:5070>.
Content-Type: application/sdp.
Content-Length: 306.
.
v=0.
o=root 1056055966 1056055966 IN IP4 41.000.000.60.
s=Asterisk PBX 1.8.12.2.
c=IN IP4 41.000.000.60.
t=0 0.
m=audio 18130 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
a=direction:active.

Sent on to phone, this one correctly munged.

U 172.16.230.128:5060 -> 172.16.230.1:61762
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 172.16.230.1:61762
;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762.
Record-Route: <sip:41.000.000.60;lr=on;ftag=c601fd36>.
Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>.
Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>.
From: "vc2 2686959"<sip:2686959 at xxx.connection-telecom.com>;tag=c601fd36.
To: <sip:7171001 at xxx.connection-telecom.com>;tag=as2a8e6d98.
Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU.
CSeq: 2 INVITE.
Server: Enswitch.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH.
Supported: replaces, timer.
Contact: <sip:7171001 at 41.000.000.60:5070>.
Content-Type: application/sdp.
Content-Length: 326.
.
v=0.
o=root 1056055966 1056055966 IN IP4 172.16.230.128.
s=Asterisk PBX 1.8.12.2.
c=IN IP4 172.16.230.128.
t=0 0.
m=audio 41166 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
a=direction:active.
a=nortpproxy:yes.

Watching the RTP flows, on the eth1 (internal) side I can see a flow from
172.16.230.1 (the phone) to 172.16.230.128 (the rtpproxy), but no flow back.

On the eth0 side, I see a flow out from 172.16.230.128 going to my
xxx.connection-telecom.com box.  Wrong source address but it does get there
and can be heard.
There is no return flow.

Most likely the Asterisk behind the opensips is sending audio to
172.16.230.128 since that is where it is getting audio from (i.e. Asterisk
nat=yes).

How to get the right address in the sdp of the outgoing invite?

Thanks,
Steve Davies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130816/60fb8ec5/attachment-0001.html>