Re: Signalling of start / stop

On Tue, Jan 21, 2014 at 10:51 AM, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
> Stefan said:
>
>> I think it is a bad idea to not signal and just stop sending RTP - the
>> receiver would then have to guess if the sender stopped sending temporarily,
>> or if there are a lot of packet losses, or if there is a speech pause (and
>> CN should be generated) etc.
>
> [BA] I would agree that a packet may need to be sent as the result of a stop(), pause() or resume().
> However, it looks to me like the action may depend on the specific configuration and codec.
>
> An example of this is SST SVC where in some codecs (e.g. VP8) there may be no packet sent to
> indicate dropping a layer, just a reconfiguration of the encoder, whereas in others (e.g. H.264)
> a codec-specific packet might be sent (SEI layer drop).
>
> In MST SVC it is possible that the situation could be different if we can assume thatl WebRTC implementations
> understand TMMBR and therefore a TMMBR message with maximum bandwidth of zero might be
> used to pause individual layers (or simulcast streams, for that matter).
>
> Peter Thatcher said:
>
> "I still think signalling is up to the app.  If the sender wants to
> signal to the receiver that start/stop/pause/resume/whatever is called
> on the sender side, in whatever signalling mechanism the app defines.
> The question I would ask is "what API does the receiver need to pass
> down information into the browser when such information has been
> signalled from the sender?"  I can't think of any of the the top of my
> head, but there might be something."
>
> [BA]  I agree that signaling is up to the app, but in addition, it looks to me like the actions taken
> as the result of a stop(), pause() or resume() may also need to be under application control
> as well.

Yes, I agree that the sender should be able to control what is sent
when it calls stop/pause/resume/whatever.

Received on Tuesday, 21 January 2014 18:59:49 UTC