W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2015

Re: Should pc.getRemoteStreams() include all remote tracks after pcsetRemoteDescription() ?

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 05 Mar 2015 10:01:56 -0500
Message-ID: <54F86FE4.8080909@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.com>, Justin Uberti <juberti@google.com>
CC: IƱaki Baz Castillo <ibc@aliax.net>, Byron Campen <docfaraday@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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 

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.


.: Jan-Ivar :.
Received on Thursday, 5 March 2015 15:02:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:04 UTC