Hello All! What a great email for this Friday night!
2012/6/1 Andreas Granig agranig@sipwise.com:
Hi guys,
I've had a discussion with Daniel Mierla at Linuxtag last week, and we were talking about the future of rtpproxy and its control protocol.
The current state of affairs is that it has a number of mandatory parameters and a couple of trailing optional ones. Since the protocol relies on the position of the parameters, it's really difficult to add new ones because you somehow need to fill up the optional positions in between, which would cause quite some headache.
Yep, indeed. Things become quite complex nowadays - different codecs and transcoding, encryption, ipv6, STUN, etc. The great old rtpproxy protocol becomes less and less suitable for modern apps.
My proposal is to change the control protocol to some kind of key/value style format, which would allow to easily add such additions. A good way in my opinion would be to use an esablished format like JSON, so an rtpproxy request like this:
20477_10 USII mycallid;myviabranch 192.168.51.1 5016 myfromtag;1
would become something like this:
{ cookie:"20477_10", method:"update", flags:"SII", callid:"mycallid", viabranch:"myviabranch", ipv4addr:"192.168.51.1", port:"5016", fromtag:"myfromtag", streamnum:1}
The "flags" option could also be split up, and adding more parameters is straight-forward, so we're pretty flexible here.
From a reply perspective, it's also easier to pass back errors instead of the "0" port approach.
Any comments on that approach?
My personal opinion is that we should pass the entire SDP (wrapped into json perhaps) - codec mapping and their parameters, encryption keys, stun data - this all could be useful for the rtpproxy backend. Otherwise it looks good.