[rtcweb] Comments to use-cases/reqs document

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

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:1.9.2.18) 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
Subject: [rtcweb] Comments to use-cases/reqs document
Precedence: list

All,

some comments to
<http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1>

(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

Comments?

Stefan

[rtcweb] Comments to use-cases/reqs document Stefan Håkansson LK
Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
Re: [rtcweb] Comments to use-cases/reqs document Stefan Håkansson LK
Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
Re: [rtcweb] Comments to use-cases/reqs document Stephan Wenger
Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
Re: [rtcweb] Comments to use-cases/reqs document Stephan Wenger
Re: [rtcweb] Comments to use-cases/reqs document Henry Sinnreich
Re: [rtcweb] Comments to use-cases/reqs document Dzonatas Sol