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@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@172.16.230.1:61762;transport=udp>.
To: <sip:7171001@xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959@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@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@xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959@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?)


INVITE sip:7171001@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@172.16.230.1:61762;transport=udp>.
To: <sip:7171001@xxx.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959@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@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@xxx.connection-telecom.com>;tag=c601fd36.
To: <sip:7171001@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@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@xxx.connection-telecom.com>;tag=c601fd36.
To: <sip:7171001@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@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