idnits 2.17.1 draft-nandakumar-payload-sdp-max-video-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC3264]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2013) is 3787 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) -- Looks like a reference, but probably isn't: '720' on line 183 -- Looks like a reference, but probably isn't: '576' on line 183 -- Looks like a reference, but probably isn't: '640' on line 171 -- Looks like a reference, but probably isn't: '480' on line 171 == Unused Reference: 'RFC4566' is defined on line 220, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group S. Nandakumar 3 Internet-Draft Cisco 4 Intended status: Standards Track C. Holmberg 5 Expires: June 10, 2014 Ericsson 6 December 7, 2013 8 Payload specific parameters for specifying video resolution in SDP. 9 draft-nandakumar-payload-sdp-max-video-resolution-00 11 Abstract 13 With the rise in realtime communication applications supporting 14 video, there is a need for receivers of the video to setup 15 appropriate expectations on their receive capacity for handling 16 various video image resolutions. Setting up the maximum supported 17 image resolution that could be handled by an Endpoint is important to 18 successfully decode and render the received video streams. This 19 document proposes SDP format specific parameters for specifying the 20 maximum image width and height resolutions along with their behavior 21 under the [RFC3264] Offer/Answer SDP usage. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 10, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . . 3 60 3.1. Media Type Registration . . . . . . . . . . . . . . . . . . 3 61 4. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Mapping of the parameters to SDP . . . . . . . . . . . . . 4 63 4.2. Usage with SDP offer/answer . . . . . . . . . . . . . . . . 4 64 5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5.1. Successful Scenario . . . . . . . . . . . . . . . . . . . . 4 66 5.2. Failure Scenario . . . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119. 78 2. Introduction 80 Off late, multimedia communication sessions are increasingly 81 supporting video by default. This is further fueled with the advent 82 of IETF technology standards such as RTCWeb, CLUE. In order to 83 successfully decode an incoming video stream, the decoder at the 84 Endpoint must be capable of handling the image resolution of the 85 received video streams, amongst other things. This document defines 86 SDP payload format specific paramaters (a=fmtp) to setup an upper 87 limit on the receiver's capability in successfully handling various 88 image resolutions of the incoming video stream. It also describes 89 [RFC3264] Offer/Answer procedures for the same. 91 Individual RTP Payload specifications that intend to specify limits 92 on the decoder's image resolution handling MUST refer to the 93 parameters defined in this document to achieve the functionality. 95 3. Payload Format Parameters 97 The media subtype parameters max-recv-width and max-recv-height 98 specified below MAY be used to signal the capabilities of a receiver 99 implementation. These parameters MUST NOT be used for any other 100 purposes. 102 3.1. Media Type Registration 104 New Parameters 105 1. max-recv-width: The value of max-recv-width is an integer 106 indicating maximum horizontal image range in pixels. When max- 107 recv-width is signaled, the sender MUST NOT send any media with 108 horizontal image resolutions higher than the value requested by 109 the receiver. 110 2. max-recv-height: The value of max-recv-height is an integer 111 indicating maximum vertical image range in pixels. When max- 112 recv-height is signaled, the sender MUST NOT send any media with 113 vertical image resolutions higher than the value requested by the 114 receiver. 116 4. SDP Parameters 118 4.1. Mapping of the parameters to SDP 120 The parameters max-recv-width, max-recv-height when present, MUST be 121 included in the "a=fmtp" line of SDP. These parameters are expressed 122 as a media type string, in the form of a semicolon separated list of 123 parameter=value pairs. 125 When signaled, both the attributes MUST be included and they signal 126 the capabilities of a media receiver's implementation. These 127 parameters are implicitly downgradable from the media sender's 128 perspective, i.e, they express the upper limit for a media sender's 129 possible behavior. Thus a media sender MAY select to set its encoder 130 using only lower/lesser or equal values of these parameters when 131 sending media. 133 4.2. Usage with SDP offer/answer 135 The interpretation of the parameters max-recv-width and max-recv- 136 height depends on the SDP direction attribute. When the direction is 137 sendrecv or recvonly, the value of this parameter indicates the 138 ranges of horizontal and vertical image resolutions the media 139 receiver is capable of rendering successfully. When the direction is 140 sendonly, these attributes have no interpretation and MUST be ignored 141 by the receiving Endpoint, if present. 143 If the media sender is not capable of sending any resolution lower 144 than or equal to the values requested by the media receiver, the 145 Offer/Answer procedure is considered as failed. 147 An SDP Answerer MUST NOT include these parameters in the SDP Answer 148 unless they are specified in the associated SDP Offer. 150 If the SDP Answer doesn't contain these parameters, the Offerer MUST 151 follow the procedures in the same way as if these parameters were 152 never sent in the first place. This might happen if the Answerer 153 doesn't support/understand these parameters. 155 5. SDP Examples 157 5.1. Successful Scenario 159 The example SDP below shows an Offer from an Endpoint that is capable 160 of receiving up to [720,576] video image resolution for the VP8 codec 161 with Payload Type 96. 163 m=video 62537 RTP/SAVPF 96 164 a=rtpmap:96 VP8/90000 165 a=fmtp:96 max-fr=30;max-recv-width=720;max-recv-height=576 166 a=sendrecv 168 SDP Offer 170 The example SDP below shows an Answer from an Endpoint that is 171 capable of receiving only up to [640,480] video image resolutions. 173 m=video 62537 RTP/SAVPF 96 174 a=rtpmap:96 VP8/90000 175 a=fmtp:96 max-fr=30;max-recv-width=640;max-recv-height=480 176 a=sendrecv 178 SDP Answer 180 5.2. Failure Scenario 182 The example SDP below shows an Offer from an Endpoint that is capable 183 of receiving up to [720,576] video image resolution for the H.264 184 codec with Payload Type 100. 186 m=video 62537 RTP/SAVPF 100 187 a=rtpmap:100 H264/90000 188 a=fmtp:100 189 profile-level-id=42800d;max-mbps=40500;max-recv-width=720;max-recv-height=576 190 a=sendrecv 192 SDP Offer 194 The example SDP below shows the Answer rejecting the above SDP Offer, 195 since the receiver of the SDP is unable to support the Offerer's 196 requested image resolutions for sending the media. 198 m=video 0 RTP/SAVPF 100 199 a=rtpmap:100 H264/90000 201 SDP Answer 203 6. IANA Considerations 205 The parameters specified in Section 3 of this document will be 206 registered with the IANA. 208 7. Acknowledgements 210 The authors would like to thanks Cullen Jennings, Ali C. Began, 211 Harald Alvestrand and Roni Evens for their review and valuable 212 comments. 214 8. Normative References 216 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 217 with Session Description Protocol (SDP)", RFC 3264, 218 June 2002. 220 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 221 Description Protocol", RFC 4566, July 2006. 223 Authors' Addresses 225 Suhas Nandakumar 226 Cisco 227 170 West Tasman Drive 228 San Jose, CA 95134 229 USA 231 Email: snandaku@cisco.com 233 Christer Holmberg 234 Ericsson 235 Hirsalantie 11 236 Jorvas 02420 237 Finland 239 Email: christer.holmberg@ericsson.com