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

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

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

[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 09:43:48 UTC