[rtcweb] Comments to use-cases/reqs document

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Wed, 29 June 2011 10:50 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 55DEB9E8029 for <rtcweb@ietfa.amsl.com>; Wed, 29 Jun 2011 03:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.072
X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eU7OwzBHofUY for <rtcweb@ietfa.amsl.com>; Wed, 29 Jun 2011 03:50:29 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 586FF9E801F for <rtcweb@ietf.org>; Wed, 29 Jun 2011 03:50:29 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-ac-4e0b0374070d
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain []) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.77.09774.4730B0E4; Wed, 29 Jun 2011 12:50:28 +0200 (CEST)
Received: from [] ( by esessmw0184.eemea.ericsson.se ( with Microsoft SMTP Server id; Wed, 29 Jun 2011 12:50:28 +0200
Message-ID: <4E0B0373.3040509@ericsson.com>
Date: Wed, 29 Jun 2011 12:50:27 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [rtcweb] Comments to use-cases/reqs document
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: Wed, 29 Jun 2011 10:50:30 -0000


some comments to

(yes, I am one of the authors, but the document now reflects what had
been discussed on mail list up to last week)

1. The "Simple video communication service with inter-operator calling"
use case derives the requirement "F25: The browser MUST support a
baseline audio and video codec". While I think this requirement makes
sense it seems a bit odd in this context. To me it rather belongs to a
case where the users use different browsers (and perhaps different
communication devices using different OSes).

2. Some clarifications should be added to "Multiparty video 
communication" and "Video conferencing system with central server" (as 
pointed out in the Minutes from the interim).

3. The "Video Size Change" use case derives F22; but that is already
derived in "Simple Video Communication Service". I propose to remove the 
"Video Size Change" use case.

4. The "Fedex Call" use case derives the DTMF req F19 "The browser must
be able to insert DTMF signals in a media stream". I think we made a
mistake here, what Cullen said was "there should be a way to navigate
the IVR". I think this is a more relevant requirement at this stage. I
think the API reg A16 should be removed as it is not clear if this would 
be done via an API.

5. To me it would make sense to add the NIC change and QoS use cases as
extensions to the "Simple video communication service" use case (as is
done with "inter-operator calling".

6. I think the structure is a bit strange. E.g. the "Multiparty on-line
game with voice communication" use case is not under browser-to-browser
even though it is clearly browser-to-browser.

So, this is what I propose the structure to look like:

     4.  Use-cases
       4.1.  Introduction
       4.2.  Browser-to-browser use-cases
         4.2.1.  Simple Video Communication Service
         4.2.2.  Simple Video Communication Service, access change
         4.2.3.  Simple Video Communication Service, QoS
         4.2.4.  Simple video communication service with
                 inter-operator calling
         4.2.5.  Hockey Game Viewer
         4.2.6.  Multiparty video communication
         4.2.7.  Multiparty on-line game with voice communication
       4.3.  Browser - GW/Server use cases
         4.3.1.  Telephony terminal
         4.3.2.  Fedex Call
         4.3.3.  Video conferencing system with central server

With the following changes:
4.2.1 Extended to say that different browsers (and perhaps operating
systems) are used, F25 derived here

4.2.6 Clarifications in text
4.3.3 Clarifications in text

F19 Changed to talk about navigating in IVR. A16 (DTMF API) removed.

F23 (change netw I/F) derived in 4.2.2

F21 (QoS) derived in 4.2.3

F24 (SIP able to carry session setup data) derived in 4.2.4