- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 14 Nov 2011 11:47:40 +0100
- To: Justin Uberti <juberti@google.com>
- CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 11/14/2011 11:14 AM, Justin Uberti wrote: > Yeah. Triggering "onaddstream" once the first frame has arrived > might be a better measure than RTP getting through. > > Just for info, we've implemented according to the spec as of August, > i.e. fire "onaddstream" when the first RTP packet gets through. We > reasoned that if you get one RTP packet the rest of the data needed > to display anything will anyway arrive shortly. We've also discussed > delaying "onaddstream" until at least one RTP packet has arrived on > all tracks belonging to the stream, but concluded that that might > delay the event more than you want - you would like to start playing > the audio even if the first video data has not arrived. But it would > be a safer measure of that all tracks are getting through to the > other end. > > > I don't think this is the right direction for onaddstream. It may be > important for a stream to exist even when no data has yet been received > on it. Consider the case of an audio conferencing application, which > wants to indicate that a new participant has joined the conference, but > no media has been delivered for that participant because they are not > speaking. I believe that keeping track of new conference participants is something that the web application state would handle separately with signalling via the web server (at minimum to exchange signalling messages). It's likely that a lot of web communication services would like to add WebRTC capabilities to their service, but keep their existing way of managing participants. /Adam
Received on Monday, 14 November 2011 10:51:55 UTC