RE: Some of the shortcoming of offer/answer + SDP based API

I think that it might be good to maintain a logical distinction between
constraints and settings.  A device has certain fixed properties, for
example the fact that it handles video and can offer resolutions between
m and n, etc.  But it also has variable settings that the user/app can
control, such as volume, the actual resolution (a number between m and
n, etc.)  The app can use a constraint to request a device with certain
properties, for example one that is capable of a resolution of at least
m.  It could do this by asking maxResolution >= m.  But it doesn't make
sense to try to _set_ maxResolution.  Instead, what you set is the
actual resolution (among those that are available.)  

We may well be able to use a similar syntax for these two uses, but
logically constraints a) apply to immutable properties of the device, b)
can often specify ranges.  Settings select specific values within the
range that a device is capable of.  There's always a difference between
"I want something that it capable of doing x" and "Please do x".

- Jim
-----Original Message-----
From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Tuesday, September 11, 2012 5:43 AM
To: public-webrtc@w3.org
Subject: Re: Some of the shortcoming of offer/answer + SDP based API

On 09/10/2012 09:26 PM, Harald Alvestrand wrote:
> On 09/10/2012 08:36 PM, Roman Shpount wrote:
>> I think you missed my point. What I am trying to say is that there 
>> are a number of parameters that needs to be specified which are not a

>> part of offer/answer exchange, and that there are a number of 
>> parameters that can be changed without an offer/answer exchange. 
>> Current API is constraint in such a way that you cannot specify first

>> at all and cannot change second without doing a complete offer/answer

>> exchange with remote side that is not needed.
> OK, now I think I understand what you are saying. Those things can't 
> be changed with an offer/answer exchange either; you're asking for 
> more API surface.

I agree to Roman on this point. Some of the examples belong more to how
the capturing device (camera, microphone) is configured to act. Others
are more related to how codecs and transport is set up when a track is
transported to a peer.

API surface to configure, and change, those parameters is needed.

There are, as I see it, four proposals that address this space
available:

1. First we have the use of constraints when asking for user permission
to use input devices. This is already in the "Media Capture and Streams"

document ([1]).

2. A proposal from Travis that gives a surface to set/change the way a
capturing/ generation of MediaStreamTracks is configured [2]. The idea
is to use constraints as the actual method of communicating the desired
setting IIUC.

3. At addStream to PeerConnection, constraints can be supplied to
control the way the tracks in the MediaStream added are set up for the
transport. This is already in the webrtc 1.0 document [3]. Likewise,
constraints that apply to SDP can be applied when doing createOffer and
createAnswer - but the use of these settings is as far as I have
understood limited to indicate whether you want video to be part of the
session even if the MediaStream you have added contains only audio and
similar things.

4. A recent proposal to add a surface where the setup of the transport
related things for a MediaStreamTrack can be controlled [4]. Again,
constraints can be used to communicate the desired settings.

Now, let me give you my personal view on these four:

For how cam/microphones are set generate media, my view is that
constraints at getUserMedia [1] time should only be used to control how
the browser populates the list of devices the user can select from (put
the most fitting based on the constraints first, not propose devices
that don't fulfill mandatory constraint, and even fail without
presenting a choice to the user if no device fulfills the mandatory
constraints). The control of how the devices are set up to operate
should be done through something like [2] so that app developers don't
by accident lock out users while trying to optimize quality. [2] also
allows changing settings.

For settings related to the transport of a MediaStreamTrack I like [4]
over [3] for several reasons. One reason is that settings can't be
changed after addStream with [3], so if you for example would like to
change the priority or something else during the session that can't be
done. Another reason is that [3] gives no surface for the situation when
a new track is added to an existing MediaStream that is connected to a
PeerConnection. [4] on the other hand allows changing settings, allows
the app to apply settings for the transport of a new track added to an
existing MS.

Stefan


[1]
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#navigatorusermedi
a

[2]
http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0143.ht
ml

[3]
http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerconnection-inter
face

[4] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html

>
> Some of them were expected to be described as "constraints" last time 
> I saw people have an opinion (and we need a mechanism to change 
> constraints after mediastream creation / connection). Those that can't

> be described in such a way ... we need to identify and discuss.
>

Received on Tuesday, 11 September 2012 14:08:19 UTC