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

On 06/10/2012 10:03 PM, Hutton, Andrew wrote:
> Hi Ted,
>
> See below.
>
> Regards Andy
>
>> -----Original Message----- From: Ted Hardie
>> [mailto:ted.ietf@gmail.com] Sent: 10 June 2012 18:48 To: Hutton,
>> Andrew Cc: rtcweb@ietf.org Subject: Re: [rtcweb] More Comments on
>> draft-ietf-rtcweb-use-cases-and- requirements-07
>>
>> On Sun, Jun 10, 2012 at 5:33 PM, Hutton, Andrew
>> <andrew.hutton@siemens-enterprise.com>  wrote:
>>> Hi,
>>>
>>
>>> Section 4.1.1.1 (Simple Video Communication Service) contains
>>> the
>> statement "Each user can also pause sending of media (audio, video,
>> or both) and mute incoming media".  I think this and the
>> associated requirements need some clarification for example whether
>> the requirement is to control the direction of the media and
>> therefore requires the generation of a new SDP offer with for
>> example a direction of "recvonly/inactive".
>>
>> Howdy,
>>
>> As a clarifying question, are you thinking that it is not clear
>> because non-signaling methods could achieve some of these?  That
>> is "muting" incoming media could also be accomplished entirely
>> receive side, by simply not rendering it?
>>
>
> Yes I guess so it is not clear whether the use case results in a
> local action in the browser or it whether it impacts the media and
> SDP. I want to make sure that it is possible to control the media
> direction in SDP (sendrecv/recvonly/sendonly/inactive) and have the
> browser behave appropriately.

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
- I think there has been proposals signaling this in SDP or in RTCP, but 
I don't think there was ever any conclusion

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.

>
>
>> regards,
>>
>> Ted
>>
>> The only associated requirement seems to be A8 but this does not
>> help clarify what is meant by "pause" in the use case. It needs to
>> be clarified whether the pause/resume/mute are actions within the
>> browser or are actions which result in notifications to the remote
>> user.
>>>
>>> Maybe we could add a use case which involves controlling the
>> direction of multiple streams to emulate switching between
>> different users in a multiparty call scenario.
>>>
>>>
>>> The statement "It is essential that the communication cannot be
>> eavesdropped" appears in all use cases so could be moved to section
>> 4.1 but I think it needs to be reworded in terms of the media
>> always being encrypted as I don't like the term "eavesdropped"
>> which is not defined.
>>>
>>> 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