Re: Semantics question for onaddstream() callback

On 11/14/2011 08:30 PM, Justin Uberti wrote:
>
> What about when a new stream is added to a participant, e.g. a 
> presentation?
>
I dont think we have a concept called "participant".
Do you mean a new MediaStreamTrack inside a MediaStream?

That's what I'd find most natural to represent "this user, who 
previously sent me voice and video, is now also sending me a 
presentation"; YMMV.

> On Nov 14, 2011 6:51 PM, "Adam Bergkvist" <adam.bergkvist@ericsson.com 
> <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     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
>