[sr-dev] erlrtpproxy (was: Re: ice support in media/rtp proxy)

[Peter Lemenkov]

Hello All!

2013/1/2 Klaus Darilion <klaus.mailinglists at pernau.at>:

> I just heard of erlrtpproxy for the first time. There is pretty no
> documentation in github. Is it comatible with rtpproxy. Are there any
> advantages over rtpproxy?
>
> I would be cool of you can shortly present erlrtpproxy to the Kamailio
> users.

I recently picked up my old attempt (which was in a quite good state
already) to rewrite a venerable RTPproxy in Erlang. Right now it still
in a w.i.p. although I'm using it personally in a two installations.

* https://github.com/lemenkov/erlrtpproxy

What I've done so far is:

* Basic offer/answer works.
* Call recording works
* Music-on-hold works.
* Transcoding from/to G.711 / G.721 / G.722 / G.723 / G.726 / G.729
(annex A only, annex B VAD frames currently skipped) / GSM / iLBC /
Opus / SPEEX. I made the first version to be compatible with a very
old Erlang so it works sub-optimally on a more recent Erlang versions
(speaking more positively this means I have a room for improvements).
* OpenSER-style timeout notifications via IPv4/IPv6 UDP/TCP (configurable)
* RADIUS notifications (start / interim update / stop, configurable)
* Control socket (22222 by default) using IPv4/IPv6 UDP/TCP (configurable)
* Events logging (start, stop, interim update, timeout, codec/parser
error) to syslog (with full RTCP pretty printing)
* WebRTC-style RTP/RTCP muxing/demuxing from/to two independent
channels (automatically)
* Setting some internal parameters via HTTP-JSON interface.
* IPv4/IPv6 bridging for RTP/RTCP
* JSON stats retrieval via HTTP (currently supporting queries like
http://localhost:8442/json/?callid=0003e30c-c50c0134-763a6f53-359481cc@192.168.0.100&payload=0
- available parameters are - payload, callid, mediaid, tag, remote IP)

{"http_query":{"callid":"0003e30c-c50c0134-763a6f53-359481cc at 192.168.0.100","payload":"0"},"result":{"media":{"callid":"0003e30c-c50c0134-763a6f53-359481cc at 192.168.0.100","mediaid":"1","tag":"0003e30cc50c5d43416d30b4-7b2f969c","payload":0,"rxbytes":108008800,"rxpackets":677772,"txbytes":108262240,"txpackets":676639,"local":{"ip":"192.168.1.233","rtp":50486,"rtcp":50487},"remote":{"ip":"192.168.5.1","rtp":5038,"rtcp":5039}},"media":{"callid":"0003e30c-c50c0134-763a6f53-359481cc at 192.168.0.100","mediaid":"1","tag":"2e268de3","payload":0,"rxbytes":108262240,"rxpackets":676639,"txbytes":108008800,"txpackets":677772,"local":{"ip":"192.168.1.233","rtp":34732,"rtcp":34733},"remote":{"ip":"192.168.5.10","rtp":20912,"rtcp":null}}}}

In progress

* A completely new JSON-based command protocol.
* Multiple networks bridging (more than just three - internal, external, ipv6).
* STUN/TURN/ICE.
* More stats and more query options (for example, select all calls
from/to a given country, using GeoIP)
* SRTP / ZRTP (almost there - I put them on hold for now) and a
gateway SRTP<->RTP
* Video with transcoding.
* Full WebRTC media support.
* CEE logging.
* Stream copying to a given IP:Port (actually I'm not sure that I'm
going to implement this feature).

I won't plan to add:

* Transcoding offloading using dedicated hardware. I just don't have
any hardware available.
* In-kernel routing (like iptrtpproxy, mediaproxy did).

Since I'm using Erlang I've got for free a lot of good stuff -
clustering, fault tolerance, restarts in case of failures, almost
linear scalability, etc. It has few disadvantages as well. Most
notable one - Erlang isn't a very friendly thing especially when it
comes to the installation. I'm working on improving this.

Regarding performance - ~1000 concurrent calls with G.711 codec and
without transcoding costs ~500% utilization of a 8-core 32-bit x86
2GHz CPU which isn't a very good but I'm working on the improvement.

-- 
With best regards, Peter Lemenkov.