Re: Spec question: Using settings dictionaries instead of MediaConstraints

On Fri, Jun 22, 2012 at 1:03 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 06/22/2012 03:37 AM, Justin Uberti wrote:
>
>
>
> On Thu, Jun 21, 2012 at 6:42 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>
>>
>> On Jun 20, 2012, at 9:21 , Harald Alvestrand 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 think we need to focus on VAD not CN. Note all the use cases erased
>> are about VAD not CN. Note the text in section 5.1 is only about VAD and
>> says
>>
>> VoiceActivityDetection
>> This is a enum type constraint that can take the values "true" and
>> "false". The default is a non mandatory "true".
>>
>> Many codecs and system are capable of detecting "silence" and changing
>> there behavior in this case by doing things such as not transmitting any
>> media. In many cases, such as when dealing with sounds other than spoken
>> voice or emergency calling, it is desirable to be able to turn off this
>> behavior. This constraints allows the application to provide information
>> about if it wishes this type of processing enable or disabled.
>>
>
>  I understand what you are saying, but other than omitting "CN" from the
> list of codecs, what other effect do you expect this constraint to have on
> the generated SDP?
>
>
> It might not even have that effect. The SDP would reasonably announce CN
> as long as the browser was able to receive it, because the other partner
> might want to use CN, or another track that was added later might set VAD
> to true even if the first track had it false.
>
> The important setting would be that the codec is configured not to choose
> to generate silence on no-voice-activity; this is a pure sender-side
> decision.
>
>
That means this constraint needs to be on a Stream or Track, not
createOffer. If it doesn't change the generated SDP, it can't go on
createOffer.