[sr-dev] Redesign of rtpproxy control protocol

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. For example, one thing we did for upcoming 3.3 was adding via branch to the call-id separated by a semi-colon and let the rtpproxy daemon parse it if it's capable to do so, which is a pretty hackish approach. Another thing we'd like to get into 3.4 is to let rtpproxy pass back media statistics in the response of a delete-command. 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? Andreas