Re: Moving forward with SDP control

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.
>
>