idnits 2.17.1 draft-alvestrand-rtcweb-resolution-00.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 date (April 30, 2012) is 4377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-burnett-rtcweb-constraints-registry-00 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-06 ** Downref: Normative reference to an Informational draft: draft-ietf-rtcweb-use-cases-and-requirements (ref. 'I-D.ietf-rtcweb-use-cases-and-requirements') == Outdated reference: A later version (-05) exists of draft-lennox-mmusic-sdp-source-selection-03 == Outdated reference: A later version (-01) exists of draft-westerlund-avtext-codec-operation-point-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 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: Standards Track April 30, 2012 5 Expires: November 1, 2012 7 RTCWEB Resolution Negotiation 8 draft-alvestrand-rtcweb-resolution-00 10 Abstract 12 This draft offers a proposal for a fragment of the SDP usage rules 13 for RTCWEB: Requirements for supporting resolution negotiation. 15 It proposes to use SDP both for initial and within-call resolution 16 configuration, and suggests that COP should be mentioned as an 17 optional, not mandatory, mechanism. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 1, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Initial negotiation of parameters . . . . . . . . . . . . . . 4 62 4. Per-stream declaration of desired video resolution . . . . . . 5 63 4.1. SDP-based per-stream declaration . . . . . . . . . . . . . 5 64 4.2. COP-based per-stream declaration . . . . . . . . . . . . . 6 65 4.3. Tradeoffs discussion . . . . . . . . . . . . . . . . . . . 6 66 5. Usage considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Relation to WebRTC API constraints . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 This draft offers a proposal for a fragment of the SDP usage rules 79 for RTCWEB: Requirements for supporting resolution negotiation. 81 It proposes to use SDP, [RFC6236] in particular, both for initial and 82 within-call resolution configuration, with the "a=recv- 83 ssrc:imageattr" mechanism from 84 [I-D.lennox-mmusic-sdp-source-selection] as a per-stream mechanism, 85 and suggests that Codec Operation Point (COP) specified in 86 [I-D.westerlund-avtext-codec-operation-point] should be mentioned as 87 an optional, not mandatory, mechanism. 89 2. Requirements 91 The relevant requirement for video resolution negotiation from the 92 RTCWEB use cases document 93 [I-D.ietf-rtcweb-use-cases-and-requirements] is: 95 o F25 The browser SHOULD use encoding of streams suitable for the 96 current rendering (e.g. video display size) and SHOULD change 97 parameters if the rendering changes during the session. 99 The scenarios from which this requirement is derived are: 101 o 4.2.1 Simple Video Communication Service - user changes size of 102 video during the session. 104 o 4.2.2 Simple Video Communication Service, NAT/FW that blocks UDP - 105 as above 107 o 4.2.3 Simple Video Communication Service, global service provider 108 - as above 110 o 4.2.4 Simple Video Communication Service, enterprise aspects - as 111 above 113 o 4.2.5 Simple Video Communication Service, access change - 114 bandwidth available changes dramatically during call (wired 115 Ethernet to 3G) 117 o 4.2.6 Simple Video Communication Service, QoS - as 4.2.5 119 o 4.2.7 Simple Video Communication Service with sharing - as above 121 o 4.2.8 Simple video communication service with inter-operator 122 callling - as above 124 o 4.2.10 Multiparty video communication - user changes size of video 126 o (4.3.3 Video conferencing system with central server does NOT list 127 F25 as a derived requirement, but notes that "it is important that 128 the delay from when a video stream is selected for display until 129 the video can be displayed is short"). 131 Formulating the requirements in a form more amenable to 132 implementation, there needs to be specified functions that allow the 133 implementation: 135 o To negotiate a maximum spatial resolution for all videos at call 136 setup time 138 o To negotiate a maximum temporal resolution ("frame rate") across 139 all videos at call setup time 141 o To negotiate other parameters as needed to ensure that the sender 142 will not send a stream that the receiver is unable to handle. 144 o To indicate the desire of the recipient for a particular spatial 145 or temporal resolution on a particular video source, at any given 146 time during the call 148 o To indicate the intent of the sender to send a video source in a 149 particular spatial or temporal resolution, at any given time 150 during the call 152 This document does not mention other requirements. 154 3. Initial negotiation of parameters 156 We assume that the normal (payload-dependent) procedures for codec 157 negotiation are sufficient to negotiate any codec parameters needed 158 to ensure that the decoder can handle all incoming streams. 160 After the initial negotiation, the following variables MUST have a 161 known value for each RTP session (represented by one or more m= 162 lines): 164 o The maximum X-resolution of any handlable video stream 166 o The maximum Y-resolution of any handlable video stream 168 o The maximum bitrate in bits per second 169 o The maximum framerate in frames per second 171 An RTCWEB client MUST support negotiation of resolution using the 172 "imageattr" attribute, as documented in [RFC6236]. 174 An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and 175 MAY choose to support only the 1.0 value of the "sar" attribute. 177 The interpretation of the negotiation is that any video stream in the 178 m= line containing the a=imageattr attribute will have a resolution 179 within the bounds established by the negotiation. 181 An RTCWEB client MUST support negotiation of the "a=framerate" 182 attribute, as specified in [RFC4566] section 6. Note that this is an 183 upper bound on framerate; there is no lower bound negotiated. 185 These bounds MAY be renegotiated over the course of the call, but 186 MUST NOT be renegotiated to render any currently transmitted video 187 stream out of bounds 189 These bounds may be supplemented by payload-specific mechanisms, and 190 there is no guarantee that all resolutions within the bounds can be 191 supported. 193 4. Per-stream declaration of desired video resolution 195 4.1. SDP-based per-stream declaration 197 An RTCWEB client MUST support per-SSRC requests for video 198 resolutions, as described in 199 [I-D.lennox-mmusic-sdp-source-selection]. To be precise, it MUST 200 support the a=remote-ssrc: framerate: and a=remote- 201 ssrc:imageattr: attributes. 203 This satisfies the requirement to indicate the desire of the 204 recipient for a particular spatial or temporal resolution. 206 We assume that the media sent from a sender to a receiver contains 207 enough information inside the media format to tell what the 208 resolution and framerate is. 210 The bounds specified for a single stream MUST be within the bounds 211 previously negotiated for the whole session. 213 This mechanism does not form a negotiation; as specified in the 214 referenced document, it is a declaration by the recipient of what 215 stream formats he desires, and the sender will respond by changing 216 the video he sends. The sender SHOULD honor the requests by the 217 receiver. 219 The mere fact that a stream is within the bounds negotiated for the 220 session is not a sufficient condition for guaranteeing that the 221 stream will be accepted; any number of issues, including temporary 222 lack of resources at the recipient. Thus, the sender MUST always be 223 prepared for one or more media streams to be refused by the 224 recipient. 226 4.2. COP-based per-stream declaration 228 An RTCWEB client MAY support the COP mechanism 229 [I-D.westerlund-avtext-codec-operation-point] to negotiate the 230 resolution of video within the limits established by the SDP 231 negotiation without the need for additional SDP exchanges. 233 4.3. Tradeoffs discussion 235 This section may be deleted before publication as an RFC; its main 236 purpose is to discuss the decision to make the SDP-based mechanism a 237 MUST and the COP-based mechanism a MAY. 239 Both mechanisms work by having the receiver declare a wish for a 240 resolution, and the sender switching to that resolution. The main 241 differences are: 243 o In SDP, given the nature of the RTCWEB signalling model, the 244 notification that a change is needed must be sent to the 245 Javascript, which then has to use the createOffer mechanism to 246 create a suitable SDP object, and use whatever mechanism is used 247 for negotiation to send that request to the sender. 249 o In COP, the decision to signal can possibly be taken either at 250 Javascript level or inside the browser, but once the decision is 251 taken, all further messaging is done by the browser using RTCP 252 packets; Javascript is not involved. 254 o For SDP, signalling follows the signalling path, which may be via 255 a data channel along the media path, or may be via a completely 256 different mechanism. 258 o For COP, signalling always follows the media path's return path. 260 o For SDP, the unbounded nature of the imageattr= specification 261 allows a wide variety of sizes to be requested, including possibly 262 unsuitable ones. 264 o For COP, the list of alternatives is created explicitly using the 265 Operation Point mechanism. 267 o For SDP, the signalling transport is (presumably) done using a 268 reliable transport 270 o For COP, timeout and retransmission must be implemented in the 271 requester. 273 o For SDP, if imageattr= is already supported, the changes to the 274 parsers involved are small. 276 o For COP, support involves embedding a completely new functionality 277 set within the RTCP components of the RTP-supporting libraries. 279 o For SDP, the defining draft specifies some other mechanisms that 280 are not mentioned here, such as "pause". 282 o For COP, the defining draft specifies some configurations that are 283 not part of the RTCWEB requirements set, such as multicast. 285 o SDP does not consider the case of substreams for scalable video 286 media. 288 o COP deos consider configuration of substreams. 290 o For SDP, an IPR disclosure seeming to assert RF licensing has been 291 made against the defining draft [ipr-ssrc]. 293 o For COP, an IPR disclosure asserting RAND (not RF) licensing has 294 been made against the defining draft, with no assertion on which 295 parts of the draft it applies to. [ipr-cop] 297 5. Usage considerations 299 This section notes briefly some of the situations in which resizing 300 might be desirable. 302 o Change of display window size on screen (window manager resize, 303 for instance) 305 o Changing the display target between a smaller and a larger window 306 ("large current talker", for instance) 308 o Retargeting of the display to a different display surface ("attach 309 external monitor", for instance) 311 o Temporary CPU or GPU overload due to media stream processing 312 conflicting with other tasks, including handling a large number of 313 media streams 315 o Recovery from such overload situations 317 o <<< more? >>> 319 Adaptation to bandwidth changes (congestion control) is NOT included 320 in this set, since a more correct model for this is that it should be 321 detected by the sender and the receiver operating in tandem, and the 322 sender should decide which flows, if any, need their bitrates 323 changed. 325 Turning video streams off (mute) is also not included; use of "size = 326 0" has been suggested as one mechanism for video mute, but this 327 proposed mechanism is not addressed in this memo. 329 6. Relation to WebRTC API constraints 331 It is intended that the resolution negotiation be influenced by the 332 constraints set by the application of either mandatory or optional 333 constraints at the WebRTC API, as registered in the registry 334 established by [I-D.burnett-rtcweb-constraints-registry]. 336 The following relationships hold for all attributes that the 337 implementation intends to satisfy (note that the constraints listed 338 here have NOT been registered yet): 340 video-min-height >= value of imageattr y= xyrange lower bound 342 video-max-height <= value of imageattr y= xyrange upper bound 344 video-min-framerate is not represented in SDP 346 video-max-framerate <= value of a=framerate attribute 348 video-min-aspect-ratio <= value of imageattr "par=" prange lower 349 bound 351 video-max-aspect-ratio >= value of imageattr "par=" prange upper 352 bound 354 The implementation is free to increase "min" values or decrease "max" 355 values (make requirements more restrictive) and add "step" in order 356 to fit with its implementation restrictions. 358 Constraints specified at PeerConnection creation time are reflected 359 as SDP-wide values. Constraints specified when creating a 360 MediaStream or attaching a MediaStream to a PeerConnection are 361 reflected as ssrc-specific values. 363 The envisioned usage is that the application will not use the values 364 specified by the client directly, but choose the minimum of the 365 specified bounds and the implementation limitations of the browser, 366 adjusted for any odd requirements of the codec or soft/hardware, and 367 choose a representation in the SDP that adequately represents the 368 possible configurations. 370 7. IANA Considerations 372 This document makes no request of IANA. 374 Note to RFC Editor: this section may be removed on publication as an 375 RFC. 377 8. Security Considerations 379 All considerations related to normal usage of SDP apply to this memo. 381 9. Acknowledgements 383 10. References 385 10.1. Normative References 387 [I-D.burnett-rtcweb-constraints-registry] 388 Burnett, D., "IANA Registry for RTCWeb Media Constraints", 389 draft-burnett-rtcweb-constraints-registry-00 (work in 390 progress), March 2012. 392 [I-D.ietf-rtcweb-use-cases-and-requirements] 393 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 394 Time Communication Use-cases and Requirements", 395 draft-ietf-rtcweb-use-cases-and-requirements-06 (work in 396 progress), October 2011. 398 [I-D.lennox-mmusic-sdp-source-selection] 399 Lennox, J. and H. Schulzrinne, "Mechanisms for Media 400 Source Selection in the Session Description Protocol 401 (SDP)", draft-lennox-mmusic-sdp-source-selection-03 (work 402 in progress), January 2012. 404 [I-D.westerlund-avtext-codec-operation-point] 405 Westerlund, M., Burman, B., and L. Hamm, "Codec Operation 406 Point RTCP Extension", 407 draft-westerlund-avtext-codec-operation-point-00 (work in 408 progress), March 2012. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 414 Description Protocol", RFC 4566, July 2006. 416 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 417 Attributes in the Session Description Protocol (SDP)", 418 RFC 6236, May 2011. 420 10.2. Informative References 422 [ipr-cop] "Telefonaktiebolaget LM Ericsson (publ)'s Statement about 423 IPR related to 424 draft-westerlund-avtext-codec-operation-point-00 - 425 https://datatracker.ietf.org/ipr/1701/", March 2012. 427 [ipr-ssrc] 428 "Vidyo, Inc.'s Statement about IPR related to 429 draft-lennox-mmusic-sdp-source-selection-00 - 430 https://datatracker.ietf.org/ipr/1170/". 432 Author's Address 434 Harald Alvestrand 435 Google 437 Email: harald@alvestrand.no