Re: Moving forward with SDP control

On 17/07/2013 12:20 AM, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 17, 2013 at 11:11 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>     On 16/07/2013 9:45 PM, Eric Rescorla wrote:
>>
>>
>>     On Wed, Jul 17, 2013 at 9:37 AM, cowwoc <cowwoc@bbs.darktech.org
>>     <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>         This contradicts what I heard from Cullin and Adam (spec
>>         editors) at WebRTC World. I was told that users are never
>>         supposed to manipulate the SDP; rather, they are meant to
>>         drive changes using the Constraints API. The only reason they
>>         are allowed to do so today is because the Constraints API
>>         hasn't been completed yet.
>>
>>
>>     I think you misinterpreted them. The API *should* provide enough
>>      flexibility
>>     that you rarely or ever need to modify SDP. However, that doesn't
>>     mean
>>     you can't do so.
>>
>>     See:
>>     http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-6
>>
>>     -Ekr
>>
>
>         They didn't say that you couldn't do so, rather that you
>     shouldn't ever need to do so.
>
>
> I think this is fairly consistent with what I said above.
>
> -Ekr
>

     So then I move to propose removing the SDP from the API in favor of 
a higher-level Capabilities API, and suggest that experimental features 
be exposed by way of implementation-specific methods or prefixed keys.

     On the topic of methods vs key/value pairs, I would like to point 
out that the former can represent anything that the latter can do (which 
the latter cannot). Instead of introducing yet another declarative 
key-value mapping, why don't we expose an imperative API?

For example, instead of:

     var capabilities =
     {
       "mandatory":
       {
         "minWidth": 720.
         "minHeight": 1280,
         "maxBandwidth": 5000
       },
       "optional":
       {
         "minFrameRate": 20
       }
     }

we can have:

     offer.resolution(720, 1280).bandwidth(5000);

This has the following advantages:

 1. Ability to fail-fast: Imagine we know that 720x1280 can never be
    sent over the wire using 5k of bandwidth. The API can fail-fast at
    maxBandwidth(5000) with a meaningful/contextual exception instead of
    the generic errors we now receive at a much later time.
 2. Ability to handle optional/mandatory constraints in a more dynamic
    manner. Meaning, users can specify a minimum resolution, but if the
    viewport drops below that value they can adjust the minimum
    resolution to an even lower value. Or, users can specify a minimum
    bandwidth value, but if it drops below this value they an
    temporarily drop video and bring it back when bandwidth conditions
    improve.

     I see a lot of use-cases for specifying minimum/maximum values 
(always optional) and letting an application layer decide how to handle 
values falling outside that range. The current behavior of mandatory 
constraints seem too rigid to me. This might work for very simple 
example code, but won't be useful in a production environment.

     Using an imperative API allows you to expose simplistic constraints 
as well as very detailed constraints. You can either drop this 
functionality into the same API or layer a high-level API on top of 
another lower-level API. It's more difficult to achieve the same in 
clean manner if key-value pairs are used.

Gili