Repository files navigation

The RTPproxy is a extremely reliable and reasonably high-performance softwareproxy for RTP streams that can work together withOpenSIPS,Kamailio orSippy B2BUA.

Originally created for handling NAT scenarios, back in 2004-2005, it can also actas a generic real time datagram relay as well as gateway Real-Time Protocol (RTP)sessions between IPv4 and IPv6 networks.

The RTPproxy supports many advanced features and is controllable overmultitude of Layer 4 protocols, including Unix Domain, UDP, UDPv6, TCP and TCPv6.

The software allows building scalable distributed SIP networks. The rtpproxy moduleincluded into the OpenSIPS or Kamailio SIP Proxy software allows using multipleRTPproxy instances running on remote machines for fault-tolerance andload-balancing purposes.

Advanced high-capacity clustering and load balancing is available through theuse ofRTP Cluster middleware.

The software also supports MOH/pre-recorded media injection, video relayingand session recording to a local file or remote UDP listener(s). As wellas makes available array of real-time or near real-time session counters,both per-session and per-instance.

Since version 3.1.0, full set of extensions is available allowing to createa WebRTC-compatible endpoints.

• introducing WebRTC/WSS clients support via 3 new modules: dtls_gw, ice_liteand rtcp_demux.

This proxy works as follows:

• When SIP Controller, either proxy or B2BUA, receives INVITE request, itextracts call-id from it and communicates it to the proxy via controlchannel. Proxy looks for an existing sessions with such id, if the sessionexists it returns UDP port for that session, if not, then it creates a newsession, binds to a first available randomly selected pair of UDP ports andreturns number of the first port. After receiving reply from the proxy, SIPController replaces media ip:port in the SDP to point to the proxy andforwards request as usually;

• when SIP Controller receives non-negative SIP reply with SDP it againextracts call-id along with session tags from it and communicates it tothe proxy. In this case the proxy does not allocate a new session if itdoesn't exist, but simply performs a lookup among existing sessions andreturns either a port number if the session is found, or error codeindicating that there is no session with such id. After receiving positivereply from the proxy, SIP Controller replaces media ip:port in the SIPreply to point to the proxy and forwards reply as usually;

• after the session has been created, the proxy listens on the port it hasallocated for that session and waits for receiving at least one UDPpacket from each of two parties participating in the call. Once suchpacket is received, the proxy fills one of two ip:port structuresassociated with each call with source ip:port of that packet. When bothstructures are filled in, the proxy starts relaying UDP packets betweenparties;

• the proxy tracks idle time for each of existing sessions (i.e. the timewithin which there were no packets relayed), and automatically cleansup a sessions whose idle times exceed the value specified at compiletime (60 seconds by default).

$ git clone -b master https://github.com/sippy/rtpproxy.git$ git -C rtpproxy submodule update --init --recursive$ cd rtpproxy$ ./configure$ make

The RTPproxy has been designed by Maxim Sobolev and now is being activelymaintained by theSippy Software, Inc. With thegreat help of numerous community contributors, both private and institutional.Not to mention army of robots gracefully dispatched at need by CI.

The original idea has inspired and directly influenced multitude of independentimplementations, including but not limited to theMediaproxy,erlrtpproxy, and most recentlyRTP Engine, each project focusing onits own area of the vast functionality space.

• User Manual;
• RTPproxy Control Protocol Reference.

Open a ticket on the github issue tracker, or post a message on themailinglist