Re: [Bug 22338] New: Arbitrary changing of tracks

(taking discussion on list - questions clutter up the bugzilla; 
clarifications may need to be copied there.)

On 06/12/2013 06:53 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22338
>
>              Bug ID: 22338
>             Summary: Arbitrary changing of tracks
>      Classification: Unclassified
>             Product: WebRTC Working Group
>             Version: unspecified
>            Hardware: All
>                  OS: All
>              Status: NEW
>            Severity: normal
>            Priority: P2
>           Component: Media Capture and Streams
>            Assignee: public-media-capture@w3.org
>            Reporter: martin.thomson@skype.net
>                  CC: public-media-capture@w3.org
>
> The spec permits a user or user agent to switch between tracks at any time:
>
> Unless and until a new set of constraints is provided, the user agent MAY
> change its choice of track at any point, provided that 1) the new choice does
> not violate given user permissions, and 2) it notifies the application code by
> raising an event.
>
> The event is undefined, but that's not the concern.  As a user, I don't want
> this to happen.  Therefore, as an application developer, I don't want this to
> happen.  If this is possible (it sounds like a bad idea to me), there needs to
> be a way to prevent it from happening.
>
> sourceId constraints are not sufficient.
>
Martin, can you be a little more precise in what you mean here?

What do you mean by "user or user agent", and what do you mean by 
"switch between tracks"?

The matching text I found is section 11.1.1 of getusermedia, which says 
" Unless and until a new set of constraints is provided, the user 
agent/may/change its choice of track at any point, provided that 1) the 
new choice does not violate given user permissions, and 2) it notifies 
the application code by raising an event. It may wish to do this, for 
example, if the user interface or network congestion changes. Note that 
no such change will have an effect on the presence or absence of each 
type of track, merely the contents."

One scenario for use of multiple tracks in a video stream that has been 
suggested is to send both a video and an "on-hold image" as two video 
tracks, and implement "video mute" by disabling the video track while 
enabling the "on-hold image" track - which allows one to achieve the 
effect without changing the source of the video element displaying the 
stream. On first thought, I wouldn't see a reason to disallow that.

One scenario I've heard (but which I don't think anyone's implemented 
yet) is that the user might switch cameras or microphones by some 
interaction with browser chrome rather than causing the application to 
getUserMedia again. I wouldn't be too concerned if that functionality 
were to go away - but again, I don't see a strong argument against it at 
the moment.