Re: constraints use case

Regarding a fallback scenario, there is:

- Use a bluetooth microphone, if one is plugged in, otherwise fallback 
to the built-in microphone.

Going slightly off-topic, shouldn't we be able to do this as well?

- Use a bluetooth microphone, but if/when it's unplugged, fallback to 
the built-in microphone. And vice-versa, if the bluetooth microphone is 
plugged in mid-call, switch over to it.

Meaning, we should have to restart the call to switch devices.

Gili

On 28/03/2014 12:19 PM, Justin Uberti wrote:
> So far I have been asked about these real-world use cases on 
> discuss-webrtc:
> - Choose between 720p and sub-HD (typically 480p or 360p) resolution 
> (maxHeight, maxWidth).
> - Choose frame rate, especially for screen capture (maxFrameRate)
> - Control DSP settings (echoCancellation et al.)
> - Choose camera (sourceId).
>
> I am not aware of any scenarios that require complicated fallback 
> semantics.
>
>
> On Thu, Mar 27, 2014 at 3:47 PM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     Earlier today, I enjoyed Cullen's use of the slippery slope fallacy in
>     response to the request that a use case be produced to support the
>     current constraints expressiveness.
>
>     Can anyone produce one?  We're not going to build a castle on this
>     foundation, but it might be interesting to know just how high we need
>     to pile our stones.  One probably isn't enough, but I can't recall
>     anything.
>
>     A mailing list URL would suffice.
>
>