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

On Wed, Jul 24, 2013 at 1:14 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Wed, Jul 24, 2013 at 12:35 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> 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 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 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.
>
> Ah ok, I didn't realise that. As I said: I was mostly focused on the
> "hold" use case.
>
>
>>> >> 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().
>
>
> If that works for the browsers (i.e. if the MediaStream object without
> the PeerConnection give sufficient context to do the SDP
> renegotiation), I'd be happy with this.

BTW: It definitely has to be on a MediaStream, because then you can
hold either a video or an audio track or both. Holding a video track
would be like switching from video+audio to audio-only, which would be
nicely covered by the same API.

I'd really like to get this introduced. Is it sufficient to mention
this on the mailing list or do we have to register a bug?

Thanks,
Silvia.

Received on Wednesday, 24 July 2013 08:57:43 UTC