W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: Semantics question for onaddstream() callback

From: Justin Uberti <juberti@google.com>
Date: Tue, 15 Nov 2011 01:58:25 -0500
Message-ID: <CAOJ7v-29LMOyUcUPu+N-ybL5o46s7SKuL+Gk8Lqo86dbvJt1Hw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
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
Received on Tuesday, 15 November 2011 06:59:22 UTC

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