idnits 2.17.1 draft-alvestrand-constraints-resolution-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2012) is 4177 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-burnett-rtcweb-constraints-registry-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-01 == Outdated reference: A later version (-05) exists of draft-lennox-mmusic-sdp-source-selection-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Informational October 21, 2012 5 Expires: April 24, 2013 7 Resolution Constraints in Web Real Time Communications 8 draft-alvestrand-constraints-resolution-01 10 Abstract 12 This document specifies the constraints necessary for a Javascript 13 application to successfully indicate to a browser that supports 14 WebRTC what resolutions it desires on a video stream. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 24, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Disposition of this text . . . . . . . . . . . . . . . . . 3 58 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Scenario: Resolution change . . . . . . . . . . . . . . . . 4 60 2.2. Scenario: Constrained bandwidth . . . . . . . . . . . . . . 5 61 3. Syntax and Mapping Examples . . . . . . . . . . . . . . . . . . 6 62 3.1. Examples with GetUserMedia . . . . . . . . . . . . . . . . 6 63 3.2. SDP mappings . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Appendix A. Changes from -00 to -01 . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 There are a number of scenarios where it's useful for a WebRTC 76 application to indicate to the WebRTC implementation in the supported 77 browser what the desired characteristics of a video stream are. 78 These include, but are not limited to: 80 o Specifying a minimum desired resolution for a given application, 81 in order to control the user experience or resource tradeoffs made 82 by the browser to favour a particular stream 84 o Specifying a maximum desired resolution for a given stream, in 85 order to save some resource (bandwidth, CPU....), possibly outside 86 of the browser where the browser can't tell that it's exceeding a 87 constraint 89 o Specifying resolutions that are a reasonable fit for the current 90 usage of the video stream, for instance fitting with the number of 91 pixels available on the part of a device's display surface that is 92 devoted to displaying this video stream 94 o Specifying the shape of a video stream, in order to fit the video 95 onto a display surface without the need for black bars or image 96 distortion 98 Similar considerations apply for framerate. 100 1.1. Disposition of this text 102 This draft is written in order to get something specific out to refer 103 to during spec-writing and implementation. The text may eventually 104 get merged into the JSEP specification, [I-D.ietf-rtcweb-jsep]. 106 2. Usage Scenarios 108 These constraints are usable in several places: 110 o As constraints to the getUserMedia call 111 [W3C.WD-mediacapture-streams-20120628], where they serve to guide 112 the configuration of the camera obtained, and may influence the 113 choice of camera. 115 o As constraints to the addStream call on a PeerConnection 116 [W3C.WD-webrtc-20120821], where they serve to guide the 117 configuration of the codec that encodes the video content for 118 transmission. 120 o As constraints applied to an existing local video stream using the 121 "change constraints" API, where it may cause the video engine to 122 reconfigure the device or codec for that particular stream. 124 o As constraints applied to an incoming video stream using the 125 "change constrains" API on a MediaStreamTrack, where it serves to 126 inform the video engine about the desirable properties of the 127 video track, which may lead to the video engine choosing to 128 reencode the video and/or signal a remote video source that it 129 wishes certain constraints to be put in place. 131 All of the constraints may be meaningful in both "mandatory" and 132 "optional" forms. 134 Consider the following (simplified) model of a video stream through a 135 WebRTC application: 137 |<-------------- Browser A -------------------->| 138 Camera ---> Mediastream A ---> Peerconnection A ------+ 139 |<------- Application A ---------->| | 140 v ^ v 141 Signalling channel Internet (media) 142 v ^ | 143 |<------- Application B ---------->| | 144