On 3/5/15 12:17 AM, Martin Thomson wrote: > On 4 March 2015 at 18:28, Justin Uberti <juberti@google.com> wrote: >> Since setRemoteDescription is what defines streams, this is always possible. Makes sense, especially given this other sentence in the spec: " A track in a MediaStream, received with an RTCPeerConnection, MUST have its muted attribute [GETUSERMEDIA] set to true until media data arrives." In other words, there seems to be no reason to delay onaddstream (or setRemoteDescription for that matter) on account of preparing media. But this does lead me to wonder: what do people expect the Constrainable methods to return and do on a remote track? The gUM spec [1] talks about this, but our spec does not AFAICT. > This is certainly how I always understood this. After all, how do you > setRemote(offer) and know when the set of streams/tracks your peer is > sending is complete so that you can decide what to reject in your > answer? How does one reject? I've heard talk about calling track.stop() on the remote track but couldn't find that in the spec. --- [1] http://w3c.github.io/mediacapture-main/getusermedia.html#the-model-sources-sinks-constraints-and-settings .: Jan-Ivar :.
Received on Thursday, 5 March 2015 15:02:31 UTC