Re: ACTION-95: Constraints usage in the WebRTC spec

I was surprised to see "Constrainable for RTCPC" still on the short-list 
of today's teleconference, and a decision of "Yes, just do it!". Did not 
everyone in this thread agree effectively to remove all constraints from 
PeerConnection and add them as dictionary members to either 
RTCConfiguration or CreateOfferOptions?

List from http://dev.w3.org/2011/webrtc/editor/webrtc.html#constraints 
cross-referenced to Adam's proposals (and in one instance follow-ups) below:

  * OfferToReceiveVideo: [2] Move to CreateOfferOptions dictionary
  * OfferToReceiveAudio: [2] Move to CreateOfferOptions dictionary
  * VoiceActivityDetection: [4][6][7] Move to a CreateOfferOptions
    dictionary
  * IceTransports: [1] Move to RTCConfiguration
  * IceRestart: [3] Move to a CreateOfferOptions dictionary
  * RequestIdentity [5] Move to RTCConfiguration and
    CreateOfferAnswerOptions dictionary


That's all of them. I propose we remove MediaConstraints from the webrtc 
spec entirely. Then Constrainable is not needed.

All in favor?

On 11/26/13 10:15 AM, Jim Barnett wrote:
> Adam,
>    Your reasoning looks sound to me.  We have tended to use the term 'constraint' too broadly up to this point.

I agree. I believe this was the sentiment at the media-capture 
teleconference as well, where we found it useful for cases where UAs 
arbitrate shared usage/control of a common resource, and picks between 
mutually-exclusive property-laden choices. e.g. gUM.

> - Jim
>
> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Tuesday, November 26, 2013 9:33 AM
> To: public-webrtc@w3.org
> Subject: ACTION-95: Constraints usage in the WebRTC spec
>
> Constraints in the WebRTC specification.
>
> The spec currently uses constraints in three ways:
> 1. Constructor argument
> 2. Arugment to method modifying an object (e.g. updateIce()) 3. Arugment to method performing an action on an object (e.g. addStream())
>
> The first two usages seem to work OK. 1) is similar to constructing a Constrainable object and then calling applyConstraints() and 2) is pretty much applyConstraints() with a different name. 3) is trickier.
> Even though the call is made on a Constrainable object, the constraints are associated with an operation made on the Constrainable object and not the object itself. I think we should avoid this kind of usage.
>
> To evaluate each constraint, I've used the following two questions. If the answer is yes to both of these questions then a settable property should not be a constraint.
>
> 1. Is there a set of possible values that are the same for all browsers?
> 2. Will this settable property succeed if applied at the correct state?
> I.e., it shouldn't fail because a value is out of the range of what the browser is capable of.
>
> Even though the answer to question 2 may be "no", there might still be a reason to use a regular settings dictionary.
>
> # Constraints
>
> ## IceTransports
> Used with PeerConnection() Constructor and updateIce()
>
> Controls which types of candidates the ICE agent is allowed to use.
>
> The possible values are "none", "relay" and "all". If a browser, for some special reason, is configured to not support all these values, that might be a reason to have it as a constraint.
>
> Proposal: Move to RTCConfiguration?

[1]

> ## OfferToReceiveVideo/Audio
> Used with createOffer()
>
> Used to express a preference for receiving a media type (even though the media line is not added as a result of addStream()).
>
> Proposal: Move to CreateOfferOptions dictionary

[2]

> ## IceRestart
> Used with createOffer()
>
> Force generation of new ICE credentials.
>
> Proposal: Move to a CreateOfferOptions dictionary

[3]

> ## VoiceActivityDetection
> No usage documented.
>
> Enables VAD, if available.
>
> Proposal: Should be a constraint on the DooHickey object.

[4]

> ## RequestIdentity
> Used with PeerConnection() Constructor, createOffer() and createAnswer()
>
> Indicates whether an identity should be requested.
>
> Proposal: Move to RTCConfiguration and CreateOfferAnswerOptions dictionary

[5]

> # addStream() Method
>
> I think we should remove the MediaConstraints argument here since it's an operation of type 3) mentioned above. It's also a question about what precision we can have on the constraints since a MediaStream can contain several tracks and it's likely that the script would like to address constraints to individual MediaStreamTrack objects. We're probably better off with having constraints on the DooHickey object.

[6]

> /Adam

On 12/17/13 2:38 PM, Jan-Ivar Bruaroey wrote:
>> On 11/26/13 12:17 PM, Justin Uberti wrote:
>>>
>>>     Proposal: Should be a constraint on the DooHickey object.
>>>
>>>
>>> As defined right now, this constraint to createOffer controls the 
>>> inclusion of the CN (RFC 3389) codecs in the offer, which are used 
>>> when doing VAD with codecs that don't have built-in CN, e.g. G.711. 
>>> That seems like something we may need to retain, even if we have 
>>> some other property on the MediaStreamTrackSender that controls 
>>> whether CN is *actually* used for the specified track.
>
> In other words, proposal: Move to a CreateOfferOptions dictionary.

[7]

.: Jan-Ivar :.