W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

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

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 26 Nov 2013 15:15:01 +0000
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2811F0290@GENSJZMBX03.msg.int.genesyslab.com>
  Your reasoning looks sound to me.  We have tended to use the term 'constraint' too broadly up to this point.

- 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?

## 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

## IceRestart
Used with createOffer()

Force generation of new ICE credentials.

Proposal: Move to a CreateOfferOptions dictionary

## VoiceActivityDetection
No usage documented.

Enables VAD, if available.

Proposal: Should be a constraint on the DooHickey object.

## RequestIdentity
Used with PeerConnection() Constructor, createOffer() and createAnswer()

Indicates whether an identity should be requested.

Proposal: Move to RTCConfiguration and CreateOfferAnswerOptions dictionary

# 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.

Received on Tuesday, 26 November 2013 15:15:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:52 UTC