How RTPproxy work for OpenSER SIP Proxy

                       How RTPproxy work for OpenSER SIP Proxy

this article is from http://blog.csdn.net/chang_jiang_110/article/details/2946117

About RTPproxy

The RTPproxy is a high-performance software proxy for RTP streams that can work together with SER,OpenSER or Sippy B2BUA. Originally created for handling NATscenarious it can also act as a generic media relay as well as gatewayRTP sessions between IPv4 and IPv6 networks. RTPproxy was developed byMaxim Sobolev and now is being actively maintained by the Sippy Software, Inc..

The RTPproxy supports some advanced features, such as remote control mode,allowing building scalable distributed SIP VoIP networks. The nathelper module included into the SER or OpenSER SIP Proxy software as well as Sippy B2BUA allows using multiple RTPproxy instances running on remote machines for fault-tolerance and load-balancing purposes.

The software also supports video relaying and RTP session recording.

How it works

This RTPproxy works as follows:

• When SIP Proxy receives INVITE request, it extracts call-id from it and communicates it to the proxy via Unix domain socket. RTPProxy looks for an existing sessions withsuch id, if the session exists it returns UDP port for that session, ifnot, then it creates a new session, binds to a first empty UDP portfrom the range specified at the compile time and returns number of thatport to a SIP Proxy. After receiving reply from the proxy, SIP Proxy replaces media ip:port in the SDP to point to the proxy and forwardsthe request as usual;

 

• when SIP Proxy receives non-negative SIP reply with SDP it again extracts call-id from it and communicates it to the proxy. In this casethe proxy does not allocate a new session if it doesn't exist, butsimply performs a lookup among existing sessions and returns either aport number if the session is found, or error code indicating that there is no session with such id. After receiving positive reply fromthe RTPproxy, SIP Proxy replaces media ip:port in the SIP Proxy reply to point to the proxy and forwards reply as usual;

 

• after the session has been created, the proxy listens on the port it has allocated for that session and waits to receive at least one UDP packet from each of the two parties participating in the call. Once these packet are received, the proxy fills one of two ip:port structures associated with each call with the source ip:port of that packet. When both structures are filled in, the proxy starts relayingUDP packets between parties;

 

• the proxy tracks idle time for each of existing sessions (i.e. thetime within which there were no packets relayed), and automatically cleans up a sessions whose idle times exceed the value specified atcompile time (60 seconds by default).

 

Performance

It should be able to handle up to 2,000 simulateneous G.729 sessions on a decent machine (P4 2.5-3.0 GHz). Please note that fine-tuning of OS network stack parameters can be necessary to get such high numbers, since RTP traffic consists of big number of very shortUDP frames (up to 30 frames/sec for one session), so that network stack should be prepared to handle huge number of short packets.

Getting RTPproxy

        cvs -d:pserver:[e-mail]:/cvsroot/ser login
        press enter when prompted for a password
        cvs -z3 -d:pserver:[e-mail]:/cvsroot/ser co rtpproxy
        then do the usual: ./configure; make; make install

Compatibility

Your client must support symmetric RTP for rtpproxy to work. It must send and receive media on the same port - that's the only way to make media to cross the NAT. Most of the clients available today do support symmetric RTP, though.

Support

Community-based support could be obtained via SER mailing lists mailto:[e-mail].

Commercial support is available from the Sippy Software, Inc..