Re: Signalling of start / stop

On an RtcSender or RtpReceiver, stop() is meant to be final.  If we
want to temporarily stop sending something, I think we'd need
something different like an "active" flag somewhere.

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