19 Dec
2012
19 Dec
'12
11:34 a.m.
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?
-- juha
19 Dec
19 Dec
11:49 a.m.
Hi Juha,
On 12/19/2012 11:34 AM, Juha Heinanen wrote:
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?
Well, yes, we're going to define a new control protocol for
mediaproxy-ng (hopefully in consensus with someone willing to pick up
rtpproxy changes - the Crocodile RCS guys have mentioned to have plans
for that as well) to pass the full SDP body to the media relay, and
receive a full SDP body in return, so the logic would then be placed in
the media relay instead of the kamailio module.
Step 2 then is to implement ICE and ICE-breaking in mediaproxy-ng.
Timeline for that is Q1/2013.
Andreas
12:28 p.m.
2012/12/19 Juha Heinanen <jh(a)tutpro.com>om>:
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.
--
With best regards, Peter Lemenkov.
2 Jan
2 Jan
7:14 p.m.
New subject: erlrtpproxy (was: Re: ice support in media/rtp proxy)
Am 19.12.2012 12:28, schrieb Peter Lemenkov:
2012/12/19 Juha Heinanen <jh(a)tutpro.com>om>:
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
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. 
3 Jan
3 Jan
1:54 a.m.
New subject: erlrtpproxy (was: Re: ice support in media/rtp proxy)
+1 what is erlrtproxy?
(Other then assuming its an Erlang port of rtpproxy)
On Jan 2, 2013 1:14 PM, "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
wrote:
Am 19.12.2012 12:28, schrieb Peter Lemenkov:
2012/12/19 Juha Heinanen <jh(a)tutpro.com>om>:
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
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
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.
5 Jan
5 Jan
9:38 a.m.
New subject: erlrtpproxy (was: Re: ice support in media/rtp proxy)
Hello All!
2013/1/2 Klaus Darilion <klaus.mailinglists(a)pernau.at>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.…
- 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.
--
With best regards, Peter Lemenkov.
4129
days inactive
4146
days old
5 comments
5 participants
participants (5)
-
Andreas Granig -
David J -
Juha Heinanen -
Klaus Darilion -
Peter Lemenkov