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

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.

> 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