Re: Moving forward with SDP control

On 7/16/13 8:55 PM, Martin Thomson 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.

I agree that this should be very constrained set, and perhaps it should 
initially just be the output of "createOffer/Answer" that is allowed.

Received on Thursday, 18 July 2013 06:39:31 UTC