Re: Signalling of start / stop

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.

On Tue, Jan 21, 2014 at 12:01 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> 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 17:12:58 UTC