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