- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 04 Jun 2012 16:16:08 +0200
- To: public-webrtc@w3.org
On 06/01/2012 09:48 PM, Eric Rescorla wrote:
> On Fri, Jun 1, 2012 at 11:53 AM, Justin Uberti<juberti@google.com> wrote:
>> I don't know if this is even needed for this case. I would think we would
>> handle this by calling setRemoteDescription("offer", sdp), and then look at
>> the MediaStream (either from remoteStreams on onaddstream to see if it has
>> audio or video tracks. Bob hasn't signaled anything back to Alice at this
>> point, so this should be fine.
> This is what I had originally assumed one would do, and then when Cullen
> and I tried to do independent sequence diagrams, it turned out that he
> didn't agree, so I asked him if the editors could try to propose something :)
>
> Cullen can provide his own arguments for why you don't want to use
> onaddstream, but IIRC part of it was that the streams aren't actually
> readable at this point.
My understanding of the movement of onaddstream from "media received" to
"media configured" is that it is intended to allow you to ask exactly
this question.
In fact, Stefan posted a CONCLUSION message on November 30 saying:
> The conclusion of this discussion seems to be:
>
> 1. MediaStream objects should be created more or less immediately as
> result of "getUserMedia" or "addStream" operations (in the later case
> a MediaStream object on the remote side should be created as a result
> of the signaling).
>
> 2. There is a need to, on a MediaStreamTrack level, notify the
> application when live data is available (which can be a bit later than
> the creation of the MediaStream object).
>
> The task is now on the Editors to change the drafts along these lines.
It would seem natural that one can inspect the resulting MediaStream to
see which kinds of tracks it contains.
(This is the last thread on the list archive that has "onaddstream" in
the subject.)
Harald
>
> -Ekr
>
>
Received on Monday, 4 June 2012 14:16:55 UTC