[sr-dev] Redesign of rtpproxy control protocol

[Andreas Granig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120601/1f7868db/attachment.pgp>