draft-ietf-rtcweb-use-cases-and-requirements-02.txt   draft-ietf-rtcweb-use-cases-and-requirements-03.txt 
RTCWEB Working Group C. Holmberg RTCWEB Working Group C. Holmberg
Internet-Draft S. Hakansson Internet-Draft S. Hakansson
Intended status: Informational G. Eriksson Intended status: Informational G. Eriksson
Expires: February 20, 2012 Ericsson Expires: February 29, 2012 Ericsson
August 19, 2011 August 28, 2011
Web Real-Time Communication Use-cases and Requirements Web Real-Time Communication Use-cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-02.txt draft-ietf-rtcweb-use-cases-and-requirements-03.txt
Abstract Abstract
This document describes web based real-time communication use-cases. This document describes web based real-time communication use-cases.
Based on the use-cases, the document also derives requirements Based on the use-cases, the document also derives requirements
related to the browser, and the API used by web applications to related to the browser, and the API used by web applications to
request and control media stream services provided by the browser. request and control media stream services provided by the browser.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2012. This Internet-Draft will expire on February 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4.2.1. Simple Video Communication Service . . . . . . . . . . 3 4.2.1. Simple Video Communication Service . . . . . . . . . . 3
4.2.2. Simple Video Communication Service, NAT/FW that 4.2.2. Simple Video Communication Service, NAT/FW that
blocks UDP . . . . . . . . . . . . . . . . . . . . . . 4 blocks UDP . . . . . . . . . . . . . . . . . . . . . . 4
4.2.3. Simple Video Communication Service, access change . . 4 4.2.3. Simple Video Communication Service, access change . . 4
4.2.4. Simple Video Communication Service, QoS . . . . . . . 5 4.2.4. Simple Video Communication Service, QoS . . . . . . . 5
4.2.5. Simple video communication service with 4.2.5. Simple video communication service with
inter-operator calling . . . . . . . . . . . . . . . . 5 inter-operator calling . . . . . . . . . . . . . . . . 5
4.2.6. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 6 4.2.6. Hockey Game Viewer . . . . . . . . . . . . . . . . . . 6
4.2.7. Multiparty video communication . . . . . . . . . . . . 6 4.2.7. Multiparty video communication . . . . . . . . . . . . 6
4.2.8. Multiparty on-line game with voice communication . . . 7 4.2.8. Multiparty on-line game with voice communication . . . 7
4.2.9. Distributed Music Band . . . . . . . . . . . . . . . . 7 4.2.9. Distributed Music Band . . . . . . . . . . . . . . . . 8
4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 8 4.3. Browser - GW/Server use cases . . . . . . . . . . . . . . 8
4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 8 4.3.1. Telephony terminal . . . . . . . . . . . . . . . . . . 8
4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . . 8
4.3.3. Video conferencing system with central server . . . . 9 4.3.3. Video conferencing system with central server . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 10 5.2. Browser requirements . . . . . . . . . . . . . . . . . . . 10
5.3. API requirements . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 13
7.2. Browser Considerations . . . . . . . . . . . . . . . . . . 14 7.3. Web Application Considerations . . . . . . . . . . . . . . 13
7.3. Web Application Considerations . . . . . . . . . . . . . . 14 8. Additional use cases . . . . . . . . . . . . . . . . . . . . . 13
8. Additional use cases . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document presents a few use-case of web applications that are This document presents a few use-case of web applications that are
executed in a browser and use real-time communication capabilities. executed in a browser and use real-time communication capabilities.
Based on the use-cases, the document derives requirements related to Based on the use-cases, the document derives requirements related to
the browser and the API used by web applications in the browser. the browser and the API used by web applications in the browser.
The requirements related to the browser are named "Fn" and are
described in section Section 5.2
The requirements related to the API are named "An" and are described
in the external document [webrtc_reqs]
The document focuses on requirements related to real-time media The document focuses on requirements related to real-time media
streams. Requirements related to privacy, signalling between the streams. Requirements related to privacy, signalling between the
browser and web server etc are currently not considered. browser and web server etc are currently not considered.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
skipping to change at page 10, line 9 skipping to change at page 10, line 16
4.3.3.2. Derived Requirements 4.3.3.2. Derived Requirements
F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F14, F16, F17
A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15 A1, A2, A3, A4, A5, A7, A8, A9, A10, A11, A12, A13, A15
5. Requirements 5. Requirements
5.1. General 5.1. General
This section contains requirements, derived from the use-cases in This section contains the browser requirements, derived from the use-
section 4. cases in section 4. For the API requirements refer to [webrtc_reqs].
NOTE: It is assumed that the user applications are executed on a NOTE: It is assumed that the user applications are executed on a
browser. Whether the capabilities to implement specific browser browser. Whether the capabilities to implement specific browser
requirements are implemented by the browser application, or are requirements are implemented by the browser application, or are
provided to the browser application by the underlying Operating provided to the browser application by the underlying Operating
System (OS), is outside the scope of this document. System (OS), is outside the scope of this document.
5.2. Browser requirements 5.2. Browser requirements
REQ-ID DESCRIPTION REQ-ID DESCRIPTION
skipping to change at page 12, line 23 skipping to change at page 12, line 32
media session where the data needed for establishment media session where the data needed for establishment
can be carried in SIP. can be carried in SIP.
---------------------------------------------------------------- ----------------------------------------------------------------
F25 The browser MUST support a baseline audio and F25 The browser MUST support a baseline audio and
video codec video codec
---------------------------------------------------------------- ----------------------------------------------------------------
F26 The browser MUST be able to send streams to a F26 The browser MUST be able to send streams to a
peer in presence of NATs that block UDP traffic. peer in presence of NATs that block UDP traffic.
---------------------------------------------------------------- ----------------------------------------------------------------
5.3. API requirements
REQ-ID DESCRIPTION
----------------------------------------------------------------
A1 The web application MUST be able to ask the
browser for permission to use cameras
and microphones as input devices.
----------------------------------------------------------------
A2 The web application MUST be able to control how
streams generated by input devices are used.
----------------------------------------------------------------
A3 The web application MUST be able to control the
local rendering of streams (locally generated streams
and streams received from a peer).
----------------------------------------------------------------
A4 The web application MUST be able to initiate
sending of stream/stream components to a peer.
----------------------------------------------------------------
A5 The web application MUST be able to control the
media format (codec) to be used for the streams
sent to a peer.
NOTE: The level of control depends on whether
the codec negotiation is handled by the browser
or the web application.
----------------------------------------------------------------
A6 After a media stream has been established, the
web application MUST be able to modify the media
format for streams sent to a peer.
----------------------------------------------------------------
A7 The web application MUST be made aware of
whether the establishment of a stream with a
peer was successful or not.
----------------------------------------------------------------
A8 The web application MUST be able to
pause/unpause the sending of a stream to a peer.
----------------------------------------------------------------
A9 The web application MUST be able to mute/unmute
a stream received from a peer.
----------------------------------------------------------------
A10 The web application MUST be able to cease the
sending of a stream to a peer.
----------------------------------------------------------------
A11 The web application MUST be able to cease
processing and rendering of a stream received
from a peer.
----------------------------------------------------------------
A12 The web application MUST be informed when a
stream from a peer is no longer received.
----------------------------------------------------------------
A13 The web application MUST be informed when high
loss rates occur.
----------------------------------------------------------------
A14 It MUST be possible for the web application to
control panning, mixing and other processing for
individual streams.
----------------------------------------------------------------
A15 The web application MUST be able to identify the
context of a stream.
----------------------------------------------------------------
A16 It MUST be possible for the web application to
send and receive datagrams to/from peer
----------------------------------------------------------------
A17 It MUST be possible for the web application to
indicate the type of audio signal (speech, audio)
----------------------------------------------------------------
6. IANA Considerations 6. IANA Considerations
TBD TBD
7. Security Considerations 7. Security Considerations
7.1. Introduction 7.1. Introduction
A malicious web application might use the browser to perform Denial A malicious web application might use the browser to perform Denial
Of Service (DOS) attacks on NAT infrastructure, or on peer devices. Of Service (DOS) attacks on NAT infrastructure, or on peer devices.
Also, a malicious web application might silently establish outgoing, Also, a malicious web application might silently establish outgoing,
and accept incoming, streams on an already established connection. and accept incoming, streams on an already established connection.
Based on the identified security risks, this section will describe Based on the identified security risks, this section will describe
security considerations for the browser and web application. security considerations for the browser and web application.
skipping to change at page 15, line 4 skipping to change at page 13, line 40
The web application is expected to ensure user consent in sending and The web application is expected to ensure user consent in sending and
receiving media streams. receiving media streams.
8. Additional use cases 8. Additional use cases
Several additional use cases have been discusses. At this point Several additional use cases have been discusses. At this point
these use cases are not included as requirement deriving use cases these use cases are not included as requirement deriving use cases
for different reasons (lack of documentation, overlap with existing for different reasons (lack of documentation, overlap with existing
use cases, lack of consensus). For completeness these additional use use cases, lack of consensus). For completeness these additional use
cases are listed below: cases are listed below:
1. Use cases regarding different situations when being invited to a 1. Use cases regarding different situations when being invited to a
"session", e.g. browser open, browser open but another tab "session", e.g. browser open, browser open but another tab
active, browser open but active in session, browser closed, .... active, browser open but active in session, browser closed, ....
(Matthew Kaufman); discussed at webrtc meeting (Matthew Kaufman); discussed at webrtc meeting
2. Different TURN provider scenarios (Cullen Jennings); discussed 2. Different TURN provider scenarios (Cullen Jennings); discussed
at the webrtc meeting at the webrtc meeting
3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/ 3. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/
rtcweb/current/msg00525.html rtcweb/current/msg00525.html
4. Local Recording (John Ewell) at webrtc meeting 4. Local Recording and Remote recording (John): Discussed a _lot_
5. Remote recording (John) http://www.ietf.org/mail-archive/web/ on the mail lists (rtcweb as well as public-webrtc late August
rtcweb/current/msg00472.html 2011. Not concluded at time of writing.
6. Emergency access for disabled (Bernard Aboba) http://
5. Emergency access for disabled (Bernard Aboba) http://
www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html
7. Clue use cases (Roni Even) http://tools.ietf.org/html/ 6. Clue use cases (Roni Even) http://tools.ietf.org/html/
draft-ietf-clue-telepresence-use-cases-01 draft-ietf-clue-telepresence-use-cases-01
8. Rohan red cross (Cullen Jennings); http://www.ietf.org/ 7. Rohan red cross (Cullen Jennings); http://www.ietf.org/
mail-archive/web/rtcweb/current/msg00323.html mail-archive/web/rtcweb/current/msg00323.html
9. Remote assistance (ala VNC or RDP) - User is helping another 8. Remote assistance (ala VNC or RDP) - User is helping another
user on their computer with either view-only or view-with- user on their computer with either view-only or view-with-
control, either of just the browser of the the entire screen. ht control, either of just the browser of the the entire screen. ht
tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html tp://www.ietf.org/mail-archive/web/rtcweb/current/msg00543.html
10. Security camera/baby monitor usage http://www.ietf.org/ 9. Security camera/baby monitor usage http://www.ietf.org/
mail-archive/web/rtcweb/current/msg00543.html mail-archive/web/rtcweb/current/msg00543.html
11. Large multiparty session http://www.ietf.org/mail-archive/web/ 10. Large multiparty session http://www.ietf.org/mail-archive/web/
rtcweb/current/msg00530.html rtcweb/current/msg00530.html
9. Acknowledgements 9. Acknowledgements
Harald Alvestrand and Ted Hardie have provided comments and feedback Harald Alvestrand and Ted Hardie have provided comments and feedback
on the draft. on the draft.
Harald Alvestrand and Cullen Jennings have provided additional use- Harald Alvestrand and Cullen Jennings have provided additional use-
cases. cases.
Thank You to everyone in the RTCWEB community that have provided Thank You to everyone in the RTCWEB community that have provided
comments, feedback and improvement proposals on the draft content. comments, feedback and improvement proposals on the draft content.
10. Change Log 10. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-rtcweb-use-cases-and-requirements-02
o Removed desrciption/list of API requirements, instead
o Reference to W3C webrtc_reqs document for API requirements
Changes from draft-ietf-rtcweb-ucreqs-01 Changes from draft-ietf-rtcweb-ucreqs-01
o Changed Intended status to Information o Changed Intended status to Information
o Changed "Ipr" to "trust200902" o Changed "Ipr" to "trust200902"
o Added use case "Simple video communication service, NAT/FW that o Added use case "Simple video communication service, NAT/FW that
blocks UDP", and derived new req F26 blocks UDP", and derived new req F26
o Added use case "Distributed Music Band" and derived new req A17 o Added use case "Distributed Music Band" and derived new req A17
o Added F24 as requirement derived from use case "Simple video o Added F24 as requirement derived from use case "Simple video
communication service with inter-operator calling" communication service with inter-operator calling"
o Added section "Additional use cases" o Added section "Additional use cases"
o Added text about ID handling to multiparty with central server use o Added text about ID handling to multiparty with central server use
case case
o Re-phrased A1 slightly o Re-phrased A1 slightly
Changes from draft-ietf-rtcweb-ucreqs-00 Changes from draft-ietf-rtcweb-ucreqs-00
o - Reshuffled: Just two main groups of use cases (b2b and b2GW/ o - Reshuffled: Just two main groups of use cases (b2b and b2GW/
Server); removed some specific use cases and added them instead as Server); removed some specific use cases and added them instead as
flavors to the base use case (Simple video communciation) flavors to the base use case (Simple video communciation)
skipping to change at page 17, line 4 skipping to change at page 15, line 43
Changes from draft-holmberg-rtcweb-ucreqs-00 Changes from draft-holmberg-rtcweb-ucreqs-00
o - Mapping between use-cases and requirements added (Harald o - Mapping between use-cases and requirements added (Harald
Alvestrand, 090311) Alvestrand, 090311)
o - Additional security considerations text (Harald Alvestrand, o - Additional security considerations text (Harald Alvestrand,
090311) 090311)
o - Clarification that user applications are assumed to be executed o - Clarification that user applications are assumed to be executed
by a browser (Ted Hardie, 080311) by a browser (Ted Hardie, 080311)
o - Editorial corrections and clarifications o - Editorial corrections and clarifications
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
[webrtc_reqs]
"Webrt requirements,
http://dev.w3.org/2011/webrtc/editor/webrtc_reqs.html".
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 20 change blocks. 
97 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/