[SR-Users] udp transport in rtpproxy sockets

Andreas Granig agranig at sipwise.com
Mon Oct 22 12:10:57 CEST 2012


Hi Juha,

On 10/22/2012 09:50 AM, Juha Heinanen wrote:
> Definition of socket(s) used to connect to (a set) RTPProxy. It may
> specify a UNIX socket or an IPv4/IPv6 UDP socket.
> 
> if that is the case, what is the justification for it, i.e, why is tcp
> (and better yet tls) transport not supported?

I fully agree that TCP (as a first step) should be a good improvement.
We've already briefly talked about redesigning the overall rtpproxy
control protocol some time ago, but we haven't had the time yet to start
with it, however we've it on our list for December.

The idea is to switch to TCP, and to pass on the whole SDP body to the
rtp proxy, along with a more flexible way to pass parameters back and
forth (e.g. passing back RTP stats in the response of a delete-message).
The protocol will be something like json or bencode. Letting the rtp
proxy analyze the full SDP body and pass back a full SDP body in return
will allow us to do advanced stuff like RTP/AVP to RTP/SAVPF conversion
and ICE handling, beside SRTP transcoding etc.

I'm aware that this goes against the ideal world of end-to-end media
negotiation, but let's be pragmatic here. We know it's not realistic to
have all SIP clients updated and play nice in a reasonable time frame,
and the only other alternative is putting an Asterisk (trunk version) or
a similar application server in between, which is not necessary.

Most likely we're going to start with forking the rtpproxy module in a
separate feature branch, do a proof-of-concept implementation and
preferably merge it back to trunk rtpproxy module once all 3 media
proxies (rtpproxy, iptrtpproxy, mediaproxy-ng) are supporting this protocol.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121022/7c1755ed/attachment.pgp>


More information about the sr-users mailing list