rtpproxy module readme gives impression that udp transport is the only possibility:
4.1. rtpproxy_sock (string)
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?
-- juha
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
Andreas Granig writes:
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.
ok, good to hear.
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.
it may never happen that all different rtpproxies support a new protocol. better to introduce new rtpproxy-ng module once you have the new protocol up and running.
-- juha
On 22.10.2012 09:50, Juha Heinanen wrote:
rtpproxy module readme gives impression that udp transport is the only possibility:
4.1. rtpproxy_sock (string)
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?
Probably because nobody implemented it yet - and SIP proxy and rtpproxy are usually "close" to each other. If you need communication via the Internet (e.g. for remote RTP proxies) you could IPsec as a workaround.
regards Klaus
-
Andreas Granig -
Juha Heinanen -
Klaus Darilion