Re: Moving forward with SDP control

This flexibility and lack of details for what must be supported for SDP 
control is one of the reasons largest challenges ahead. There is no 
clear definition of what exact feature sets must be supported exclusive 
to the RTC engine without a lot of "hand waving" saying "whatever SDP 
does" for compatibility. That's not good enough to finish 1.0, let alone 
be able to come up with a reasonable 2.0 non-SDP based alternative that 
covers 1.0 features.

See this draft for example a ton of SDP features that could be supported:
http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-03

This SDP settings list can be grouped into several categories:
1) attributes needed by RTP engine for control / constraints / stream / 
track definition and mappings
2) attributes needed to specify compatibility between other non-WebRTC 
RTC engines
3) attributes that are legacy and do not need definition at all
4) attributes that have no value to a browser's RTC engine, but might to 
a higher layer above
5) attributes that could be respected by an browser's RTC engine, but 
could also be performed by a higher layer
6) attributes that are extensions that might have value to RTC engine, 
but only in some future version

So to address each types:
1) These attributes are the real mandatory attributes and define the 
minimum required feature set for 1.0. Examples: codec attributes, 
payload mappings, SSRCs and track / stream groupings, and transport 
information.
2) The exact RTC engine feature for mandate support and optional support 
needs to be defined for various extensions that currently exist. 
Example: "rtcp-rsize".
3) What happens to these attributes if they are sent into an engine? 
Example: "mbms-repair"
4) If you need/want these attributes, you'll have to parse the SDP from 
JS, or ask the browsers to expose an API for you. Example: "label"
5) The responsibility for who should/could respond to these kind of 
attributes is unclear for SDP. Example "t" or 'floor control' SDP 
attributes.
6) Each of these needs to be road mapped now vs later.


Not only is it going to take an enormous amount of time to define the 
exact SDP attributes needed but it will introduce ambiguities for what 
should be implemented inside the RTC engine (vs JS). To that end, what 
should be exposed for easier SDP handling (to prevent mangling -- even 
if they aren't truly needed by the RTC engine)? Where is the division of 
responsibility lies for features which could be implemented in JS as a 
layer above versus mandated that a browser must / might implement? E.g. 
should the browser respect the start/stop times of the "t" attribute? In 
the future, should the browser define floor control API just because the 
SDP can express it?


The bottom line:
We should be asking "What features / functions / control do we need an 
RTC engine to support minimum on the wire compatibility for 1.0" and 
define the JS surface controls around those exclusively. Instead the 
question being asked far-to-often appears to be "What attributes of SDP 
do we need to expose inside the browser engine?".

The distinction is important. By mandating SDP, we must define every 
support / optional / unsupported SDP attribute exposed from WebRTC 
browser engines (even if they are merely generated in the SDP output or 
accepted as input). Whereas we could just select what an engine really 
needs to function properly and compatibly with existing systems and 
expose nothing more.


-Robin




> Martin Thomson <mailto:martin.thomson@gmail.com>
> 16 July, 2013 2:53 PM
>
> 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.