[rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07)

Changing the subject line again, since we're discussing how to do mute, 
not whether to do it.....

On 06/14/2012 11:15 AM, Hutton, Andrew wrote:
> On 13 June 2012 15:37 Stefan Hakansson wrote:
>
>> This is my personal understanding:
>>
>> - the API (and this part has been there for a long time) allows the
>> application to disable/enable individual tracks of MediaStreams
>> - So say you have a MediaStream (one audio track, one video track in
>> this example) that is rendered using a video element; disabling audio
>> would lead to silence, disabling video to that the video stops
>> - The question is: what should happen if the MediaStream is connected
>> to
>> a PeerConnection and sent to a peer?
>> - using recvonly does not seem appropriate as that would stop all
>> ssrc:s
>> belonging to the same m-line - and the app only disabled one
>> - one option could be to simply stop sending the RTP packets for this
>> track. I don't know how reliable that would be.
> In the case of outgoing media then I think mute should simply disconnect the source (e.g. microphone) and there is no impact on RTP other than depending on the codec silence will be transmitted or SID frame etc. There is also no impact on RTCP which continues.
>
> This is different to setting the direction to be recvonly which would completely stop the outgoing RTP packets and would normally be signaled to the remote party. This should of course be achieved using setLocalDescription.

Just to add to the complexity of the "mute" case:

When an audio stream is muted, should there be comfort noise sent?
If yes, what should determine the noise level?

(people who've never had to deal with comfort noise can safely tune out 
at this point)

>
>
>> - I think there has been proposals signaling this in SDP or in RTCP,
>> but
>> I don't think there was ever any conclusion
> If we are talking about a local mute then I don't see any need to signal this but again this is different to changing the direction attribute in SDP.
>
>> For the other part, muting incoming media, this is simple: the app (at
>> receiving browser) could just disable the tracks it wants in the
>> incoming MediaStreams. A related question is if this should be signaled
>> back to the sender (so it could stop sending). This is essentially a
>> question of efficiency/optimization, and nothing stops the app from
>> signaling that now using an app specific protocol (perhaps carried over
>> the data channel), but perhaps this should be brought into SDP or RTCP.
>>
> If the application wants to ask the remote party to pause sending of RTP then it should surely do this in SDP by setting the direction attribute appropriately (i.e. sendonly or inactive).
>
> Regards
> Andy
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb