Re: Spec question: Using settings dictionaries instead of MediaConstraints ([ACTION-50])

On Tue, Jun 19, 2012 at 11:29 AM, Adam Bergkvist <
adam.bergkvist@ericsson.com> wrote:

> On 2012-06-19 03:48, Justin Uberti wrote:
>
>>
>>
>> On Mon, Jun 18, 2012 at 7:53 PM, Eric Rescorla <ekr@rtfm.com
>> <mailto:ekr@rtfm.com>> wrote:
>>
>>    On Mon, Jun 18, 2012 at 5:13 AM, Adam Bergkvist
>>    <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@**ericsson.com<adam.bergkvist@ericsson.com>
>> >>
>>
>>    wrote:
>>     > On 2012-06-15 21:28, Justin Uberti wrote:
>>     >>
>>     >> At the interim, it was indicated that using MediaConstraints for
>>     >> non-media PeerConnection methods was probably not the right fit,
>> one
>>     >> reason being that most options were only relevant for a specific
>>    method,
>>     >> and it would be good to make it clear which options should be
>>    passed to
>>     >> which methods.
>>     >>
>>     >> Therefore I propose that we define other settings dictionaries,
>>    similar
>>     >> to MediaConstraints, but named specifically for the methods in
>> which
>>     >> they will be used.
>>
>>    Generally, I like this approach. Some (hopefully easy) nits below.
>>
>>     >> This results in new dictionaries IceOptions and
>>     >> SessionDescriptionOptions, with values as shown below:
>>     >>
>>     >> IceOptions.AllowedCandidates = ("none", "relay", "all) // "all",
>>    if not
>>     >> specified
>>     >>
>>     >> SessionDescriptionOptions.**IncludeAudio = true/false // forces
>>    m=audio
>>     >> line to be included
>>     >> SessionDescriptionOptions.**IncludeVideo = true/false // forces
>>    m=video
>>     >> line to be included
>>
>>    By "forces" you mean "even if I don't include a video stream"?
>>    That's what I'm taking from Adam's comment.
>>
>>
>> Correct.
>>
>>    What happens if I AddStream() a video stream  but set this to
>>    false?
>>
>>
>> One of the following:
>> 1. The setting is ignored.
>> 2. The stream is ignored.
>> 3. An exception is thrown.
>>
>>
>>    Maybe it would make more sense to have this *only* control
>>    generating a recv-type media stream and have addstream
>>    control only a send-type.
>>
>>
>> This controls adding a m= line in the offer or answer, which is needed
>> if we want to send or receive. The original intent was to make the
>> meaning of this setting to be "include a m=video line if one doesn't
>> already exist", which would be essentially #1 above.
>>
>> Or we could be strict and do #3.
>>
>>
> With Ekr's comment above about letting "includeVideo" control the
> recv-type and addStream() control send-type, then addStream(videoStream) +
> "includeVideo":false could mean that I want to send video, but not receive
> video. The nice thing with only having addStream() control the send-type is
> that if the app can't generate a video stream, then there's no way for the
> JS app to hard-code that video should be sent anyhow which needs to fail in
> some way.
>
> If I get the current approach, then addStream(videoStream) obviously means
> that I want to send video, but also implies that I'm willing to receive
> video (regardless if I set "includeVideo":true or not). A bit less control
> than the scenario above.
>
>
>
So if you added streams, but didn't set |includeVideo|, the m=video line
would be marked as a=sendonly. Got it.