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

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.