Re: Exchange of "settings" versus exchange of "capabilities"/"preferences"

Yes, I've been thinking along the same lines trying to go through the 
API with a fine tooth comb and attempting to use it from an application 
developer's use case perspective.

I kind of see the RtpSender/RtpReceiver's "parameters" as a low level 
construct where an engine can generate out details constructs of what 
needs to happen to "send" or "receive" with the "RtpSender" and 
"RtpReceiver". The application developer can certainly go in an tweak 
the "parameters" but they are extremely low level "down to the wire 
codec configuration" stuff. We need it to exist because compatible might 
demand tweaking it but the last thing I would want is for an average 
developer to be required to setup one of those things.

In simple use cases, a developer doesn't have to touch "parameters". 
They can just create one and filter them. But if a developer wants to 
start using SVC with simulcast and temporal and spatial layering, they 
are going to have to know exactly how to set up that low level stuff or 
it won't work. And they need to understand what codecs can do it and 
which cannot. And engines need to be able to exchange that information 
on the wire and filter and "fix" it according to their own understanding 
of the codecs no matter what the remote side generates.

I think it's a bit of a recipe for an SDP like disaster scenario, 
especially when engines need to filter capabilities from parameters they 
don't understand from capabilities they don't fully understand.

As an application programmer, I want simple knobs to control "what I 
want", i.e. preferences. I want the engine to be able to spit out that 
complex detailed stuff. And from an engine maker, I don't want to be 
re-tweaking low level stuff generated by another engine with a whole set 
of rules that I may not be aware.

But there's a solution that isn't far off from from the current proposal 
that operates more on "capabilities" as you suggest but still uses our 
"parameter" stuff we do right now (with some fixes to make other SVC 
scenarios work after much research). I'm just getting it ready to put on 
the list (with examples).

Bottom line, you are right, there's potential of a rabbit hole of issues 
here if we don't fix this...

We really do need to have a "use case" document to describe common 
scenarios for application developers to describe what we want to support 
so we can know if it's possible to implement these scenarios without 
expecting crazy juggling acts. We've been throwing around some use case 
concepts for a while but it would be good to have a bit more of a firm 
list of the scenarios we want to be able to support out of the gate.

-Robin


> Bernard Aboba <mailto:Bernard.Aboba@microsoft.com>
> May 5, 2014 at 7:04 PM
>
> In re-reading the recently posted Editor's draft 
> (http://ortc.org/wp-content/uploads/2014/04/ortc1.html) I realized 
> that there is something about Section 6.4 examples 8 and 9 that 
> bothers me.
>
> The basic problem is that in these examples the peers send 
> "parameters" (e.g. detailed settings) to each other over the wire, 
> then "filter" them through the receiving and sending capabilities.
>
> In looking at the examples, it occurred to me that this implicitly 
> assumes that the peers not only share a "capabilities" language in 
> common, but also share a common set of "parameters" that each 
> understands.
>
> This model seems to assume implicitly that the browsers support 
> similar capabiltiies, differing only modestly.
>
> However, if we consider browsers that have substantially different 
> capabilities -- say a browser that speaks H.264/SVC with integrated 
> simulcast and temporal scaling  initiating an exchange to a browser 
> supporting H.264/CBP that can handle only handle simulcast, then the 
> limitations of this approach become apparent.  For example, attempting 
> to exchange "parameters" on the wire could have unpredictable results, 
> compared with exchanging "capabilities" and basic "preferences" so as 
> to determine the subset of functionality that the two sides have in 
> common.
>
> In Example 8, the initiator sends along its receiver capabilities with 
> its audio and video send parameters obtained from createParameters.   
> The problem is that the resulting detailed H.264/SVC send "parameters" 
> would not be understandable to the peer who only speaks H.264 CBP and 
> simulcast, and attempting to separate out the "mandatory" and 
> "optional" aspects of the send "parameters" would involve a repulsive 
> level of complexity (requiring integration of the "constraint" model 
> from getUserMedia).
>
> Note that sending along the receiver capabilities doesn't help, except 
> to enable the peer to realize that why the "parameters" it has 
> received don't make sense to it, even though the two peers actually 
> have a subset of functionality in common (e.g. H.264/CBP and 
> simulcast).   Given the initiator's receive capabiltiies and its own 
> send capabilities, the peer can reply with a more sensible set of 
> sending parameters, but that leaves the connection only half set-up.
>
> In thinking of how to fix Examples 8 and 9, it occurred to me that 
> they could be made to work much better if both sides exchange 
> "capabilities" first to determine the subset of functionality that 
> they have in common.   Doing things this way allows the initiator to 
> say that it supports H.264/CBP as well as H.264/SVC and in addition 
> that it supports simulcast (for any codec).  In taking the 
> intersection of capabilities, both sides can then conclude that they 
> can and send H.264/CBP with simulcast.
>
> If we can assume a deterministic procedure for taking the intersection 
> of receiver and sender capabilities and "filtering" the parameters 
> through this, it even seems possible to conclude the negotiation in a 
> single round-trip while avoiding the exchange of "parameters" over the 
> wire at all (an I dreaming?).
>
> In looking at a number of potential use cases, this same conclusion 
> appears to present itself -- that exchange of "capabiltiies" over the 
> wire is inherently simpler and potentially more interoperable than 
> exchange of "parameters".
>
> On reflection, perhaps this conclusion is not so strange after all. 
>   The exchange of "capabilities" is more or less the model used by 
> H.245 -- and the exchange of "parameters" (or settings) is somewhat 
> akin to the SDP O/A model.
>
> Hmm.
>