Am 19.12.2012 12:28, schrieb Peter Lemenkov:

2012/12/19 Juha Heinanen jh@tutpro.com:

...

ice seems to be at least in theory supported by several sip clients: baresip, csipsimple, pjsip based clients, etc.

one of the problems of ice is that is uses turn protocol to find ip addresses/ports of relays in case end-to-end connectivity cannot be established otherwise. turn server, on the other hand, must authenticates its clients. this doubles authentication work and, worse, a single turn server does not seem to be able to handle more than one domain. having each domain its own turn server is clearly not a scalable solution. so life would be easier without turn servers.

mediaproxy module has solved this problem so that it adds the ice relay candidates to sdp on behalf of ice clients and therefore no separate turn servers nor turn client authentication are needed.

have people who have worked on rtpproxy or mediaproxy-ng considered supporting ice in the way mediaproxy modules does today? any other thoughts about this?

I plan to add STUN/TURN directly into erlrtpproxy. And yes, this definitely needs a completely new protocol, JSON-based.

Hi Peter!

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.

Thanks Klaus

Hello All!

2013/1/2 Klaus Darilion klaus.mailinglists@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.1... - available parameters are - payload, callid, mediaid, tag, remote IP)

{"http_query":{"callid":"0003e30c-c50c0134-763a6f53-359481cc@192.168.0.100","payload":"0"},"result":{"media":{"callid":"0003e30c-c50c0134-763a6f53-359481cc@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@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.