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/