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

On 06/05/2012 12:00 PM, Harald Alvestrand wrote:
> 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

To me, the natural way to handle this is that the (application of the) 
recipient just disables the track(s) it does not want to receive (by 
setting the enabled attribute to false). If this in turn should result 
in the (browser of the) sender not sending RTP is more of an 
optimization, and how to do that has been discussed at the rtcweb list.

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

"in the middle" could be things like:
- the browsers could not find a common media format (codec) for this 
particular track
- the needed resources (e.g. video encoder at sender or decoder at 
receiver, or cpu cycles) where occupied
- the app at either side does something with the SDP (intentionally or 
by mistake) that stops the set-up of the RTP stream that would represent 
this track

>
> These may need to apply to a track or a stream (probably affecting the
> state of tracks).
>
> Did I miss some variants?

Not that I can think of. An interesting question is: to what extent, and 
how, should the sender side app be informed of that "something in the 
middle" prevented the set up?

>
>
>
>
>

Received on Tuesday, 5 June 2012 14:50:29 UTC