draft-ietf-rtcweb-use-cases-and-requirements-12.txt   draft-ietf-rtcweb-use-cases-and-requirements-13.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: April 17, 2014 Ericsson Expires: August 10, 2014 Ericsson
October 14, 2013 February 6, 2014
Web Real-Time Communication Use-cases and Requirements Web Real-Time Communication Use-cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-12.txt draft-ietf-rtcweb-use-cases-and-requirements-13.txt
Abstract Abstract
This document describes web based real-time communication use-cases. This document describes web based real-time communication use-cases.
Requirements on the browser functionality are derived from use-cases. Requirements on the browser functionality are derived from the use-
cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 17, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4 3.2. Common requirements . . . . . . . . . . . . . . . . . . . 4
3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4 3.3. Browser-to-browser use-cases . . . . . . . . . . . . . . 4
3.3.1. Simple Video Communication Service . . . . . . . . . 4 3.3.1. Simple Video Communication Service . . . . . . . . . 4
3.3.2. Simple Video Communication Service, NAT/FW that 3.3.2. Simple Video Communication Service, NAT/Firewall that
blocks UDP . . . . . . . . . . . . . . . . . . . . . 5 blocks UDP . . . . . . . . . . . . . . . . . . . . . 5
3.3.3. Simple Video Communication Service, FW that only 3.3.3. Simple Video Communication Service, Firewall that
allows http . . . . . . . . . . . . . . . . . . . . . 5 only allows traffic via a HTTP Proxy . . . . . . . . 5
3.3.4. Simple Video Communication Service, global service 3.3.4. Simple Video Communication Service, global service
provider . . . . . . . . . . . . . . . . . . . . . . 5 provider . . . . . . . . . . . . . . . . . . . . . . 5
3.3.5. Simple Video Communication Service, enterprise 3.3.5. Simple Video Communication Service, enterprise
aspects . . . . . . . . . . . . . . . . . . . . . . . 6 aspects . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.6. Simple Video Communication Service, access change . . 7 3.3.6. Simple Video Communication Service, access change . . 7
3.3.7. Simple Video Communication Service, QoS . . . . . . . 7 3.3.7. Simple Video Communication Service, QoS . . . . . . . 7
3.3.8. Simple Video Communication Service with sharing . . . 8 3.3.8. Simple Video Communication Service with screen
sharing . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.9. Simple Video Communication Service with file exchange 8 3.3.9. Simple Video Communication Service with file exchange 8
3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 8 3.3.10. Hockey Game Viewer . . . . . . . . . . . . . . . . . 8
3.3.11. Multiparty video communication . . . . . . . . . . . 9 3.3.11. Multiparty video communication . . . . . . . . . . . 9
3.3.12. Multiparty on-line game with voice communication . . 10 3.3.12. Multiparty on-line game with voice communication . . 10
3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 11 3.4. Browser - GW/Server use cases . . . . . . . . . . . . . . 10
3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 11 3.4.1. Telephony terminal . . . . . . . . . . . . . . . . . 11
3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 11 3.4.2. Fedex Call . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. Video conferencing system with central server . . . . 11 3.4.3. Video conferencing system with central server . . . . 11
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Browser requirements . . . . . . . . . . . . . . . . . . 13 4.2. Browser requirements . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Browser Considerations . . . . . . . . . . . . . . . . . 16 6.2. Browser Considerations . . . . . . . . . . . . . . . . . 16
6.3. Web Application Considerations . . . . . . . . . . . . . 17 6.3. Web Application Considerations . . . . . . . . . . . . . 17
7. Additional use-cases . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Normative References . . . . . . . . . . . . . . . . . . . . 23
10. Normative References . . . . . . . . . . . . . . . . . . . . 24 Appendix A. API requirements . . . . . . . . . . . . . . . . . . 23
Appendix A. API requirements . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document presents a few use-cases of web applications that are This document presents a few use-cases 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.
In most of the use-cases all end-user clients are web applications, In most of the use-cases all end-user clients are web applications,
but there are some use-cases where at least one of the end-user but there are some use-cases where at least one of the end-user
client is of another type (e.g. a telephone). clients is of another type (e.g. a mobile phone or a SIP UA).
Based on the use-cases, the document derives requirements related to Based on the use-cases, the document derives requirements related to
browser functionality. These requirements are named "Fn", where n is browser functionality. These requirements are named "Fn", where n is
an integer, and are described in Section 4.2. an integer, and are described in Section 4.2.
This document was developed in an initial phase of the work with This document was developed in an initial phase of the work with
rather minor updates at later stages. It has not really served as a rather minor updates at later stages. It has not really served as a
tool in deciding features or scope for the WGs efforts so far. It is tool in deciding features or scope for the WGs efforts so far. It is
proposed to be used in a later phase to evaluate the protocols and proposed to be used in a later phase to evaluate the protocols and
solutions developed by the WG. solutions developed by the WG.
skipping to change at page 4, line 8 skipping to change at page 4, line 4
o Clients can be on IPv6-only o Clients can be on IPv6-only
o Clients can be on dual-stack o Clients can be on dual-stack
o Clients can be connected to networks with different throughput o Clients can be connected to networks with different throughput
capabilities capabilities
o Clients can be on variable-media-quality networks (wireless) o Clients can be on variable-media-quality networks (wireless)
o Clients can be on congested networks o Clients can be on congested networks
o Clients can be on firewalled networks with no UDP allowed o Clients can be on firewalled networks with no UDP allowed
o Clients can be on networks with a NAT using any type of Mapping o Clients can be on networks with a NAT using any type of Mapping
and Filtering behaviors (as described in RFC4787). and Filtering behaviors (as described in RFC4787).
3.2. Common requirements 3.2. Common requirements
The requirements retrived from the "Simple Video Communication The requirements retrived from the Simple Video Communication Service
Service" by default apply to all other use-cases, and are considred use-case (Section 3.3.1) by default apply to all other use-cases, and
common. For each individual use-case, only the additional are considred common. For each individual use-case, only the
requirements are listed. The following requirements can be retrieved additional requirements are listed. The following requirements can
from, and apply to, each of the documented use-cases. For each be derived from, and apply to, each of the documented use-cases. For
individual use-case, only requirements that are not part of the each individual use-case, only requirements that are not part of the
common requirements are listed. common requirements are listed.
3.3. Browser-to-browser use-cases 3.3. Browser-to-browser use-cases
3.3.1. Simple Video Communication Service 3.3.1. Simple Video Communication Service
3.3.1.1. Description 3.3.1.1. Description
Two or more users have loaded a video communication web application Two or more users have loaded a video communication web application
into their browsers, provided by the same service provider, and into their browsers, provided by the same service provider, and
skipping to change at page 5, line 10 skipping to change at page 5, line 5
It is essential that media and data be encrypted, authenticated and It is essential that media and data be encrypted, authenticated and
integrity protected on a per-packet basis and that media and data integrity protected on a per-packet basis and that media and data
packets failing the integrity check not be delivered to the packets failing the integrity check not be delivered to the
application. application.
The application gives the users the opportunity to stop it from The application gives the users the opportunity to stop it from
exposing the host IP address to the application of the other user. exposing the host IP address to the application of the other user.
Any session participant can end the session at any time. Any session participant can end the session at any time.
The two users may be using communication devices of different makes, The two users may be using communication devices with different
with different operating systems and browsers from different vendors. operating systems and browsers from different vendors.
The web service monitors the quality of the service (focus on quality The web service monitors the quality of the service (focus on quality
of audio and video) the end-users experience. of audio and video) the end-users experience.
3.3.1.2. Common Requirements 3.3.1.2. Common Requirements
F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39 F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39
A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26
3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP 3.3.2. Simple Video Communication Service, NAT/Firewall that blocks UDP
3.3.2.1. Description 3.3.2.1. Description
This use-case is almost identical to the Simple Video Communication This use-case is almost identical to the
Service use-case (Section 3.3.1). The difference is that one of the Simple Video Communication Service use-case (Section 3.3.1). The
users is behind a NAT that blocks UDP traffic. difference is that one of the users is behind a NAT/Firewall that
blocks UDP traffic.
3.3.2.2. Additional Requirements 3.3.2.2. Additional Requirements
F29 F29
3.3.3. Simple Video Communication Service, FW that only allows http 3.3.3. Simple Video Communication Service, Firewall that only allows
traffic via a HTTP Proxy
3.3.3.1. Description 3.3.3.1. Description
This use-case is almost identical to the Simple Video Communication This use-case is almost identical to the
Service use-case (Section 3.3.1). The difference is that one of the Simple Video Communication Service use-case (Section 3.3.1). The
users is behind a FW that only allows traffic via a HTTP Proxy. difference is that one of the users is behind a Firewall that only
allows traffic via a HTTP Proxy.
3.3.3.2. Additional Requirements 3.3.3.2. Additional Requirements
F37 F37
3.3.4. Simple Video Communication Service, global service provider 3.3.4. Simple Video Communication Service, global service provider
3.3.4.1. Description 3.3.4.1. Description
This use-case is almost identical to the Simple Video Communication This use-case is almost identical to the
Service use-case (Section 3.3.1). Simple Video Communication Service use-case (Section 3.3.1).
What is added is that the service provider is operating over large What is added is that the service provider is operating over large
geographical areas (or even globally). geographical areas (or even globally).
Assuming that ICE will be used, this means that the service provider Assuming that ICE will be used, this means that the service provider
would like to be able to provide several STUN and TURN servers (via would like to be able to provide several STUN and TURN servers (via
the app) to the browser; selection of which one(s) to use is part of the app) to the browser; selection of which one(s) to use is part of
the ICE processing. Other reasons for wanting to provide several the ICE processing. Other reasons for wanting to provide several
STUN and TURN servers include support for IPv4 and IPv6, load STUN and TURN servers include support for IPv4 and IPv6, load
balancing and redundancy. balancing and redundancy.
Note that ICE support being mandatory does not preclude a WebRTC
endpoint from supporting additional traversal mechanisms.
3.3.4.2. Additional Requirements 3.3.4.2. Additional Requirements
F31 F31
A22 A22
3.3.5. Simple Video Communication Service, enterprise aspects 3.3.5. Simple Video Communication Service, enterprise aspects
3.3.5.1. Description 3.3.5.1. Description
This use-case is similar to the Simple Video Communication Service This use-case is similar to the Simple Video Communication Service
use-case (Section 3.3.1). use-case (Section 3.3.1).
What is added is aspects when using the service in enterprises. ICE What is added is aspects when using the service in enterprises. ICE
is assumed in the further description of this use-case. is assumed in the further description of this use-case.
An enterprise that uses a RTCWEB based web application for An enterprise that uses a RTCWEB based web application for
communication desires to audit all RTCWEB based application session communication desires to audit all RTCWEB based application sessions
used from inside the company towards any external peer. To be able used from inside the company towards any external peer. To be able
to do this they deploy a TURN server that straddle the boundary to do this they deploy a TURN server that straddles the boundary
between the internal network and the external. between the internal and the external network.
The firewall will block all attempts to use STUN with an external The firewall will block all attempts to use STUN with an external
destination unless they go to the enterprise auditing TURN server. destination unless they go to the enterprise auditing TURN server.
In cases where employees are using RTCWEB applications provided by an In cases where employees are using RTCWEB applications provided by an
external service provider they still want to have the traffic to stay external service provider they still want the traffic to stay inside
inside their internal network and in addition not load the straddling their internal network and in addition not load the straddling TURN
TURN server, thus they deploy a STUN server allowing the RTCWEB server, thus they deploy a STUN server allowing the RTCWEB client to
client to determine its server reflexive address on the internal determine its server reflexive address on the internal side. Thus
side. Thus enabling cases where peers are both on the internal side enabling cases where peers are both on the internal side to connect
to connect without the traffic leaving the internal network. It must without the traffic leaving the internal network. It must be
be possible to configure the browsers used in the enterprise with possible to configure the browsers used in the enterprise with
network specific STUN and TURN servers. This should be possible to network specific STUN and TURN servers. This should be possible to
achieve by auto-configuration methods. The RTCWEB functionality will achieve by auto-configuration methods. The RTCWEB functionality will
need to utilize both network specific STUN and TURN resources and need to utilize both network specific STUN and TURN resources and
STUN and TURN servers provisioned by the web application. STUN and TURN servers provisioned by the web application.
3.3.5.2. Additional Requirements 3.3.5.2. Additional Requirements
F32 F32
3.3.6. Simple Video Communication Service, access change 3.3.6. Simple Video Communication Service, access change
3.3.6.1. Description 3.3.6.1. Description
This use-case is almost identical to the Simple Video Communication This use-case is almost identical to the
Service use-case (Section 3.3.1). The difference is that the user Simple Video Communication Service use-case (Section 3.3.1). The
changes network access during the session: difference is that the user changes network access during the
session.
The communication device used by one of the users have several The communication device used by one of the users has several network
network adapters (Ethernet, WiFi, Cellular). The communication adapters (Ethernet, WiFi, Cellular). The communication device is
device is accessing the Internet using Ethernet, but the user has to accessing the Internet using Ethernet, but the user has to start a
start a trip during the session. The communication device trip during the session. The communication device automatically
automatically changes to use WiFi when the Ethernet cable is removed changes to use WiFi when the Ethernet cable is removed and then moves
and then moves to cellular access to the Internet when moving out of to cellular access to the Internet when moving out of WiFi coverage.
WiFi coverage. The session continues even though the access method The session continues even though the access method changes.
changes.
3.3.6.2. Additional Requirements 3.3.6.2. Additional Requirements
F26 F26
3.3.7. Simple Video Communication Service, QoS 3.3.7. Simple Video Communication Service, QoS
3.3.7.1. Description 3.3.7.1. Description
This use-case is almost identical to the Simple Video Communication This use-case is almost identical to the
Service, access change use-case (Section 3.3.6). The use of Quality Simple Video Communication Service, access change use-case
of Service (QoS) capabilities is added: (Section 3.3.6). The use of Quality of Service (QoS) capabilities is
added:
The user in the previous use case that starts a trip is behind a The user in the previous use case that starts a trip is behind a
common residential router that supports prioritization of traffic. common residential router that supports prioritization of traffic.
In addition, the user's provider of cellular access has QoS support In addition, the user's provider of cellular access has QoS support
enabled. The user is able to take advantage of the QoS support both enabled. The user is able to take advantage of the QoS support both
when accessing via the residential router and when using cellular. when accessing via the residential router and when using cellular.
3.3.7.2. Additional Requirements 3.3.7.2. Additional Requirements
F24, F26 F24, F26
3.3.8. Simple Video Communication Service with sharing 3.3.8. Simple Video Communication Service with screen sharing
3.3.8.1. Description 3.3.8.1. Description
This use-case has the audio and video communication of the Simple This use-case has the audio and video communication of the
Video Communication Service use-case (Section 3.3.1). Simple Video Communication Service use-case (Section 3.3.1).
But in addition to this, one of the users can share what is being But in addition to this, one of the users can share what is being
displayed on her/his screen with a peer. The user can choose to displayed on her/his screen with a peer. The user can choose to
share the entire screen, part of the screen (part selected by the share the entire screen, part of the screen (part selected by the
user) or what a selected application displays with the peer. user) or what a selected application displays with the peer.
3.3.8.2. Additional Requirements 3.3.8.2. Additional Requirements
F30 F30
A21 A21
3.3.9. Simple Video Communication Service with file exchange 3.3.9. Simple Video Communication Service with file exchange
3.3.9.1. Description 3.3.9.1. Description
This use-case has the audio and video communication of the Simple This use-case has the audio and video communication of the
Video Communication Service use-case (Section 3.3.1). Simple Video Communication Service use-case (Section 3.3.1).
But in addition to this, the users can send and receive files stored But in addition to this, the users can send and receive files stored
in the file system of the device used. in the file system of the device used.
3.3.9.2. Additional Requirements 3.3.9.2. Additional Requirements
F30, F33 F30, F33
A21, A24 A21, A24
skipping to change at page 9, line 32 skipping to change at page 9, line 26
the desktop screen, with picture-in-picture thumbnails of the rear the desktop screen, with picture-in-picture thumbnails of the rear
facing camera and the desktop camera (self-view). On the display of facing camera and the desktop camera (self-view). On the display of
the mobile phone the game is shown (front facing camera) with the mobile phone the game is shown (front facing camera) with
picture-in-picture thumbnails of the rear facing camera (self-view) picture-in-picture thumbnails of the rear facing camera (self-view)
and the desktop camera. As the most important stream in this phase and the desktop camera. As the most important stream in this phase
is the video showing the game, the application used in the talent is the video showing the game, the application used in the talent
scout's mobile sets higher priority for that stream. scout's mobile sets higher priority for that stream.
3.3.10.2. Additional Requirements 3.3.10.2. Additional Requirements
F17, F34 F17, F24
A17, A23 A17, A23
3.3.11. Multiparty video communication 3.3.11. Multiparty video communication
3.3.11.1. Description 3.3.11.1. Description
In this use-case is the Simple Video Communication Service use-case In this use-case, the Simple Video Communication Service use-case
(Section 3.3.1) is extended by allowing multiparty sessions. No (Section 3.3.1) is extended by allowing multiparty sessions. No
central server is involved - the browser of each participant sends central server is involved - the browser of each participant sends
and receives streams to and from all other session participants. The and receives streams to and from all other session participants. The
web application in the browser of each user is responsible for web application in the browser of each user is responsible for
setting up streams to all receivers. setting up streams to all receivers.
In order to enhance intelligibility, the web application pans the In order to enhance the user experience, the web application renders
audio from different participants differently when rendering the the audio coming from different particiapants so that it is
audio. This is done automatically, but users can change how the experienced to come from different spatial locations. This is done
different participants are placed in the (virtual) room. In addition automatically, but users can change how the different participants
the levels in the audio signals are adjusted before mixing. are placed in the (virtual) room. In addition the levels in the
audio signals are adjusted before mixing.
Another feature intended to enhance the use experience is that the Another feature intended to enhance the use experience is that the
video window that displays the video of the currently speaking peer video window that displays the video of the currently speaking peer
is highlighted. is highlighted.
Each video stream received is by default displayed in a thumbnail Each video stream received is by default displayed in a thumbnail
frame within the browser, but users can change the display size. frame within the browser, but users can change the display size.
Note: What this use-case adds in terms of requirements is Note: What this use-case adds in terms of requirements is
capabilities to send streams to and receive streams from several capabilities to send streams to and receive streams from several
skipping to change at page 10, line 48 skipping to change at page 10, line 44
Note: the difference regarding local audio processing compared to the Note: the difference regarding local audio processing compared to the
"Multiparty video communication" use-case is that other sound objects "Multiparty video communication" use-case is that other sound objects
than the streams must be possible to be included in the than the streams must be possible to be included in the
spatialization and mixing. "Other sound objects" could for example spatialization and mixing. "Other sound objects" could for example
be a file with the sound of the tank; that file could be stored be a file with the sound of the tank; that file could be stored
locally or remotely. locally or remotely.
3.3.12.2. Additional Requirements 3.3.12.2. Additional Requirements
F12, F13, F14, F15, F16, F18 F12, F13, F14, F15, F16, F18, F23, F24
A13, A14, A15, A16, A17, A18, A23 A13, A14, A15, A16, A17, A18, A23
3.4. Browser - GW/Server use cases 3.4. Browser - GW/Server use cases
3.4.1. Telephony terminal 3.4.1. Telephony terminal
3.4.1.1. Description 3.4.1.1. Description
A mobile telephony operator allows its customers to use a web browser A mobile telephony operator allows its customers to use a web browser
to access their services. After a simple log in the user can place to access their services. After a simple log in the user can place
and receive calls in the same way as when using a normal mobile and receive calls in the same way as when using a normal mobile
phone. When a call is received or placed, the identity is shown in phone. When a call is received or placed, the identity is shown in
the same manner as when a mobile phone is used. the same manner as when a mobile phone is used.
skipping to change at page 11, line 30 skipping to change at page 11, line 27
on line, so they are available and can be clicked to call, and be on line, so they are available and can be clicked to call, and be
used to present the identity of an incoming call. If the callee is used to present the identity of an incoming call. If the callee is
not in your phone contacts the number is displayed. Furthermore, not in your phone contacts the number is displayed. Furthermore,
your call logs are available, and updated with the calls made/ your call logs are available, and updated with the calls made/
received from the browser. And for people receiving calls made from received from the browser. And for people receiving calls made from
the web browser the usual identity (i.e. the phone number of the the web browser the usual identity (i.e. the phone number of the
mobile phone) will be presented. mobile phone) will be presented.
3.4.1.2. Additional Requirements 3.4.1.2. Additional Requirements
F21 F21, F27
3.4.2. Fedex Call 3.4.2. Fedex Call
3.4.2.1. Description 3.4.2.1. Description
Alice uses her web browser with a service that allows her to call Alice uses her web browser with a service that allows her to call
PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to
hear the initial prompts from the fedex Interactive Voice Responder hear the initial prompts from the fedex Interactive Voice Responder
(IVR) and when the IVR says press 1, there should be a way for Alice (IVR) and when the IVR says press 1, there should be a way for Alice
to navigate the IVR. to navigate the IVR.
skipping to change at page 12, line 4 skipping to change at page 11, line 44
PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to
hear the initial prompts from the fedex Interactive Voice Responder hear the initial prompts from the fedex Interactive Voice Responder
(IVR) and when the IVR says press 1, there should be a way for Alice (IVR) and when the IVR says press 1, there should be a way for Alice
to navigate the IVR. to navigate the IVR.
3.4.2.2. Additional Requirements 3.4.2.2. Additional Requirements
F21, F22 F21, F22
3.4.3. Video conferencing system with central server 3.4.3. Video conferencing system with central server
3.4.3.1. Description 3.4.3.1. Description
An organization uses a video communication system that supports the An organization uses a video communication system that supports the
establishment of multiparty video sessions using a central conference establishment of multiparty video sessions using a central conference
server. server.
The browser of each participant send an audio stream (type in terms The browser of each participant sends an audio stream (type in terms
of mono, stereo, 5.1, ... depending on the equipment of the of mono, stereo, 5.1, ... depending on the equipment of the
participant) to the central server. The central server mixes the participant) to the central server. The central server mixes the
audio streams (and can in the mixing process naturally add effects audio streams (and can in the mixing process naturally add effects
such as spatialization) and sends towards each participant a mixed such as spatialization) and sends towards each participant a mixed
audio stream which is played to the user. audio stream which is played to the user.
The browser of each participant sends video towards the server. For The browser of each participant sends video towards the server. For
each participant one high resolution video is displayed in a large each participant one high resolution video is displayed in a large
window, while a number of low resolution videos are displayed in window, while a number of low resolution videos are displayed in
smaller windows. The server selects what video streams to be smaller windows. The server selects what video streams to be
skipping to change at page 12, line 35 skipping to change at page 12, line 30
be displayed is short. be displayed is short.
All participants are authenticated by the central server, and All participants are authenticated by the central server, and
authorized to connect to the central server. The participants are authorized to connect to the central server. The participants are
identified to each other by the central server, and the participants identified to each other by the central server, and the participants
do not have access to each others' credentials such as e-mail do not have access to each others' credentials such as e-mail
addresses or login IDs. addresses or login IDs.
Note: This use-case adds requirements on support for fast stream Note: This use-case adds requirements on support for fast stream
switches F7, on encryption of media and on ability to traverse very switches F7, on encryption of media and on ability to traverse very
restrictive FWs. There exist several solutions that enable the restrictive Firewalls. There exist several solutions that enable the
server to forward one high resolution and several low resolution server to forward one high resolution and several low resolution
video streams: a) each browser could send a high resolution, but video streams: a) each browser could send a high resolution, but
scalable stream, and the server could send just the base layer for scalable stream, and the server could send just the base layer for
the low resolution streams, b) each browser could in a simulcast the low resolution streams, b) each browser could in a simulcast
fashion send one high resolution and one low resolution stream, and fashion send one high resolution and one low resolution stream, and
the server just selects or c) each browser sends just a high the server just selects or c) each browser sends just a high
resolution stream, the server transcodes into low resolution streams resolution stream, the server transcodes into low resolution streams
as required. as required.
3.4.3.2. Additional Requirements 3.4.3.2. Additional Requirements
skipping to change at page 13, line 26 skipping to change at page 13, line 19
system, is outside the scope of this document. system, is outside the scope of this document.
4.2. Browser requirements 4.2. Browser requirements
REQ-ID DESCRIPTION REQ-ID DESCRIPTION
--------------------------------------------------------------- ---------------------------------------------------------------
F1 The browser must be able to use microphones and F1 The browser must be able to use microphones and
cameras as input devices to generate streams. cameras as input devices to generate streams.
---------------------------------------------------------------- ----------------------------------------------------------------
F2 The browser must be able to send streams and F2 The browser must be able to send streams and
data to a peer in the presence of NATs. data to a peer in the presence of NATs.
---------------------------------------------------------------- ----------------------------------------------------------------
F3 Transmitted streams and data must be rate F3 Transmitted streams and data must be rate
controlled (meaning that the browser must, regardless controlled (meaning that the browser must, regardless
of application behavior, reduce send rate when of application behavior, reduce send rate when
there is congestion). there is congestion).
---------------------------------------------------------------- ----------------------------------------------------------------
F4 The browser must be able to receive, process and F4 The browser must be able to receive, process and
render streams and data ("render" does not render streams and data ("render" does not
apply for data) from peers. apply for data) from peers.
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 15, line 4 skipping to change at page 14, line 45
based Interactive voice response (IVR) System based Interactive voice response (IVR) System
---------------------------------------------------------------- ----------------------------------------------------------------
F23 The browser must be able to send short F23 The browser must be able to send short
latency unreliable datagram traffic to a latency unreliable datagram traffic to a
peer browser [RFC5405]. peer browser [RFC5405].
---------------------------------------------------------------- ----------------------------------------------------------------
F24 The browser should be able to take advantage F24 The browser should be able to take advantage
of available capabilities (supplied by network of available capabilities (supplied by network
nodes) to prioritize voice, video and data nodes) to prioritize voice, video and data
appropriately. appropriately.
---------------------------------------------------------------- ----------------------------------------------------------------
F25 The browser should use encoding of streams F25 The browser should use encoding of streams
suitable for the current rendering (e.g. suitable for the current rendering (e.g.
video display size) and should change parameters video display size) and should change parameters
if the rendering changes during the session if the rendering changes during the session
---------------------------------------------------------------- ----------------------------------------------------------------
F26 It must be possible to move from one network F26 The communication session must survive across a
interface to another one change of the network interface used by the
session
---------------------------------------------------------------- ----------------------------------------------------------------
F27 The browser must be able to initiate and F27 The browser must be able to initiate and
accept a media session where the data needed accept a media session where the data needed
for establishment can be carried in SIP. for establishment can be carried in SIP.
---------------------------------------------------------------- ----------------------------------------------------------------
F28 The browser must support a baseline audio and F28 The browser must support a baseline audio and
video codec video codec
---------------------------------------------------------------- ----------------------------------------------------------------
F29 The browser must be able to send streams and F29 The browser must be able to send streams and
data to a peer in the presence of NATs that data to a peer in the presence of NATs and
block UDP traffic. Firewalls that block UDP traffic.
---------------------------------------------------------------- ----------------------------------------------------------------
F30 The browser must be able to use the screen (or F30 The browser must be able to generate streams
a specific area of the screen) or what a certain using the entire user display, a specific area
application displays on the screen to generate of the user's display or the information being
streams. displayed by a specific application.
---------------------------------------------------------------- ----------------------------------------------------------------
F31 The browser must be able to use several STUN F31 The browser must be able to use several STUN
and TURN servers and TURN servers
---------------------------------------------------------------- ----------------------------------------------------------------
F32 There browser must support that STUN and TURN F32 The browser must support the use of STUN and TURN
servers to use are supplied by other entities servers that are supplied by entities other than
than via the web application (i.e. the network the web application (i.e. the network provider).
provider).
---------------------------------------------------------------- ----------------------------------------------------------------
F33 The browser must be able to send reliable F33 The browser must be able to send reliable
data traffic to a peer browser. data traffic to a peer browser.
---------------------------------------------------------------- ----------------------------------------------------------------
F34 The browser must support prioritization of
streams and data.
----------------------------------------------------------------
F35 The browser must enable verification, given F35 The browser must enable verification, given
the right circumstances and by use of other the right circumstances and by use of other
trusted communication, of that streams and trusted communication, that streams and
data received have not been manipulated by data received have not been manipulated by
any party. any party.
---------------------------------------------------------------- ----------------------------------------------------------------
F36 The browser must encrypt, authenticate and F36 The browser must encrypt, authenticate and
integrity protect media and data on a integrity protect media and data on a
per-packet basis, and must drop incoming media per-packet basis, and must drop incoming media
and data packets that fail the per-packet and data packets that fail the per-packet
integrity check. In addition, the browser integrity check. In addition, the browser
must support a mechanism for cryptographically must support a mechanism for cryptographically
binding media and data security keys to the binding media and data security keys to the
user identity (see R-ID-BINDING in [RFC5479]). user identity (see R-ID-BINDING in [RFC5479]).
---------------------------------------------------------------- ----------------------------------------------------------------
F37 The browser must be able to send streams and F37 The browser must be able to send streams and
data to a peer in the presence of FWs that only data to a peer in the presence of Firewalls that only
allows traffic via a HTTP Proxy, when FW policy allows traffic via a HTTP Proxy, when Firewall policy
allows WebRTC traffic. allows WebRTC traffic.
---------------------------------------------------------------- ----------------------------------------------------------------
F38 The browser must be able to collect statistics, F38 The browser must be able to collect statistics,
related to the transport of audio and video related to the transport of audio and video
between peers, needed to estimate quality of between peers, needed to estimate quality of
experience. experience.
---------------------------------------------------------------- ----------------------------------------------------------------
F39 The browser must make it possible to set up a F39 The browser must make it possible to set up a
call between two parties without one party call between two parties without one party
learning the other party's host IP address. learning the other party's host IP address.
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 17, line 40 skipping to change at page 17, line 32
finished. finished.
The browser needs to ensure that the stream negotiation procedures The browser needs to ensure that the stream negotiation procedures
are not seen as Denial Of Service (DOS) by other entities. are not seen as Denial Of Service (DOS) by other entities.
6.3. Web Application Considerations 6.3. Web Application Considerations
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.
7. Additional use-cases 7. Acknowledgements
Several additional use-cases have been discussed. At this point
these use-cases are not included as requirement deriving use-cases
for different reasons (lack of documentation, overlap with existing
use-cases, lack of consensus). For completeness these additional
use-cases are listed below:
1. Use-cases regarding different situations when being invited to a
"session", e.g. browser open, browser open but another tab
active, browser open but active in session, browser closed, ....
(Matthew Kaufman); discussed at webrtc meeting
2. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb
/current/msg00525.html, followed up by Stephan Wenger
3. Local Recording and Remote recording (John): Discussed a _lot_
on the mail lists (rtcweb as well as public-webrtc) August and
September 2011. Concrete proposal: http://www.ietf.org/mail-
archive/web/rtcweb/current/msg01006.html (remote) and http://
www.ietf.org/mail-archive/web/rtcweb/current/msg00734.html
(local)
4. Emergency access for disabled (Bernard Aboba) http://
www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html
5. Clue use-cases (Roni Even) http://tools.ietf.org/html/draft-
ietf-clue-telepresence-use-cases-01
6. Rohan red cross (Cullen Jennings); http://www.ietf.org/mail-
archive/web/rtcweb/current/msg00323.html
7. Security camera/baby monitor usage http://www.ietf.org/mail-
archive/web/rtcweb/current/msg00543.html
8. Large multiparty session http://www.ietf.org/mail-archive/web/
rtcweb/current/msg00530.html
9. Call center http://www.ietf.org/mail-archive/web/rtcweb/current/
msg04203.html
10. Enterprise policies http://www.ietf.org/mail-archive/web/rtcweb/
current/msg04271.html
11. Low-complex multiparty central node http://www.ietf.org/mail-
archive/web/rtcweb/current/msg04430.html
12. Multiparty central node that is not allowed to decipher http://
www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html
8. Acknowledgements
The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin The authors wish to thank Bernard Aboba, Gunnar Hellstrom, Martin
Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric Thomson, Lars Eggert, Matthew Kaufman, Emil Ivov, Eric Rescorla, Eric
Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale Burger, John Leslie, Dan Wing, Richard Barnes, Barry Dingle, Dale
Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald Worley, Ted hardie, Mary Barnes, Dan Burnett, Stephan Wenger, Harald
Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the Alvestrand, Cullen Jennings, Andrew Hutton and everyone else in the
RTCWEB community that have provided comments, feedback, text and RTCWEB community that have provided comments, feedback, text and
improvement proposals on the document. improvement proposals on the document.
9. Change Log 8. 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-10 Changes from draft-ietf-rtcweb-use-cases-and-requirements-10
o Described that the API requirements are really from a W3C o Described that the API requirements are really from a W3C
perspective and are supplied as an appendix in the introduction. perspective and are supplied as an appendix in the introduction.
Moved API requirements to an Appendix. Moved API requirements to an Appendix.
o Removed the "Conventions" section with the key-words and reference o Removed the "Conventions" section with the key-words and reference
to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase.
o Added a note on the proposed use of the document to the o Added a note on the proposed use of the document to the
introduction. introduction.
o Removed the note talking about WS from the "FW that only allows o Removed the note talking about WS from the "Firewall that only
http" use-case. allows http" use-case.
o Removed the word "Skype" that was used as example in one of the o Removed the word "Skype" that was used as example in one of the
use-cases. use-cases.
o Clarified F3 (the req saying the everything the browser sends must o Clarified F3 (the req saying the everything the browser sends must
be rate controlled). be rate controlled).
o Removed the TBD saying we need to define reasonable levels from o Removed the TBD saying we need to define reasonable levels from
the requirement saying that quality must be good even in presence the requirement saying that quality must be good even in presence
of packet losses (F5), and changed "must" to "should" (Based on a of packet losses (F5), and changed "must" to "should" (Based on a
skipping to change at page 20, line 32 skipping to change at page 19, line 23
o Changed "video communication session" to "audiovisual o Changed "video communication session" to "audiovisual
communication session. communication session.
Changes from draft-ietf-rtcweb-use-cases-and-requirements-08 Changes from draft-ietf-rtcweb-use-cases-and-requirements-08
o Changed "eavesdropping" to "wiretapping" and referenced RFC2804. o Changed "eavesdropping" to "wiretapping" and referenced RFC2804.
o Removed informal ref webrtc_req; that document has been abandoned o Removed informal ref webrtc_req; that document has been abandoned
by the W3C webrtc WG. by the W3C webrtc WG.
o Added use-case where one user is behind a FW that only allows o Added use-case where one user is behind a Firewall that only
http; derived req. F37. allows http; derived req. F37.
o Changed F24 slightly; MUST-> SHOULD, inserted "available". o Changed F24 slightly; MUST-> SHOULD, inserted "available".
o Added a clause to "Simple video communication service" saying that o Added a clause to "Simple video communication service" saying that
the service provider monitors the quality of service, and derived the service provider monitors the quality of service, and derived
reqs F38 and A26. reqs F38 and A26.
Changes from draft-ietf-rtcweb-use-cases-and-requirements-07 Changes from draft-ietf-rtcweb-use-cases-and-requirements-07
o Added "and data exchange" to 1. Introduction. o Added "and data exchange" to 1. Introduction.
skipping to change at page 23, line 16 skipping to change at page 22, line 4
o Removed description/list of API requirements, instead o Removed description/list of API requirements, instead
o Reference to W3C webrtc_reqs document for API requirements 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/Firewall
o Added use case "Simple video communication service, NAT/FW that 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
skipping to change at page 24, line 28 skipping to change at page 23, line 15
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
10. Normative References 9. 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.
[RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May
2000. 2000.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November for Application Designers", BCP 145, RFC 5405, November
2008. 2008.
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009. Protocols", RFC 5479, April 2009.
 End of changes. 58 change blocks. 
162 lines changed or deleted 117 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/