- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 13 Jan 2014 13:27:48 -0800
- To: Peter Thatcher <pthatcher@google.com>
- Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-orca@w3.org" <public-orca@w3.org>
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 >> >> >> >
Received on Monday, 13 January 2014 21:28:16 UTC