Re: muting/hold (was Re: Cisco's position on the WebRTC API)

On Tue, Jul 23, 2013 at 7:22 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> Hi Eric,
>
> On Wed, Jul 24, 2013 at 12:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > I think you're conflating a number of features here:
> >
> > 1. Stop sending media to the other side. This needs to be done with
> > some API call on the media stream to mute it. In Firefox, at least
> > you do this by setting .enabled to false. I'm not sure if there
> > is WG consensus that this is the right plan. Regardless, no
> > signaling is required.
> >
> > 2. Stop playing the media from the other side. This is just done
> > by muting the element the MS is playing into.
> >
> > 3. Tell the other side to stop sending media (often called "hold").
> > It's not clear how one would do that. Note that this also plays into
> > the question of how one rejects an incoming MST offer.
>
> Good, let's get an API for each one of these! My particular focus was
> on the last on, which needs SDP renegotation FAIK, but it seems at
> least (1.) isn't specified either yet.
>

Well, MSTs already have .enabled:

http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes-1

"The MediaStreamTrack.enabled attribute, on getting, must return the last
value to which it was set. On setting, it must be set to the new value, and
then, if the MediaStreamTrack<http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>
object
is still associated with a track, must enable the track if the new value is
true, and disable it otherwise."

"Each track in a
MediaStream<http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStream>
object
can be disabled, meaning that it is muted in the object's output. All
tracks are initially enabled."


So while I think the intention of .enabled is moderately clear, it could
also probably stand to be more precise.






>
> >> Do take my suggestion for a .mute() function on MediaStream as such a
> >> concrete proposal.
> >
> >
> > I think this is more complicated than you suggest, as indicated above. I
> > agree
> > something is needed.
>
> Good!
>
> About (1.) - is there any intention to add .enabled to MediaStream?
>
> About (3.) How about a .hold() function on a PeerConnection with a
> MediaStream as the parameter?
>

An alternative would be to set the remote MST.enabled to false. This would
have the advantage that one could imagine rejecting an MST by doing
MST.stop().

-Ekr