W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: UI Problem - media types of incoming connection

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 5 Jun 2012 11:17:07 +0200
Message-ID: <4FCDCE93.5010309@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2012-06-05 08:59, Harald Alvestrand wrote:
> 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.

I agree.

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

We can't do anything with the stream on the sender side, since it may be 
consumed elsewhere and adding it to a PeerConnection shouldn't affect 
other stream consumers. However, we might need an error to tell the 
sender that all the tracks couldn't be sent.

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

On the receiver side, i guess we have these options:
1. Fail the entire stream
2. Mark the failing tracks as ended (will never produce data)
  - Clear distinction between successfully negotiated tracks
    (muted -> live) and failing tracks (muted -> ended).
3. Keep the failing tracks muted.
  - Less clear distinction between successfully negotiated tracks
    (muted -> live) and failing track (stay muted), but tracks may
    be renegotiated.

>> 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
Received on Tuesday, 5 June 2012 10:07:23 UTC

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