5 Jun
2012
5 Jun
'12
10:43 a.m.
Hello,
On 6/2/12 1:19 AM, Andreas Granig wrote:
Hi Peter,
On 06/01/2012 07:25 PM, Peter Lemenkov wrote:
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
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.