Re: Signalling of start / stop

RTCP BYE is unreliable and cannot be used to definitively detect the end of
stream. Normally you would need to signal based on some sort of timeout
RTCP/RTP timeout as well but this can delay end of stream detection by
quite a bit (up to a few minutes).

_____________
Roman Shpount


On Mon, Jan 13, 2014 at 4:27 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> I imagine that the sender would send an RTCP BYE.  That would cause
> the onended event to fire on the affected tracks even if the receiver
> didn't do the signaling.
>
> On 13 January 2014 11:59, Peter Thatcher <pthatcher@google.com> wrote:
> > I think that would be up to the application.  Either on the sending
> > end it sends a "hey, I'm stopping, and here's why" signal, or on the
> > receiving end it sends a "hey, please stop sending" signal.  Either
> > way, the application should know why it called .stop() and be able to
> > signal it between sender and receiver.  Same for start.
> >
> > I don't see how that effects the API at all.  It's up to the app and
> > how it defines the signalling, and the app has all the tools it needs.
> >
> > On Sat, Jan 11, 2014 at 5:16 AM, Stefan Håkansson LK
> > <stefan.lk.hakansson@ericsson.com> wrote:
> >> (I tried to send this yesterday - but the list does not seem to like me)
> >>
> >> Has there been any discussion on how to signal stop (and start) for
> >> RTCStream/RTCTrack/RtpSender/RtcReceiver?
> >>
> >> I think it should be signaled - the receiving UA should be able to
> >> distinguish sender stopping (which I presume should fire onmute on the
> >> received track) from e.g. a lot of packet losses.
> >>
> >> Stefan
> >>
> >>
> >>
> >
>
>