W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 17 Jul 2013 09:09:28 +0800
Message-ID: <CABcZeBPW-esj0ecV7hptFTf0K5iO42v__HeHEWProBgbT4LbLQ@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
The JSEP spec is supposed to list what manipulations are permissible.

That seems to be a work in progress...


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.
Received on Wednesday, 17 July 2013 01:10:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC