Re: Moving forward with SDP control

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.

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.

Received on Tuesday, 16 July 2013 18:53:46 UTC