Re: Moving forward with SDP control

     Makes sense to me, though I believe you need to address the other 
(separate) proposal of replacing the offer/answer mechanism. I think in 
the latter case we need to ask ourselves: what use-cases require us to 
use offer/answer, and what use-cases require us to replace it? I don't 
think this has been well-understood to date.

Thanks,
Gili

On 16/07/2013 8:17 AM, Harald Alvestrand wrote:
> Hi all,
>
> Recently there has been a lot of discussion (primarily in the 
> IETF/rtcweb space though, but this topic really belongs here) about 
> the desire to meet most use-cases without having to parse, modify or 
> construct SDP.
> This was discussed already as part of the discussion on whether 
> PeerConnection and SDP should be maintained or not last year [1].
>
> In the meantime, a number of API extensions have been created, notably 
> the constraints setting and modification interfaces, which seem likely 
> to be useful in achieving the goals people seek to achieve by SDP 
> mangling.
>
> However, this work has not progressed very quickly, or very 
> comprehensively.
> It may be time for a more structured approach.
>
> We think it makes sense to divide the information needed into 
> subcategories:
>
> * Define the use cases for which SDP mangling is currently thought to 
> be required - the "why" of the SDP tweaking.
>
> * Propose what parameters one should be able to control/influence 
> without having to do SDP mangling. A proposal should describe what the 
> current API specification produces, what the needed mangling is, and 
> what the desired effect of the mangling is - the "what" of the SDP 
> tweaking.
>
> * Propose suitable API surfaces to control/influence how media is 
> encoded and transported over the network - the "how" of the SDP 
> tweaking. We think that a requirement should be that working 
> applications do not break when adding this surface - if it is not used 
> things should work as today.
>
> Someone may make a proposal encompassing all 3 pieces of information 
> (why, what and how) - or just some of the first ones - or a proposal 
> for a latter one that builds upon others' proposals (a "how" building 
> on someone else's "why" and "what"). But we would not want to consider 
> a "how" without a "what", or a "what" without a "why" - it just 
> becomes impossible to figure out whether the original requirement is 
> satisfied if we don't build all 3 layers of the proposals.
>
> Does this sound like a way we could move forward?
>
> Harald for the chairs.
>
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html
>

Received on Tuesday, 16 July 2013 16:06:34 UTC