Re: UI Problem - media types of incoming connection

Cullen and I discussed this and agreed the onaddstream handling mentioned
here (and I presume, the contents of PeerConnection.remoteStreams) is the
right solution.

However, this does bring up a couple other questions:
- If the caller advertises multiple media streams/tracks in its offer, but
the callee only accepts some of them (accepting audio but not video by
setting the m= port to zero), does a callback at the callee side get fired
(after setLocalDescription(answer)) indicating those remoteStreams have now
gone away?
- Same thing, but from the caller side - how does the caller find out that
some of its streams/tracks were rejected (we have no callback for this,
currently), and do those localStreams go away?

On Mon, Jun 4, 2012 at 10:16 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

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