[sr-dev] Redesign of rtpproxy control protocol

[Peter Lemenkov]

Hello All!
What a great email for this Friday night!

2012/6/1 Andreas Granig <agranig at 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.

-- 
With best regards, Peter Lemenkov.