Re: Semantics question for onaddstream() callback

On Mon, Nov 14, 2011 at 10:31 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> **
> 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?
>

Yes, that's what it would map to at the PeerConnection level.

>
> 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.
>

Right. Sorry for the confusion. In any case, I think that the app may need
to know about this before the actual presentation data arrives.

>
>
>  On Nov 14, 2011 6:51 PM, "Adam Bergkvist" <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
>>
>
>