W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 23 Jul 2013 19:35:25 -0700
Message-ID: <CABcZeBMotcMq-v1GCO6PSRMZ7DCSzg2=dHmoZ-u9j3gHjZfpzA@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Jul 23, 2013 at 7:22 PM, Silvia Pfeiffer

> 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:


"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>
is still associated with a track, must enable the track if the new value is
true, and disable it otherwise."

"Each track in a
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

Received on Wednesday, 24 July 2013 02:36:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC