Re: Signalling of start / stop

• From: Peter Thatcher <pthatcher@google.com>
• Date: Mon, 13 Jan 2014 11:59:42 -0800
• To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
• Cc: "public-orca@w3.org" <public-orca@w3.org>
• Message-ID: <CAJrXDUGh+Sjr-a1=EtFbV=dLYem_EwOfTyGPMuV380YTFp-25g@mail.gmail.com>

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
>
>
>

Received on Monday, 13 January 2014 20:00:51 UTC