Re: Missing Features: Stream Control

I am not sure we need pause/resume, or reject/accept in v1.

That said, I like your proposals for solving this. I have a couple of 
comments in-line below.

On 10/18/13 6:27 PM, Adam Roach wrote:
> We've recently had some implementors reach out to ask about how to do
> certain things with the WebRTC interfaces, and I've been pretty well
> unable to turn up anything that makes a lot of sense for most of the
> interesting stream-control interfaces.
>
> Some of this is talked about here, with an implication that the author
> of this wiki page, at least, would be willing to leave some of them
> unspecified for the first version of WebRTC:
>
> http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions
>
> Unfortunately, I don't think we can leave stream pause/unpause or stream
> rejection/removal out of the first version of the document. The good
> news is that I think we have all the interfaces necessary to do these
> things; we just need to spell out clear semantics for them.
>
> As a high-level thumbnail sketch, here's what I think makes sense:
>
>  1. To pause a track that you are sending, set enabled=false on a
>     MediaStreamTrack that you have added to a PeerConnection. This
>     information will cause the PeerConnection to stop sending the
>     associated RTP. Maybe this triggers an onnegotiationneeded to set
>     the corresponding m-line to recvonly or inactive and maybe it just
>     stops sending the stream; I'm not sure which makes more sense.

I really think we should signal. How would the receiving end otherwise 
know the difference between pause and a broken connection (at least 
until the next RTCP or ICE packet arrives)?

(And I would personally prefer if we could signal via some in-band 
mechanism rather than having to do a SDP O/A, but that's another discussion)

>       * To unpause, set enabled back to true, and the steps are reversed
>       * To pause all the MSTs associated with a MediaStream, use enabled
>         on the MediaStream itself.

I don't think there is any "enabled" on MediaStream.

>
>  2. To pause a track that you are receiving, set enabled=false on the
>     MediaStreamTrack that you received from the PeerConnection via
>     onaddstream. This will cause the MST to stop providing media to
>     whatever sink it has been wired to, and trigger an
>     onnegotiationneeded event. The subsequent CreateOffer sets the
>     corresponding m-line to sendonly or inactive, as appropriate.
>       * As above, this operation can also be performed on a MediaStream
>         to impact all of its tracks.
>
>  3. To reject a track that has been offered, call stop() on the
>     corresponding MediaStreamTrack after it has been received via
>     onaddstream, but before calling CreateAnswer. This will cause it to
>     be rejected with a port number of zero.
>
>  4. To remove a track from an ongoing session, call stop() on the
>     corresponding MediaStreamTrack object. This will (a) immediately
>     stop transmitting associated RTP, and (b) trigger an
>     onnegotiationneeded event.
>       * If both the sending and receiving MST associated with that
>         m-line have been stop()ed, then the subsequent CreateOffer sets
>         the port on the corresponding m-line to zero.
>       * If only one of the two MSTs associated with that m-line has been
>         stop()ed, then the subsequent CreateOffer sets the corresponding
>         m-line to sendonly, receiveonly, or inactive, as appropriate.

I like this. It is analogous to when a MediaStreamTrack that is sourced 
by a microphone or camera is stopped - that makes the device stop. And 
this is sort of the same.

>
> Does this make sense to everyone? It seems pretty clean, easy to
> specify, and reasonable to implement. Best of all, we're not changing
> any currently defined interfaces, just providing clear semantics for
> certain operations.
>
> /a
>

Received on Friday, 18 October 2013 17:54:36 UTC