idnits 2.17.1 draft-even-avt-h263-h261-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 85 has weird spacing: '...ber, it can b...' == Line 120 has weird spacing: '...ber, it can b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2003) is 7505 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) == Unused Reference: '5' is defined on line 308, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3555 (ref. '6') (Obsoleted by RFC 4855, RFC 4856) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT R. Even 3 Internet-Draft Polycom 4 Expires: April 7, 2004 P. Koskelainen 5 Nokia 6 October 8, 2003 8 SDP parameters for supporting H.263 and H.261 options 9 draft-even-avt-h263-h261-options-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 7, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines the syntax and the semantics of SDP parameters 41 needed to support features of H.261 and H.263 video codecs. This 42 optional parameters enables the H.261 and H.263 codecs to specify 43 their functionality enabling better video support. The document 44 specify codec specific parameters that can be used with SIP, SAP or 45 any similar protocol that uses SDP to signal support of those codecs. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. H.261 Codec Parameters . . . . . . . . . . . . . . . . . . . . . 3 51 3. H.263 Codec Parameters . . . . . . . . . . . . . . . . . . . . . 4 52 4. Usage of SDP H.261 and H.263 options with SIP . . . . . . . . . 6 53 5. Use of SDP H.263 and H.261 options with SAP . . . . . . . . . . 7 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 55 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 57 Intellectual Property and Copyright Statements . . . . . . . . . 9 59 1. Introduction 61 Internet multimedia conferencing is picking up with point-to-point 62 and multipoint video conferencing implementations. The common video 63 codecs that are used in video conferencing applications include 64 H.261[3] and the basic H.263 with its two revisions from 1998 and 65 2000[4]. The current usage of H.261[3] and H.263[4] is limited since 66 the current SDP MIME types defined in RFC3555 [6] are defining only 67 part of the functionality needed. 69 This document specifies the SDP syntax and the semantics for 70 describing the optional H.261 and H.263 features. The syntax in this 71 document uses the SDP "a=fmtp" attribute which is meant to carry 72 codec specific parameters. These codec specific parameters can be 73 used with SIP[1], SAP[2] or any similar protocol that uses SDP to 74 signal support of those codecs. 76 2. H.261 Codec Parameters 78 For further description of these H.261 parameters refer to the ITU 79 H.261 document[3]. 81 The fmtp parameters for H.261 are represented in the SDP attribute. 83 a=fmtp:xx H261_option 85 The xx is the RTP payload number, it can be a static or dynamic 86 payload number. The recommendation is to use dynamic payload number. 88 The syntax of H261_option is 90 H261_option = *Size SP | *Annex SP 92 Size = "QCIF" "=" "mpi | "CIF" "=" mpi 94 mpi = 1*2DIGIT 96 Annex = "D" 98 The Size parameter specifies the picture size supported and at what 99 frame rate. H.261 defines two resolution QCIF and CIF. 101 mpi is an integer value (1..4) and it means the maximum picture frame 102 rate is (29.97/mpi) frames/sec. The definition of the mpi is 103 according to the video codec specification. 105 Annex D specifies support for still image graphics according to H.261 106 annex D. 108 3. H.263 Codec Parameters 110 H.263 has three MIME types defined in RFC3555. The parameters in 111 this section may be used with any of the H263 MIME types. When used 112 with H.263-2000 MIME subtype name, the optional parameters profile 113 and levels must not be used. For description of these H.263 114 parameters refer to the ITU H.263 document[4]. 116 The fmtp parameters for H.263 are represented in the SDP attribute. 118 a=fmtp:xx H263_option 120 The xx is the RTP payload number, it can be a static or dynamic 121 payload number. The recommendation is to use dynamic payload number. 123 The syntax of H263_option is 125 H263_option = *Size SP | *Annex SP | *Params 127 Size = "SQCIF" "=" "mpi | "QCIF" "=" mpi | "CIF" "=" mpi | 129 "CIF4" "=" mpi I "CIF16" "=" mpi | 131 "XMAX" "=" xmax SP "YMAX" "=" ymax SP "MPI" "=" mpi 133 mpi = 1*2DIGIT 135 xmax=1*4DIGIT 137 ymax=1*4DIGIT 139 The Size parameter specifies the picture size supported and at what 140 frame rate. H.263 defines fixed resolution SQCIF, QCIF, CIF, 4xCIF 141 and 16xCIF as well as custom picture size that are presented by their 142 maximum X and Y size. The X and Y values must be dividable by 4. 144 mpi is an integer value (1..32) and it means the maximum picture 145 frame rate is (29.97/mpi) frames/sec. The definition of the mpi is 146 according to the video codec specification. 148 Annex = "D" "=" #annex_d | "E" | "F" | "G" | "I" | "J" | 150 "K" "=" #annex_k | "L" "=" #annex_l | "M" | "N" "=" annex_n | 152 "O" "=" #annex_o | "P" | "Q" | "R" | "S" | "T" 154 annex_d= "1" | "2" 155 annex_k= "1" | "2" | "3" | "4" 157 annex_l= "1" | "2" | "3" | "4" | "5" | "6" | "7" 159 annex_n= "1" | "2" | "3" | "4" 161 annex_o= "1" | "2" | "3" 163 Here #term means comma separated list of term. 165 The H.263 parameters that can be specified are in the Params options. 167 Params= "PAR" "=" par_a ":" par_b | "CPCF" "=" cpcf | "MaxBR" "=" 168 maxbr | 170 "BPP" "=" bpp | "HRD" | "Interlaced" 172 par_a=1*3DIGIT 174 par_b=1*DIGIT 176 cpcf=1*2DIGIT "." 1*3DIGIT 178 maxbr=1*5DIGIT 180 bpp=1*5DIGIT 182 Explanations: 184 Arbitrary Pixel Aspect Ratio (PAR): 186 Par_a and par_b are integers between 0 and 255. 188 Default ratio is 12:11 if not otherwise specified. 190 Arbitrary (Custom) Picture Clock Frequency (CPCF): 192 Cpcf is floating point value. Default value is 29.97. 194 MaxBitRate (MaxBR): 196 Maximum video stream bitrate, presented with units of 100 bits/s. 197 MaxBR value is an integer between 1..19200. 199 BitsPerPictureMaxKb (BPP): 201 Maximum amount of kilobits allowed to represent a single picture 202 frame, value is specified by largest supported picture resolution, 203 see [1]. If this parameter is not present, then default value, that 204 is based on the maximum supported resolution, is used. BPP is 205 integer value between 0 and 65536. 207 Hypothetical Reference Decoder (HRD): 209 See annex B of H.263 specification. 211 Interlaced or 60 fields indicates the support for interlace display 212 according to H.263 annex W.6.3.11 214 These parameters are separated by space. 216 4. Usage of SDP H.261 and H.263 options with SIP 218 This document does not specify actual SIP signaling. The decoder 219 send its preferred parameters and let the other end select according 220 to SIP procedures. This syntax may be sent, for example, with SIP 221 INVITE and corresponding status response (200 ok). Other SIP methods 222 may be used. 224 Codec options: (D,E,F,G,I,J,K,L,M,N,O,P,Q,R,S,T) These characters 225 exist only if the sender of this SDP message is able or willing to 226 decode those. E.g. If a terminal is capable of decoding Syntax 227 based Arithmetic Coding (SAC) and Advanced Prediction (AP) options, 228 it can put E F in the end of the format specific parameters. 230 Picture sizes and MPI: 232 Supported picture sizes and their corresponding minimum picture 233 interval (MPI) information for H.261 and H.263 can be combined. All 234 picture sizes can be advertised to other party, or only some subset 235 of it. Terminal announces only those picture sizes (with their MPIs) 236 which it is willing to receive. For example, MPI=2 means that 237 maximum (decodeable) picture rate per second is about 15. 239 Parameters occurring first are the most preferred picture mode to be 240 received. 242 Example of the usage of these parameters: 244 CIF=4 QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2 246 This means that sender hopes to receive CIF picture size, which it 247 can decode at MPI=4. If that is not possible, then QCIF with MPI 248 value 3, if that is neither possible, then SQCIF with MPI value =2. 249 It is also allowed (but least preferred) to send arbitrary picture 250 sizes (max 360x240) with MPI=2. Note that most encoders support at 251 least QCIF and CIF fixed resolutions and they are expected to be 252 available almost in every H.261 and H.263 based video application. 254 MaxBR and BPP parameters: 256 Both these parameters are useful in SIP. MaxBitRate is video decoder 257 property, hence it differs from SDP b : bandwidth-value attribute 258 which refers more to application's total bandwidth (an application 259 consists often of both audio and video). 261 BitsPerPictureMaxKb is needed especially for decoder buffer size 262 estimation to reduce the probability of video buffer overflow. 264 Below is an example of H.263 SDP syntax in SIP message. 266 a=fmtp: xx CIF=4 QCIF=2 MaxBR=1000 E F 268 This means that the sender of this message can decode H.263 bit 269 stream with following options and parameters: Preferred resolution is 270 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 271 Maximum receivable bitrate is 100 kbit/s (1000*100 bit/s) and SAC and 272 AP options can be used. 274 5. Use of SDP H.263 and H.261 options with SAP 276 SAP announcements are one-way only. All H.263/H.261 options can be 277 used to signal that the sending terminal is going to use these 278 options in its transmitted video stream. It is just an informal 279 message. 281 Usually only one picture size (with its MPI) exists. However, since 282 it is possible for a video source (terminal) to change its picture 283 size during session, several picture sizes can exist in the parameter 284 list. First one is the original picture size to be used in the 285 beginning of the session. 287 6. Security Considerations 289 The security for these features are the same as for SDP. 291 References 293 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 294 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 295 Session Initiation Protocol", RFC 3261, June 2002. 297 [2] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 298 Protocol", RFC 2974, October 2000. 300 [3] International Telecommunications Union, "Video codec for 301 audiovisual services at p x 64 kbit/s", ITU-T Recommendation 302 H.261, March 1993. 304 [4] International Telecommunications Union, "Video coding for low 305 bit rate communication", ITU-T Recommendation H.263, February 306 1998. 308 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 309 Session Description Protocol (SDP)", RFC 3264, June 2002. 311 [6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 312 Payload Formats", RFC 3555, July 2003. 314 Authors' Addresses 316 Roni Even 317 Polycom 318 94 Derech Em Hamoshavot 319 Petach Tikva 49130 320 Israel 322 EMail: roni.even@polycom.co.il 324 Petri Koskelainen 325 Nokia 326 P.O. Box 100 (Visiokatu 1) 327 Tampere FIN-33721 328 Finland 330 EMail: petri.koskelainen@nokia.com 332 Intellectual Property Statement 334 The IETF takes no position regarding the validity or scope of any 335 intellectual property or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; neither does it represent that it 339 has made any effort to identify any such rights. Information on the 340 IETF's procedures with respect to rights in standards-track and 341 standards-related documentation can be found in BCP-11. Copies of 342 claims of rights made available for publication and any assurances of 343 licenses to be made available, or the result of an attempt made to 344 obtain a general license or permission for the use of such 345 proprietary rights by implementors or users of this specification can 346 be obtained from the IETF Secretariat. 348 The IETF invites any interested party to bring to its attention any 349 copyrights, patents or patent applications, or other proprietary 350 rights which may cover technology that may be required to practice 351 this standard. Please address the information to the IETF Executive 352 Director. 354 Full Copyright Statement 356 Copyright (C) The Internet Society (2003). All Rights Reserved. 358 This document and translations of it may be copied and furnished to 359 others, and derivative works that comment on or otherwise explain it 360 or assist in its implementation may be prepared, copied, published 361 and distributed, in whole or in part, without restriction of any 362 kind, provided that the above copyright notice and this paragraph are 363 included on all such copies and derivative works. However, this 364 document itself may not be modified in any way, such as by removing 365 the copyright notice or references to the Internet Society or other 366 Internet organizations, except as needed for the purpose of 367 developing Internet standards in which case the procedures for 368 copyrights defined in the Internet Standards process must be 369 followed, or as required to translate it into languages other than 370 English. 372 The limited permissions granted above are perpetual and will not be 373 revoked by the Internet Society or its successors or assignees. 375 This document and the information contained herein is provided on an 376 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 377 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 378 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 379 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 380 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 382 Acknowledgement 384 Funding for the RFC Editor function is currently provided by the 385 Internet Society.