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

ACTION-95: Constraints usage in the WebRTC spec

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 26 Nov 2013 15:33:14 +0100
Message-ID: <5294B12A.4050108@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 14:33:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC