RE: Signalling of start / stop

A possible way to go about this could be to either:

Add a state {enabled, disabled or active, inactive} attribute to RTCRtpSender and RTCRtpReciever.
OR
Throw an onerror event if the user tries to RTCRtpSender::start() after having previously called RTCRtpReciever ::stop().
Add RTCRtpSender::pause()/resume() and RTCRtpReciever ::pause()/resume() methods to temporarily stop sending if that is desired.



Adalberto Foresti
Principal Program Manager
Microsoft Open Technologies, Inc.
A Subsidiary of Microsoft Corporation


From: Harald Alvestrand [mailto:hta@google.com]
Sent: Tuesday, January 14, 2014 10:01 AM
To: Peter Thatcher
Cc: Stefan Håkansson LK; public-orca@w3.org
Subject: Re: Signalling of start / stop

WRT stop(), I put this in -msid:

   o  When a description is updated to no longer list the msid value on
      any m-line, the recipient can signal to its application that the
      media stream has been closed.

   In addition to signaling that the track is closed when it disappears
   from the SDP, the track will also be signaled as being closed when
   all associated SSRCs have disappeared by the rules of [RFC3550]
   section 6.3.4 (BYE packet received) and 6.3.5 (timeout).

This was the result of some discussion. I think it would be nice to consistently apply this.



On Tue, Jan 14, 2014 at 6:36 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:
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<mailto: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<mailto: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
>>>
>>>
>>>
>>
>