Re: peerConnection constraints webidl implementer feedback

On 10/16/2013 12:02 AM, Jan-Ivar Bruaroey wrote:
> Hi all,
>
> Here's some feedback after cleaning up constraints for 
> createOffer/Answer in PeerConnection in Firefox. They're in 
> engineering-style bullet-points, so my apologies in advance for the 
> terseness (these are all requests for spec changes).
>
> These are probably more controversial than the feedback I just posted 
> for gUM in media-capture, so I'll jump right in:
>
>  1. About the settings passed to createOffer/Answer & addStream: These
>     are not really constraints IMHO!
>       * I see constraints as defined in gUM by their /reduction/
>         algorithm on some starting pool of similar-propertied things,
>         candidates. Applying this model to the abstract "capabilities"
>         of PeerConnection seems like a stretch that would need a lot
>         of upside to justify the complexity and confusion it adds
>         upfront (like the inverse logic, and whether these things and
>         gUM-constraints are interchangeable)
>       * Differences from gUM constraints:
>           o There is no "audio" or "video" top-layer, we jump right
>             into mandatory vs. optional.
>           o There's no pool of similar-propertied things to reduce, so
>             the reduction algorithm for optional constraints doesn't
>             fit, and the array construct serves no purpose (other than
>             that the whole category is not-mandatory)
>           o The mandatory algorithm boils down to "use these settings
>             (which you must support)". Very simple.
>           o Once unknown keys have been checked for, there's no
>             difference between mandatory and optional internally,
>             which boils down to a flat struct of settings.
>
Except that if you don't know if something's supported, but you'd like 
to have it if it's available, the optional part gives you that.

>           o OfferToReceiveVideo, OfferToReceiveAudio and
>             VoiceActivityDetection are effectively features you turn
>             ON in most cases, not limiters or reducers.
>               + This manifests itself as a problem in the optional
>                 case where it's not clear how to handle failures of
>                 something that is "optional", does it fire the
>                 error-callback or does it proceed without error? This
>                 doesn't come up in gUM.
>

VoiceActivityDetection is a good example of something that might or 
might not be present, and most applications can probably live without 
it. If it's not implemented, the call should continue without error.

>              +
>
>
>       * The last thing I said about a request being "optional" doesn't
>         even make sense, which is the next problem: In place of the
>         reduction algorithm, which doesn't fit here, we/I succumb to
>         attempts at intuiting downstream uses for the mandatory vs.
>         optional distinction, which in itself is troubling. The big
>         one is:
>           o "Otional" means "Do this if you can"
>       * But say the system runs out of ways to receive video because
>         we are receiving 50 videos already, does this setting being
>         specified as "optional" mean we fire the error callback or
>         push through silently? - Regardless of your answer, you must
>         admit you are far removed from the gUM constraints algorithm.
>

I don't really see the difference.

>      *
>
>
>  1. MediaStreamConstraints seems mis-named. It appears to house
>     PeerConnection-specific settings, like OfferToReceiveVideo etc.
>     not settings for MediaStreams.
>
>
> Here's what I propose we do instead for PeerConnection:
>
>   * Declare createOffer/Answer/addStream to take a 'Settings'
>     /dictionary/.
>       o This dictionary has /mandatory/ and /optional/ members like
>         today, except that optional is another dictionary not an array.
>

Doesn't allow for sequencing, which is what we use for priority. Been 
discussed many times before, no consensus to change detected.
In many cases, I think constraints at this level will be "yes or no" 
things - but still, I think there's value in having a consistent interface.

>   * Remove any mention of these being constraints (which they are
>     not), and
>       o spell out a simple "unknown mandatory settings fail (and
>         mandatory trumps optional)" algorithm.
>
> This would pretty much work with what we have already. Thoughts?

Sorry, been there, discussed that, ended up where we are.

>
> .: Jan-Ivar :.
>