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

Reasons for silence (Re: UI Problem - media types of incoming connection)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 05 Jun 2012 12:00:28 +0200
Message-ID: <4FCDD8BC.4050801@alvestrand.no>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Changing the subject, since we're touching on a different topic...

On 06/05/2012 11:17 AM, Adam Bergkvist wrote:
> On 2012-06-05 08:59, Harald Alvestrand wrote:
> 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.

Hmm..... this illustrates the fact that there are multiple reasons a 
track shows no data, and we may need to keep them straight, because they 
affect what might happen next:

- the sender is not sending data, but may do so in the future (source muted)
- the recipient has asked not to receive data, but may ask for it later 
(I was using "muted" above for this, it may not be the best word)
- the sender has ended the stream, and no data will ever come again (ended)
- something in the middle prevents the delivery of data (which may be 
seen as "sender mute" on one side and "receiver mute" on the other, or 
may be a third state).

These may need to apply to a track or a stream (probably affecting the 
state of tracks).

Did I miss some variants?
Received on Tuesday, 5 June 2012 10:01:01 UTC

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