[OpenSIPS-Users] Mediaproxy does not work with sipp

[Ruud Klaver]

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?

Ruud Klaver
AG Projects