Re: UI Problem - media types of incoming connection

On 06/04/2012 11:23 PM, Justin Uberti wrote:
> 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?
My opinion:

At the API level, we should keep the concept that the sender dictates 
the content of LocalStreams, and RemoteStreams is strictly a mirror of 
what's in LocalStreams. Similarly for Tracks.

Thus, a track that's rejected at the SDP level should not disappear from 
the API; it should be present, but marked as muted at the sender's side.

If SDP later renegotiates the session to allow the relevant media type, 
it can be unmuted.

>
> On Mon, Jun 4, 2012 at 10:16 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto: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 <mailto: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
>
>
>
>
>