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

Re: Semantics question for onaddstream() callback

From: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
Date: Sun, 13 Nov 2011 15:59:51 +0100
Message-ID: <4EBFDB67.7050705@ericsson.com>
To: Justin Uberti <juberti@google.com>
CC: Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 11/13/2011 03:33 PM, Justin Uberti wrote:
> On Mon, Nov 7, 2011 at 11:51 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>      >On Mon, Nov 7, 2011 at 7:15 AM, Harald Alvestrand
>     <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>      >> 1) We know that this stream is expected. The callback occurs as
>     soon as we
>      >> have the OFFER or ANSWER containing information about this
>     stream. Move the
>      >> last onaddstream() up to just after onconnecting().
>      >>
>      >> 2) We know that media is arriving on the stream. The callback
>     occurs as soon
>      >> as the first media packet arrives. Move the first onaddstream()
>     down below
>      >> the "ICE Completes" line
>      >>
>      >>
>      >> My order of preference is 1) followed by 2). But I think we need
>     to pick one
>      >> and only one, and make sure the API spec says exactly that.
>      >
>      >My vote would be (1) and to add a onmediastarted() callback to
>      >indicate the first
>      >packet for a given media stream.
>     I share this view - you need both. //Stefan
> Agree regarding (1). Regarding (2), what do we expect the application
> would do when it gets an onmediastarted()?
That's the indication that things worked out. (1) only indicates that 
signaling has been carried out, (2) tells the application that media is 
actually getting through. There can be problems with getting media 
through; there may FWs or NATs or other reasons for not getting it through.

The application could e.g. wait with displaying the video surface until 
something is actually received. (Sure there are other ways - paint a 
canvas&analyze - but (2) is quite convenient)

As the API is currently defined, feeding back to the sender that (2) has 
happened can also be used as an indicator to the sender that the streams 
sent are received be the receiver (of course we could add error events 
at the addStream level to accomplish the same thing - but it is already 
there in some sense with (2)). So it can be part of error handling.

If I had to select, (2) would be the one to keep; but both make a lot of 

my $0.02
Received on Sunday, 13 November 2011 15:00:27 UTC

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