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

Re: Semantics question for onaddstream() callback

From: Justin Uberti <juberti@google.com>
Date: Mon, 14 Nov 2011 07:30:07 -0500
Message-ID: <CAOJ7v-06O3RXgBWpd4M5t9R-UPTGL1jE1Ed-a+4RNM38obDOSA@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>
What about when a new stream is added to a participant, e.g. a
presentation?
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 Monday, 14 November 2011 12:30:44 UTC

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