[OpenSIPS-Users] Mediaproxy does not work with sipp

[Giuseppe Roberti]

Hi.

Ruud Klaver wrote:
> Hi Giuseppe,
> 
> On 28 Oct 2008, at 16:42, Giuseppe Roberti wrote:
> 
>> Hi.
>>
>> I am trying to do a benchmark test of media relay, but it does not proxy
>> rtp flow from sipp client to sipp server, anyone know why ?
>>
>> sipp client (192.168.1.65) is started with:
>> sipp -sf uac_pcap -r 1 -rp 10s -i 192.168.1.65 192.168.1.70
>>
>> sipp server (192.168.1.67) is started with:
>> sipp -sn uas -i 192.168.1.67 -mi 192.168.1.67 -rtp_echo
>>
>> opensips (192.168.1.70) simple proxy invites from sipp client to sipp
>> server engaging mediaproxy on invite.
>>
>> here a log from media-relay:
>>
>> Starting MediaProxy Relay 2.1.0
>> Set resource limit for maximum open file descriptors to 11000
>> Adding new dispatcher at 192.168.1.70:25060
>> Connected to dispatcher at 192.168.1.70:25060
>> Received new SDP offer
>> mediaproxy.mediacontrol.StreamListenerProtocol starting on 50000
>> mediaproxy.mediacontrol.StreamListenerProtocol starting on 50001
>> mediaproxy.mediacontrol.StreamListenerProtocol starting on 50002
>> mediaproxy.mediacontrol.StreamListenerProtocol starting on 50003
>> Added new stream: (audio) 192.168.1.65:6000 (RTP: Unknown, RTCP:
>> Unknown) <-> 192.168.1.70:50000 <-> 192.168.1.70:50002 <-> Unknown (RTP:
>> Unknown, RTCP: Unknown)
>> created new session 1-20951 at 192.168.1.65: sipp at 192.168.1.65:5060
>> (20951SIPpTag091) --> service at 192.168.1.70:5060
>> updating existing session 1-20951 at 192.168.1.65: sipp at 192.168.1.65:5060
>> (20951SIPpTag091) --> service at 192.168.1.70:5060
>> Received updated SDP answer
>> Got initial answer from callee for stream: (audio) 192.168.1.65:6000
>> (RTP: Unknown, RTCP: Unknown) <-> 192.168.1.70:50000 <->
>> 192.168.1.70:50002 <-> 192.168.1.67:6000 (RTP: Unknown, RTCP: Unknown)
>> Got traffic information for stream: (audio) 192.168.1.65:6000 (RTP:
>> 192.168.1.65:6000, RTCP: Unknown) <-> 192.168.1.70:50000 <->
>> 192.168.1.70:50002 <-> 192.168.1.67:6000 (RTP: Unknown, RTCP: Unknown)
>> expired session 1-20951 at 192.168.1.65: sipp at 192.168.1.65:5060
>> (20951SIPpTag091) --> service at 192.168.1.70:5060
>> (Port 50000 Closed)
>> (Port 50001 Closed)
>> (Port 50002 Closed)
>> (Port 50003 Closed)
>>
>> Regards.
>> -- 
>> Giuseppe Roberti
>> <jnod at jnod.org>
> 
> The media-relay log indicates that the caller (the sipp client) did send 
> media to the relay, but the callee (the sipp server) never did. Because 
> the relay did not receive media from both ends and because you are using 
> a private IP range, the conntrack rule cannot be created and no media 
> can be relayed. If you would have been using a public IP range, the 
> relay would have already started sending the received UDP/RTP packets 
> from the caller to the callee through userspace. (This was implemented 
> because the relay was meant to run on a public IP, in which case already 
> relaying packets to a private IP makes no sense).
> 
> I have no experience in using sipp, but the "-rtp_echo" parameter 
> suggests to me that the sipp server simply sends the UDP/RTP packets 
> back to the ip/port that it received them from, without actually parsing 
> the SDP. A quick scan of the sipp manual confirms this:
> 
> "The "RTP echo" feature allows SIPp to listen to one or two local IP 
> address and port (specified using -mi and -mp command line parameters) 
> for RTP media. Everything that is received on this address/port is 
> echoed back to the sender."
> 
> This means that the sipp server never sent any UDP/RTP media to the 
> relay, so the connntrack rule cannot be created and nothing is relayed. 
> Probably if you put the sipp server on a public IP the packets will be 
> relayed and echoed back to the correct port on the relay. Could you try 
> this out?

Yes. You are right.
Using a public ip address (or deleting private ip from 
/usr/lib/python2.5/site-packages/mediaproxy/iputils.py) works fine.
Thanks.

> 
> Ruud Klaver
> AG Projects
> 

-- 
Giuseppe Roberti
<jnod at jnod.org>