Re: Spec question: Using settings dictionaries instead of MediaConstraints

On Wed, Jun 20, 2012 at 9:21 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 06/19/2012 03:45 PM, Justin Uberti wrote:
>
>
>
> On Tue, Jun 19, 2012 at 8:57 AM, Stefan Hakansson LK <
> stefan.lk.hakansson@ericsson.com> wrote:
>
>>  On 06/19/2012 08:30 AM, Randell Jesup wrote:
>>
>>> On 6/18/2012 3:22 PM, Justin Uberti wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 18, 2012 at 2:57 PM, Cullen Jennings (fluffy)
>>>> <fluffy@cisco.com<mailto:fluffy@cisco.com>>  wrote:
>>>>
>>>>
>>>>     This seems like good proposal, one comment on a small detail.
>>>>
>>>>     On Jun 15, 2012, at 1:28 PM, Justin Uberti wrote:
>>>>
>>>>      >  SessionDescriptionOptions.IncludeAudio = true/false // forces
>>>>     m=audio line to be included
>>>>      >  SessionDescriptionOptions.IncludeVideo = true/false // forces
>>>>     m=video line to be included
>>>>      >  SessionDescriptionOptions.UseVoiceActivityDetection = true/false
>>>>     // includes CN codecs if true
>>>>
>>>>     I think these three should be constraints, not settings because a
>>>>     given browser may not support any of them.
>>>>
>>>>
>>>> Practically speaking, what does that mean for applications?
>>>>
>>>
>>> I can conceive of a browser implementing audio but not video.  And a
>>> gateway or other stand-alone WebRTC box/functionality might include JS
>>> and these JS apis for ease of programming (and might be audio-only).
>>> (I'd try to avoid it in production, probably, but even that might not be
>>> needed with modern JS JIT speed so long as it didn't have to tear down
>>> and restart all the time.)
>>>
>>> CN codecs: I dislike them anyways.  :-)  An implementation definitely
>>> could avoid including those.
>>>
>>
>>  Many codecs have built in CN modes. I guess for those it is more a
>> question of being able to switch off the VAD.
>>
>>
>  I agree with the scenarios mentioned - my question was mostly about what
> does having these settings be "constraints" vs "settings" mean for users of
> the API. Is it simply that the call must fail if the request can't be
> satisfied?
>
>
> If they are constraints, it's the caller's choice whether or not the call
> should fail if the constraint can't be satisfied (listing them in
> "mandatory" vs "optional" sections).
>
> If they are settings, it's the specification's choice whether or not the
> call should fail if the constraint can't be satisfied; it has to be always
> handled the same.
>
> At least that's how I read it.
>

That makes sense. So perhaps we add .mandatory and .optional to make these
dictionaries into SessionDescriptionConstraints/IceConstraints, e.g.

constraints = {};
constraints.mandatory.getCapabilities = true;
constraints.optional.includeAudio = true;
constraints.optional.includeVideo = true;
pc.createOffer(successCb, failCb, constraints);

and we end up with MediaConstraints, SessionDescriptionConstraints, and
IceConstraints that all act the same way.

>
>
>              Harald
>
>
>