RE: Signalling of start / stop

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.

Received on Tuesday, 21 January 2014 18:51:38 UTC