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

On 06/14/2012 11:21 AM, Harald Alvestrand wrote:
> 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?

To me it feels as that ideally we should stop sending RTP (and make the 
other end know that the track is disabled). If we go to comfort noise 
state, the track in the MediaStream at the other end would still be 
active (even though what is played could be very low level comfort 
noise), but to reflect the local state the remote track should go to 
"muted", shouldn't it?

>
> (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
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb