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

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Sun, 10 June 2012 15:33 UTC

Return-Path: <andrew.hutton@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E719421F85C6 for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 08:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Q8ANUtvRv1 for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 08:33:20 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5912C21F85AA for <rtcweb@ietf.org>; Sun, 10 Jun 2012 08:33:20 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CF2701EB84E3 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 17:33:18 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Sun, 10 Jun 2012 17:33:18 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07
Thread-Index: AQHNRXWCXu14Kzuy2EiOwUV/KKjYHJbzfIYA
Date: Sun, 10 Jun 2012 15:33:17 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net>
References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <F3D4ABD6AB47084B84337CF4F3446A464B2F11B52E@ESESSCMS0362.eemea.ericsson.se> <AAB6A6B6-BEC7-436C-B1EB-2C117596C7C6@cisco.com> <F3D4ABD6AB47084B84337CF4F3446A464B2F2631AC@ESESSCMS0362.eemea.ericsson.se>
In-Reply-To: <F3D4ABD6AB47084B84337CF4F3446A464B2F2631AC@ESESSCMS0362.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.27.249.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2012 15:33:21 -0000

Hi,

Some comments on draft-ietf-rtcweb-use-cases-and-requirements-07.

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".  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