Re: Moving forward with SDP control

The JSEP spec is supposed to list what manipulations are permissible.

That seems to be a work in progress...

-Ekr



On Wed, Jul 17, 2013 at 9:04 AM, Peter Thatcher <pthatcher@google.com>wrote:

>
>
>
> On Tue, Jul 16, 2013 at 11:53 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> On 16 July 2013 05:17, Harald Alvestrand <harald@alvestrand.no> wrote:
>> > 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.
>>
>> This process might be made more feasible if there was a specification
>> that identified exactly what SDP browsers are required to:
>> a) produce - given a set of stream inputs, what are the set of SDP
>> offers a browser can legally produce; given an offer, plus a set of
>> stream inputs, what are the set of SDP answers a browser can legally
>> produce; and
>> b) consume - given a certain starting state, what SDP offers or
>> answers is a browser required to accept and what actions do those
>> documents induce.
>>
>> This should, at least initially, be a very constrained specification.
>> (I believe that is what Roman is stating.)  In fact, this could go so
>> far as to categorically state that the input to setLocalDescription()
>> is precisely the output of createOffer or createAnswer.
>>
>
> That's equivalent to saying the browser should reject calls to
> setLocalDescription that have mangled SDP.  But some browsers already
> accept mangling of SDP before calling setLocalDescription.  What if WebRTC
> apps already rely on that?  Would the spec require breaking such apps?
>
>
>>
>> Once that is sorted out, your process for enabling a range of use
>> cases makes sense.  Until that specification exists, I don't see a way
>> to get anything other than what you describe: a piecemeal approach.
>> It's not like Justin and Cullen haven't already tried to cover the set
>> of use cases.  The JSEP draft has had a list of them for ages, but
>> there has been no real attempt on the W3C side to address those cases.
>>
>> I'm just speculating, but I suspect that there is some reluctance to
>> explore solutions when the foundation in SDP is still quite nebulous.
>> Maybe that will change when (if?) MMUSIC decides on a plan, but I
>> suspect that plan will first need to be enacted before you will see
>> any movement.  I have no objection to doing a little groundwork now,
>> but I find that talking about requirements only gets you so far.
>>
>>
>