[OpenSIPS-Users] Mediaproxy does not work with sipp

Giuseppe Roberti jnod at jnod.org
Sun Nov 2 23:14:47 CET 2008


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 ( is started with:
>> sipp -sf uac_pcap -r 1 -rp 10s -i
>> sipp server ( is started with:
>> sipp -sn uas -i -mi -rtp_echo
>> opensips ( 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
>> Connected to dispatcher at
>> 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) (RTP: Unknown, RTCP:
>> Unknown) <-> <-> <-> Unknown (RTP:
>> Unknown, RTCP: Unknown)
>> created new session 1-20951 at sipp at
>> (20951SIPpTag091) --> service at
>> updating existing session 1-20951 at sipp at
>> (20951SIPpTag091) --> service at
>> Received updated SDP answer
>> Got initial answer from callee for stream: (audio)
>> (RTP: Unknown, RTCP: Unknown) <-> <->
>> <-> (RTP: Unknown, RTCP: Unknown)
>> Got traffic information for stream: (audio) (RTP:
>>, RTCP: Unknown) <-> <->
>> <-> (RTP: Unknown, RTCP: Unknown)
>> expired session 1-20951 at sipp at
>> (20951SIPpTag091) --> service at
>> (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.

> Ruud Klaver
> AG Projects

Giuseppe Roberti
<jnod at jnod.org>

More information about the Users mailing list