Re: Moving forward with SDP control

It is relatively easier to generate an SDP where is needed rather than converting everything back and forth to SDP and wait for the other end-point to confirm each request. Using now SDP for describing media is like using a notifications bus that accepts only comma separated values format and you force high level structured objects to communicate over such bus. Or like using a DOS computer as a back to back user agent between two modern operating systems and wonder what is wrong with the network. No wonder the system breaks at every incremental step one tries to use it.

Adrian


On Jul 16, 2013, at 2:17 PM, 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 18:15:18 UTC