[sr-dev] Redesign of rtpproxy control protocol
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jun 5 09:43:42 CEST 2012
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
More information about the sr-dev
mailing list