- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Wed, 04 Mar 2015 14:37:05 -0500
- 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