a synchronous choice getUserMedia options

Problem RTCPeerConnection requires MediaStreams (and MediaStreamTracks) in order to negotiate streams MediaStreams can currently only exist when the user has provided consent This leads to a problem where negotiation can’t continue without consent, which leads to clipping on answer

Proposed Solution (Common) Provide placeholder MediaStreams that can be used as a basis for negotiation – The object is real, but unconnected or disabled somehow prior to the user providing consent – The SSRCs that can be generated are stable [sic] – Negotiation can continue prior to consent being granted using the placeholder

Option 1 getUserMedia returns streams that do not start until consent is granted. var stream = navigator.getUserMedia(constraints); stream.audioTracks[0].onstart = grantedCb; stream.audioTracks[0].onend = deniedCb; pc.addStream(stream); Consent events are communicated on the tracks – A new started event is added to tracks. – The reasons for the end event are expanded to include all the error conditions for getUserMedia: nodevice, permissiondenied, deviceerror

Option 2 As option 1, except the return value is a wrapper: var streamBucket = navigator.getUserMedia(constraints); streamBucket.onsuccess = grantedCb; streamBucket.onfailure = deniedCb; pc.addStream(streamBucket.stream); Returned tracks are ‘muted’ until consent is granted Extra arguments to gUM create a signature that is identical in usage to existing asynchronous gUM – also possible with Option 1

Option 3 Stream placeholders are instantiated and “connected” to devices by getUserMedia var audioTrack = new AudioMediaStreamTrack(constraints); var stream = new MediaStream(audioTrack); navigator.getUserMedia(stream, grantedCb, deniedCb); pc.addStream(stream); Constraints are attached directly to tracks – Nascent until the device is connected – Turn into settings once the device is connected Backward compat (if desired) with overload

Option 4 Leave it asynchronous Don’t change anything Ensures that users don’t get an object that isn’t “working” Avoid programmer errors that arise due to bad assumptions about consent, device availability, constraints, etc…

Preferences Synchronous Option 3: – 3 fits better with the new settings work – 1 and 2 are functionally equivalent, with some stylistic differences, and some usability issues – 4 doesn’t solve the problem No backward compatibility hack – Overloading gUM might be possible to replicate old behavior, but that’s just extra API cruft