Re: Signalling of start / stop

On 13/01/14 21:00, Peter Thatcher 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.

Re-reading [1][2], I think my question was actually two different ones.

In [1] a RTCTrack (or Stream) can be started and stopped, as well as 
removed. I take that as stop not being final (you'd then remove), but 
rather saying "I won't send anything for a while, but may resume later".

In [2], stop is final; no way to temporarily stop the transmission (or 
reception).

I don't know if there is a need for "stop sending temporarily" or not, 
but regardless I think it must be specced out what happens when stop is 
called (and perhaps called only on the sending side - perhaps this app 
is not well behaved and does not signal in the app layer).


[1] https://rawgithub.com/openpeer/ortc/master/ortc.html#rtctrack*
[2] http://lists.w3.org/Archives/Public/public-orca/2014Jan/0000.html

>
> 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 Tuesday, 14 January 2014 11:59:12 UTC