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
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.
Hi Peter,
On 06/01/2012 07:25 PM, Peter Lemenkov wrote:
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.
When taking into account all kinds of use-cases like ICE handling between ICE/non-ICE clients and srtp bridging for webrtc, as well as transcoding for "normal" clients, it makes sense to pass the full SDP body to the rtpproxy and expecting a full SDP body back in response.
Maybe some basic wrapping which includes generic and SIP specific values (like the cookie, call-id, tags, branches, IPv4/IPv6 bridging etc) as well as the full SDP for a request, and for responses a status and again the full SDP would be sufficient.
That way, we'd get also get rid of certain flags in the rtpproxy module.
Andreas
Hi,
just an idea: Why not look at MGCP or Megaco/H.248 to control the RTP-Proxy? Might be interesting, since you could use Kamailio as a Client for other cases, such as Announcement-Servers or PSTN Termination.... This needs more investigation, i know, and it's way more complicated, but maybe worth the effort; i don't know. Just an idea.
Carsten
2012/6/2 Andreas Granig agranig@sipwise.com:
Hi Peter,
On 06/01/2012 07:25 PM, Peter Lemenkov wrote:
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.
When taking into account all kinds of use-cases like ICE handling between ICE/non-ICE clients and srtp bridging for webrtc, as well as transcoding for "normal" clients, it makes sense to pass the full SDP body to the rtpproxy and expecting a full SDP body back in response.
Maybe some basic wrapping which includes generic and SIP specific values (like the cookie, call-id, tags, branches, IPv4/IPv6 bridging etc) as well as the full SDP for a request, and for responses a status and again the full SDP would be sufficient.
That way, we'd get also get rid of certain flags in the rtpproxy module.
Andreas
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 6/2/12 1:19 AM, Andreas Granig wrote:
Hi Peter,
On 06/01/2012 07:25 PM, Peter Lemenkov wrote:
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.
When taking into account all kinds of use-cases like ICE handling between ICE/non-ICE clients and srtp bridging for webrtc, as well as transcoding for "normal" clients, it makes sense to pass the full SDP body to the rtpproxy and expecting a full SDP body back in response.
Maybe some basic wrapping which includes generic and SIP specific values (like the cookie, call-id, tags, branches, IPv4/IPv6 bridging etc) as well as the full SDP for a request, and for responses a status and again the full SDP would be sufficient.
That way, we'd get also get rid of certain flags in the rtpproxy module.
but then these flags have to be given as options to rtpproxy (command line or config) -- it will not be that flexible for a per-session control.
Transferring the whole and only sdp, will require quite some development in the rtpproxy (including a full sdp parser), my opinion would be a more gradual approach, first just have current control protocol re-implemented in a more flexible and extensible packaging mechanism (I prefer also json). The start enhancing it, eventually getting to the stage where using only the sdp will be enough. I am thinking from development and testing point of view. If anyone has resources to implement in one step, pretty much from scratch everything, all is fine. Otherwise, small changes are easier to do and to test.
Anyhow, perhaps we should go with a new module (e.g., rtpproxy-ng) in the first phase, keeping the old one for a while as well.
Cheers, Daniel
-
Andreas Granig -
Carsten Bock -
Daniel-Constantin Mierla -
Peter Lemenkov