On 2014-01-21 01:35, Bernard Aboba wrote:
Harald Alvestrand said:
“WRT stop(), I put this in -msid:
o When a description is updated to no longer list the msid value on
any m-line, the recipient can signal to its application that the
media stream has been closed.
In addition to signaling that the track is closed when it disappears
from the SDP, the track will also be signaled as being closed when
all associated SSRCs have disappeared by the rules of [RFC3550]
section 6.3.4 (BYE packet received) and 6.3.5 (timeout).
This was the result of some discussion. I think it would be nice to
consistently apply this.”
[BA] The text above applies to individual video streams as well as for “application layer” simulcast where each stream is an individual MediaStreamTrack. However, there are some additional wrinkles that need to be taken into account for “native” simulcast or scalable video coding, where it may be desirable to stop, pause or resume an individual stream or layer which might be represented as a “Channel” rather than an individual MediaStreamTrack.
Bernard, I agree to that we might want to go there (i.e. individually control individual stream/layer). But my question is a more basic one: if we have API methods to stop, pause, resume track/channel/layer (pick what you want) - how is this signaled between endpoints?
Harald put forth what is in the msid draft for (permanent) stop. But what about pause/resume?
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.
Received on Tuesday, 21 January 2014 08:07:24 UTC