Missing Features: Stream Control

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.
      * 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.

 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.

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