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: Wed, 04 Mar 2015 14:37:05 -0500
Message-ID: <54F75EE1.7070501@mozilla.com>
To: Byron Campen <docfaraday@gmail.com>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi Byron, this is tracked in https://bugzil.la/1019579

Regardless of Firefox behavior, the spec is unclear about the guarantees 
given, which causes confusion in webrtc libraries.

Is relying on pc.setRemoteDescription().then(() => 
log(pc.getRemoteStreams()) to work, guaranteed by the spec? "As soon as 
possible" doesn't seem like that guarantee. If we want that, then lets 
be specific about it.

.: Jan-Ivar :.

On 3/4/15 2:03 PM, Byron Campen wrote:
>    So, we do indeed fire onaddstream as soon as possible after 
> setRemote. The only thing we could do differently is delay 
> onSetRemoteDescriptionSuccess until the streams/tracks are created, 
> but this would impose delays on ICE (since content needs this callback 
> before trickling ICE candidates). Now, if you are indeed seeing a 
> multi-second delay, there is probably some bug that needs filing, 
> since it should not be that long.
>
> Best regards,
> Byron Campen
>
> On 3/4/15 10:54 AM, Iñaki Baz Castillo wrote:
>> Hi all.
>>
>> The spec is unclear about this topic. I will describe the current
>> "issue" in Firefox (which may be it's not an issue):
>>
>> 1) App creates an offer, sends it to the peer and receives a remote
>> answer with N tracks.
>>
>> 2) App calls to pc.setRemoteDescription().
>>
>> 3) Within the success callback the app calls to pc.getRemoteStreams().
>> It gets no remote streams or tracks.
>>
>> 4) After a few seconds onaddstream fires.
>>
>> 5) After that, calling to pc.getRemoteStreams() return the proper
>> media stream with all its remote tracks.
>>
>>
>> My understanding it that getRemoteStreams() should be deterministic.
>> Nothing has happened between bullets 3 and 5. The onaddstream event is
>> just a native event but the real action happened during bullet 2 and
>> 3, so I consider that bullet 3 should return the full list of remote
>> tracks without waiting some JS cycles for internal stuff.
>>
>>
>> The point here is that the spec is unclear about onaddstream:
>>
>> "It is called any time a MediaStream is added by the remote peer. This
>> will be fired only as a result of setRemoteDescription. Onaddstream
>> happens as early as possible after the setRemoteDescription. This
>> callback does not wait for a given media stream to be accepted or
>> rejected via SDP negotiation."
>>
>> Well, what does "as early as possible" mean? :)
>>
>>
>> Anyhow, the issue above is not about when onaddstream is fired. Since
>> it is an event there is no need for it to be called at a specific JS
>> cycle. But my question is:
>>
>>
>> Should pc.getRemoteStreams() return the full list of remote
>> streams/tracks ONCE setRemoteDescription() succeeded? Currently
>> Firefox does not behave in that way, and instead getRemoteStreams()
>> just return the proper data once onaddstream has been emitted.
>>
>>
>> Thanks a lot.
>>
>>
>
>


-- 
.: Jan-Ivar :.
Received on Wednesday, 4 March 2015 19:37:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC