idnits 2.17.1 draft-ietf-avt-rfc2032-bis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 743. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Reference vertical motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. VMVD is encoded as a 2's complement number, and `10000' corresponding to the value -16 SHALL not be used (motion vector fields range from +/-15). -- 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 (January 23, 2006) is 6668 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'H261' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: July 27, 2006 January 23, 2006 6 RTP Payload Format for H.261 Video Streams 7 draft-ietf-avt-rfc2032-bis-13.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 27 http://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 July 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This memo describes a scheme to packetize an H.261 video stream for 41 transport using the Real-time Transport Protocol, RTP, with any of 42 the underlying protocols that carry RTP. 44 The memo also describes the syntax and semantics of the SDP 45 parameters needed to support the H.261 video codec. A media type 46 registration is included for this payload format. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Structure of the packet stream . . . . . . . . . . . . . . . . 5 53 3.1. Overview of the ITU-T recommendation H.261 . . . . . . . . 5 54 3.2. Considerations for packetization . . . . . . . . . . . . . 5 55 4. Specification of the packetization scheme . . . . . . . . . . 7 56 4.1. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.2. Recommendations for operation with hardware codecs . . . . 10 58 5. Packet loss issues . . . . . . . . . . . . . . . . . . . . . . 11 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 60 6.1. Media Type Registrations . . . . . . . . . . . . . . . . . 13 61 6.1.1. Registration of MIME media type video/H261 . . . . . . 13 62 6.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 14 63 6.2.1. Usage with the SDP Offer Answer Model . . . . . . . . 15 64 7. Backward Compatibility to RFC2032 . . . . . . . . . . . . . . 17 65 7.1. Optional H.261-specific control packets . . . . . . . . . 17 66 7.2. New SDP optional parameters . . . . . . . . . . . . . . . 17 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 69 10. changes from RFC 2032> . . . . . . . . . . . . . . . . . . . . 20 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 Intellectual Property and Copyright Statements . . . . . . . . . . 24 76 1. Introduction 78 The ITU-T recommendation H.261 [H261] specifies the encoding used by 79 ITU-T compliant video-conference codecs. Although these encoding 80 were originally specified for fixed data rate ISDN circuits, 81 experiments [INRIA], [MICE] have shown that they can also be used 82 over packet-switched networks such as the Internet. 84 The purpose of this memo is to specify the RTP payload format for 85 encapsulating H.261 video streams in RTP [RFC3550]. 87 This document obsolete RFC 2032 and updates the "video/h261" media 88 type that was registered in RFC 3555. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119] and 95 indicate requirement levels for compliant RTP implementations. 97 3. Structure of the packet stream 99 3.1. Overview of the ITU-T recommendation H.261 101 The H.261 coding is organized as a hierarchy of groupings. The video 102 stream is composed of a sequence of images, or frames, which are 103 themselves organized as a set of Groups of Blocks (GOB). Note that 104 H.261 "pictures" are referred as "frames" in this document. Each GOB 105 holds a set of 3 lines of 11 macro blocks (MB). Each MB carries 106 information on a group of 16x16 pixels: luminance information is 107 specified for 4 blocks of 8x8 pixels, while chrominance information 108 is given by two "red" and "blue" color difference components at a 109 resolution of only 8x8 pixels. These components and the codes 110 representing their sampled values are as defined in the ITU-R 111 Recommendation 601 [BT601]. 113 This grouping is used to specify information at each level of the 114 hierarchy: 116 - At the frame level, one specifies information such as the delay 117 from the previous frame, the image format, and various indicators. 119 - At the GOB level, one specifies the GOB number and the default 120 quantifier that will be used for the MBs. 122 - At the MB level, one specifies which blocks are present and which 123 did not change, and optionally a quantifier and motion vectors. 125 Blocks which have changed are encoded by computing the discrete 126 cosine transform (DCT) of their coefficients, which are then 127 quantized and Huffman encoded (Variable Length Codes). 129 The H.261 Huffman encoding includes a special "GOB start" pattern, 130 which is a word of 16 bits, 0000 0000 0000 0001. This pattern is 131 included at the beginning of each GOB header (and also at the 132 beginning of each frame header) to mark the separation between two 133 GOBs, and is in fact used as an indicator that the current GOB is 134 terminated. The encoding also includes a stuffing pattern, composed 135 of seven zero bits followed by four bits with a value of one; that 136 stuffing pattern can only be entered between the encoding of MBs, or 137 just before the GOB separator. 139 3.2. Considerations for packetization 141 H.261 codecs designed for operation over ISDN circuits produce a bit 142 stream composed of several levels of encoding specified by H.261 and 143 companion recommendations. The bits resulting from the Huffman 144 encoding are arranged in 512-bit frames, containing 2 bits of 145 synchronization, 492 bits of data and 18 bits of error correcting 146 code. The 512-bit frames are then interlaced with an audio stream 147 and transmitted over px64 kbps circuits according to specification 148 H.221 [H221]. 150 When transmitting over the Internet, we will directly consider the 151 output of the Huffman encoding. All the bits produced by the Huffman 152 encoding stage will be included in the packet. We will not carry the 153 512-bit frames, as protection against bit errors can be obtained by 154 other means. Similarly, we will not attempt to multiplex audio and 155 video signals in the same packets, as UDP and RTP provide a much more 156 suitable way to achieve multiplexing. 158 Directly transmitting the result of the Huffman encoding over an 159 unreliable stream of UDP datagrams would, however, have poor error 160 resistance characteristics. The result of the hierarchical structure 161 of H.261 bit stream is that one needs to receive the information 162 present in the frame header to decode the GOBs, as well as the 163 information present in the GOB header to decode the MBs. Without 164 precautions, this would mean that one has to receive all the packets 165 that carry an image in order to properly decode its components. 167 If each image could be carried in a single packet, this requirement 168 would not create a problem. However, a video image or even one GOB 169 by itself can sometimes be too large to fit in a single packet. 170 Therefore, the MB is taken as the unit of fragmentation. Packets 171 must start and end on a MB boundary, i.e. a MB cannot be split across 172 multiple packets. Multiple MBs may be carried in a single packet 173 when they will fit within the maximal packet size allowed. This 174 practice is recommended to reduce the packet send rate and packet 175 overhead. 177 To allow each packet to be processed independently for efficient 178 resynchronization in the presence of packet losses, some state 179 information from the frame header and GOB header is carried with each 180 packet to allow the MBs in that packet to be decoded. This state 181 information includes the GOB number in effect at the start of the 182 packet, the macroblock address predictor (i.e. the last MBA encoded 183 in the previous packet), the quantizer value in effect prior to the 184 start of this packet (GQUANT, MQUANT or zero in case of a beginning 185 of GOB) and the reference motion vector data (MVD) for computing the 186 true MVDs contained within this packet. The bit stream cannot be 187 fragmented between a GOB header and MB 1 of that GOB. 189 Moreover, since the compressed MB may not fill an integer number of 190 octets, the data header contains two three-bit integers, SBIT and 191 EBIT, to indicate the number of unused bits in the first and last 192 octets of the H.261 data, respectively. 194 4. Specification of the packetization scheme 196 4.1. Usage of RTP 198 Each RTP packet starts with a fixed RTP header as explained in 199 RFC3550 [RFC3550]. The following fields of the RTP fixed header used 200 for H.261 video streams are further emphasized here: 202 - Payload type: The assignment of an RTP payload type for this packet 203 format is outside the scope of this document, and will not be 204 specified here. It is expected that the RTP profile for a particular 205 class of applications will assign a payload type for this encoding, 206 or if that is not done then a payload type in the dynamic range shall 207 be chosen. 209 - The RTP timestamp encodes the sampling instant of the first video 210 image contained in the RTP data packet. If a video image occupies 211 more than one packet, the timestamp SHALL be the same on all of those 212 packets. Packets from different video images MUST have different 213 timestamp so that frames may be distinguished by the timestamp. For 214 H.261 video streams, the RTP timestamp is based on a 90kHz clock. 215 This clock rate is a multiple of the natural H.261 frame rate (i.e. 216 30000/1001 or approx. 29.97 Hz). That way, for each frame time, the 217 clock is just incremented by the multiple and this removes inaccuracy 218 in calculating the timestamp. Furthermore, the initial value of the 219 timestamp MUST be random (unpredictable) to make known-plaintext 220 attacks on encryption more difficult, see RTP [RFC3550]. Note that 221 if multiple frames are encoded in a packet (e.g. when there are very 222 little changes between two images), it is necessary to calculate 223 display times for the frames after the first, using the timing 224 information in the H.261 frame header. This is required because the 225 RTP timestamp only gives the display time of the first frame in the 226 packet. 228 - The marker bit of the RTP header MUST be set to one in the last 229 packet of a video frame, and otherwise, MUST be zero. Thus, it is 230 not necessary to wait for a following packet (which contains the 231 start code that terminates the current frame) to detect that a new 232 frame should be displayed. 234 The H.261 data SHALL follow the RTP header, as in: 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 . . 240 . RTP header . 241 . . 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | H.261 header | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | H.261 stream ... . 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 The H.261 header is defined as following: 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The fields in the H.261 header have the following meanings: 258 Start bit position (SBIT): 3 bits 260 Number of most significant bits that should be ignored in the 261 first data octet. 263 End bit position (EBIT): 3 bits 265 Number of least significant bits that should be ignored in the 266 last data octet. 268 INTRA-frame encoded data (I): 1 bit 270 Set to 1 if this stream contains only INTRA-frame coded blocks. 271 Set to 0 if this stream may or may not contain INTRA-frame coded 272 blocks. The meaning of this bit should not be changed during the 273 course of the RTP session. 275 Motion Vector flag (V): 1 bit 277 Set to 0 if motion vectors are not used in this stream. Set to 1 278 if motion vectors may or may not be used in this stream. The 279 meaning of this bit should not be changed during the course of the 280 session. 282 GOB number (GOBN): 4 bits 283 Encodes the GOB number in effect at the start of the packet. Set 284 to 0 if the packet begins with a GOB header. 286 Macroblock address predictor (MBAP): 5 bits 288 Encodes the macroblock address predictor (i.e. the last MBA 289 encoded in the previous packet). This predictor ranges from 0-32 290 (to predict the valid MBAs 1-33), but because the bit stream 291 cannot be fragmented between a GOB header and MB 1, the predictor 292 at the start of the packet shall not be 0. Therefore, the range 293 is 1-32, which is biased by -1 to fit in 5 bits. For example, if 294 MBAP is 0, the value of the MBA predictor is 1. Set to 0 if the 295 packet begins with a GOB header. 297 Quantizer (QUANT): 5 bits 299 Quantizer value (MQUANT or GQUANT) in effect prior to the start of 300 this packet. Set to 0 if the packet begins with a GOB header. 302 Horizontal motion vector data (HMVD): 5 bits 304 Reference horizontal motion vector data (MVD). Set to 0 if V flag 305 is 0 or if the packet begins with a GOB header, or when the MTYPE 306 of the last MB encoded in the previous packet was not MC. HMVD is 307 encoded as a 2's complement number, and `10000' corresponding to 308 the value -16 is forbidden (motion vector fields range from 309 +/-15). 311 Vertical motion vector data (VMVD): 5 bits 313 Reference vertical motion vector data (MVD). Set to 0 if V flag 314 is 0 or if the packet begins with a GOB header, or when the MTYPE 315 of the last MB encoded in the previous packet was not MC. VMVD is 316 encoded as a 2's complement number, and `10000' corresponding to 317 the value -16 SHALL not be used (motion vector fields range from 318 +/-15). 320 Note that the I and V flags are hint flags, i.e. they can be inferred 321 from the bit stream. They are included to allow decoders to make 322 optimizations that would not be possible if these hints were not 323 provided before bit stream was decoded. Therefore, these bits cannot 324 change for the duration of the stream. A conformant implementation 325 can always set V=1 and I=0. 327 The H.261 stream SHALL be used without BCH error correction and 328 without error correction framing. 330 4.2. Recommendations for operation with hardware codecs 332 Packetizers for hardware codecs can trivially figure out GOB 333 boundaries using the GOB-start pattern included in the H.261 data. 334 (Note that software encoders already know the boundaries.) The 335 cheapest packetization implementation is to packetize at the GOB 336 level all the GOBs that fit in a packet. But when a GOB is too 337 large, the packetizer has to parse it to do MB fragmentation. (Note 338 that only the Huffman encoding must be parsed and that it is not 339 necessary to fully decompress the stream, so this requires relatively 340 little processing; example implementations can be found in some 341 public H.261 codecs such as IVS [IVS] and VIC [VIC].) It is 342 recommended that MB level fragmentation be used when feasible in 343 order to obtain more efficient packetization. Using this 344 fragmentation scheme reduces the output packet rate and therefore 345 reduces the overhead. 347 At the receiver, the data stream can be depacketized and directed to 348 a hardware codec's input. If the hardware decoder operates at a 349 fixed bit rate, synchronization may be maintained by inserting the 350 stuffing pattern between MBs (i.e., between packets) when the packet 351 arrival rate is slower than the bit rate. 353 5. Packet loss issues 355 On the Internet, most packet losses are due to network congestion 356 rather than transmission errors. Using UDP, no mechanism is 357 available at the sender to know if a packet has been successfully 358 received. It is up to the application, i.e. coder and decoder, to 359 handle the packet loss. Each RTP packet includes a sequence number 360 field which can be used to detect packet loss. 362 H.261 uses the temporal redundancy of video to perform compression. 363 This differential coding (or INTER-frame coding) is sensitive to 364 packet loss. After a packet loss, parts of the image may remain 365 corrupt until all corresponding MBs have been encoded in INTRA-frame 366 mode (i.e. encoded independently of past frames). There are several 367 ways to mitigate packet loss: 369 (1) One way is to use only INTRA-frame encoding and MB level 370 conditional replenishment. That is, only MBs that change (beyond 371 some threshold) are transmitted. 373 (2) Another way is to adjust the INTRA-frame encoding refreshment 374 rate according to the packet loss observed by the receivers. The 375 H.261 recommendation specifies that a MB is INTRA-frame encoded 376 at least every 132 times it is transmitted. However, the INTRA- 377 frame refreshment rate can be raised in order to speed the 378 recovery when the measured loss rate is significant. 380 (3) The fastest way to repair a corrupted image is to request an 381 INTRA-frame coded image refreshment after a packet loss is 382 detected. One means to accomplish this is for the decoder to 383 send to the coder a list of packets lost. The coder can decide 384 to encode every MB of every GOB of the following video frame in 385 INTRA-frame mode (i.e. Full INTRA-frame encoded), or if the 386 coder can deduce from the packet sequence numbers which MBs were 387 affected by the loss, it can save bandwidth by sending only those 388 MBs in INTRA-frame mode. This mode is particularly efficient in 389 point-to-point connection or when the number of decoders is low. 391 The H.261 specific control packets FIR and NACK as described in 392 RFC2032 SHALL NOT be used to request image refreshment. Old 393 implementations are encourage to use the methods described in this 394 section. Image refreshment may be needed due to packet loss or due 395 to application requirements. An example of application requirement 396 may be the change of the speaker in a voice-activated multipoint 397 video switching conference. There are two methods that can be used 398 for requesting image refreshment. The first method is by using the 399 Extended RTP Profile for RTCP-based Feedback and sending RTCP generic 400 control packets as described in RFC YYYY [rtcp-feedback]. The second 401 method is by using the application protocol specific commands like 402 H.245 [ITU.H245] FastUpdateRequest. 404 6. IANA Considerations 406 This section updates the H.261 media type described in RFC3555 407 [RFC3555]. 409 This section specifies optional parameters that MAY be used to select 410 optional features of the payload format. The parameters are 411 specified here as part of the MIME subtype registration for the ITU-T 412 H.261 codec. A mapping of the parameters into the Session 413 Description Protocol (SDP) [I-D.ietf-mmusic-sdp-new] is also provided 414 for those applications that use SDP. Multiple parameters SHOULD be 415 expressed as a media type string, in the form of a semi-colon 416 separated list of parameters. 418 6.1. Media Type Registrations 420 This section describes the media types and names associated with this 421 payload format. The section updates the previous registered version 422 in RFC 3555 [RFC3555]. This registration uses the template defined 423 in RFC 4288 [RFC4288] 425 6.1.1. Registration of MIME media type video/H261 427 MIME media type name: video 429 MIME subtype name: H261 431 Required parameters: None 433 Optional parameters: 435 CIF: This parameter has the format of parameter=value. It 436 describes the maximum supported frame rate for CIF resolution. 437 permissible value are integer values 1 to 4 and it means that the 438 maximum rate is 29.97/ specified value 440 QCIF: This parameter has the format of parameter=value. It 441 describes the maximum supported frame rate for QCIF resolution. 442 permissible value are integer values 1 to 4 and it means that the 443 maximum rate is 29.97/ specified value 445 D: specifies support for still image graphics according to H.261 446 annex D. If supported the parameter value SHALL be "1". If not 447 supported the parameter SHOULD NOT be used or SHALL have the value 448 "0". 450 Encoding considerations: 452 This media type is framed and binary, see section 4.8 in [RFC4288] 454 Security considerations: See Section 8 456 Interoperability considerations: 458 These are receiver options, current implementations will not send 459 any optional parameters in their SDP. They will ignore the 460 optional parameters and will encode the H.261 stream without annex 461 D. Most decoders support at least QCIF resolutions and they are 462 expected to be available almost in every H.261 based video 463 application. 465 Published specification: RFC yyy 467 Applications which use this media type: 469 Audio and video streaming and conferencing applications. 471 Additional information: none 473 Person and email address to contact for further information : 475 Roni Even: roni.even@polycom.co.il 477 Intended usage: COMMON 479 Restrictions on usage: 481 This media type depends on RTP framing, and hence is only defined 482 for transfer via RTP [RFC3550]. Transport within other framing 483 protocols is not defined at this time. 485 Author: Roni Even 487 Change controller: 489 IETF Audio/Video Transport working group delegated from the IESG. 491 6.2. SDP Parameters 493 The MIME media type video/H261 string is mapped to fields in the 494 Session Description Protocol (SDP) as follows: 496 o The media name in the "m=" line of SDP MUST be video. 498 o The encoding name in the "a=rtpmap" line of SDP MUST be H261 (the 499 MIME subtype). 501 o The clock rate in the "a=rtpmap" line MUST be 90000. 503 o The optional parameters "CIF", "QCIF" and "D" if any, SHALL be 504 included in the "a=fmtp" line of SDP. These parameters are 505 expressed as a MIME media type string, in the form of as a semi- 506 colon separated list of parameters 508 6.2.1. Usage with the SDP Offer Answer Model 510 When offering H.261 over RTP using SDP in an Offer/Answer model 511 [RFC3264] the following considerations are necessary. 513 Codec options: (D) This option MUST NOT appear unless the sender of 514 this SDP message is able to decode this option. This option SHALL be 515 considered as a receiver's capability even when send in a "sendonly" 516 offer. 518 Picture sizes and MPI: 520 Supported picture sizes and their corresponding minimum picture 521 interval (MPI) information for H.261 can be combined. All picture 522 sizes may be advertised to the other party, or only a subset of it. 523 Using the recvonly or sendrev direction attribute a terminal SHOULD 524 announce those picture sizes (with their MPIs) which it is willing to 525 receive. For example, CIF=2 means that receiver can receive a CIF 526 picture and the frame rate SHALL be less then 15 frames per second. 528 When the direction attribute is sendonly the parameters describe the 529 capabilities of the stream that the sender can produce. 531 Implementations following this specification SHALL specify at least 532 one supported picture size. 534 If the receiver does not specify the picture size /MPI parameter then 535 it is safe to assume that it is an implementation that follows RFC 536 2032. In that case it is RECOMMENDED to assume that such a receiver 537 supports reception of QCIF resolution with MPI=1. 539 Parameters offered first are the most preferred picture mode to be 540 received. 542 An example of media representation in SDP is as follows: (CIF at 15 543 frames per second, QCIF at 30 frames per second and annex D 545 m=video 49170/2 RTP/AVP 3 546 a=rtpmap:31 H261/90000 547 a=fmtp:31 CIF=2;QCIF=1;D=1 549 This means that the sender of this message can decode H.261 bit 550 stream with following options and parameters: Preferred resolution is 551 CIF (its MPI is 2), but if that is not possible then QCIF size is 552 also supported. Still image using annex D MAY be used. 554 7. Backward Compatibility to RFC2032 556 The current draft updates RFC2032. This section will address the 557 major backward compatibility issues. 559 7.1. Optional H.261-specific control packets 561 RFC 2032 defined two H.261-specific RTCP control packets, "Full 562 INTRA-frame Request" and "Negative Acknowledgement". Support of 563 these control packets was optional. The H.261-specific control 564 packets differ from normal RTCP packets in that they are not 565 transmitted to the normal RTCP destination transport address for the 566 RTP session (which is often a multicast address). Instead, these 567 control packets are sent directly via unicast from the decoder to the 568 encoder. The destination port for these control packets is the same 569 port that the encoder uses as a source port for transmitting RTP 570 (data) packets. Therefore, these packets may be considered "reverse" 571 control packets. This memo suggests generic methods to address the 572 same requirement. The authors of the drafts are not aware of 573 products that supports these control packets. Since these are 574 optional features new implementations SHALL ignore them and they 575 SHALL NOT be used by new implementations. 577 7.2. New SDP optional parameters 579 The draft adds new optional parameters to the H261 payload type. 580 Since these are optional parameters we expect old implementation to 581 ignore these parameters while new implementations that will receive 582 the H261 payload type capabilities with no parameters will assume 583 that it is an old implementation and will send H.261 at QCIF 584 resolution and 30 frames per second. 586 8. Security Considerations 588 RTP packets using the payload format defined in this specification 589 are subject to the security considerations discussed in the RTP 590 specification [RFC3550], and any appropriate RTP profile (for example 591 [RFC3551]). This implies that confidentiality of the media streams 592 is achieved by encryption. SRTP [RFC3711] may be used to provide 593 both encryption and integrity protection of RTP flow. Because the 594 data compression used with this payload format is applied end-to-end, 595 encryption will be performed after compression so there is no 596 conflict between the two operations. 598 A potential denial-of-service threat exists for data encoding using 599 compression techniques that have non-uniform receiver-end 600 computational load. The attacker can inject pathological datagrams 601 into the stream which are complex to decode and cause the receiver to 602 be overloaded. The usage of authentication of at least the RTP 603 packet is RECOMMENDED. H.261 is vulnerable to such attacks, because 604 it is possible for an attacker to generate RTP packets containing 605 frames that affect the decoding process of future frames. Therefore, 606 the usage of data origin authentication and data integrity protection 607 of at least the RTP packet is RECOMMENDED; for example, with SRTP. 609 Note that the appropriate mechanism to ensure confidentiality and 610 integrity of RTP packets and their payloads is very dependent on the 611 application and on the transport and signaling protocols employed. 612 Thus, although SRTP is given as an example above, other possible 613 choices exist. 615 9. Acknowledgements 617 This is to acknowledge the authors of RFC2032 Thierry Turletti and 618 Christian Huitema. Special thanks for the work done by Petri 619 Koskelainen from Nokia and Nermeen Ismail from Cisco who helped with 620 drafting the text for the new MIME types. 622 10. changes from RFC 2032> 624 The changes from the RFC 2032 are: 626 1. The H.261 MIME type is now in the payload specification. 628 2. Added optional parameters to the H.261 MIME type 630 3. Deprecated the H.261 specific control packets 632 4. Editorial changes to be in line with RFC editing procedures 634 11. References 636 11.1. Normative References 638 [H261] International Telecommunications Union, "Video codec for 639 audiovisual services at p x 64 kbit/s", ITU Recommendation 640 H.261, March 1993. 642 [I-D.ietf-mmusic-sdp-new] 643 Handley, M., "SDP: Session Description Protocol", 644 draft-ietf-mmusic-sdp-new-25 (work in progress), 645 July 2005. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 651 with Session Description Protocol (SDP)", RFC 3264, 652 June 2002. 654 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 655 Jacobson, "RTP: A Transport Protocol for Real-Time 656 Applications", STD 64, RFC 3550, July 2003. 658 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 659 Video Conferences with Minimal Control", STD 65, RFC 3551, 660 July 2003. 662 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 663 Payload Formats", RFC 3555, July 2003. 665 11.2. Informative References 667 [BT601] International Telecommunications Union, "Studio encoding 668 parameters of digital television for standard 4:3 and 669 wide-screen 16:9 aspect ratios", ITU-R Recommendation 670 BT.601-5, October 1995. 672 [H221] International Telecommunications Union, "Frame structure 673 for a 64 to 1920 kbit/s channel in audiovisual 674 teleservices", ITU Recommendation H.221, May 1999. 676 [INRIA] Turletti, T., "H.261 software codec for videoconferencing 677 over the Internet", INRIA Research Report 1834, 678 January 1993. 680 [ITU.H245] 681 International Telecommunications Union, "CONTROL PROTOCOL 682 FOR MULTIMEDIA COMMUNICATION", ITU Recommendation H.245, 683 2003. 685 [IVS] Turletti, T., "INRIA Videoconferencing tool (IVS), 686 available by anonymous ftp from zenon.inria.fr in the 687 "rodeo/ivs/last_version" directory. See also URL 688 http://www.inria.fr/rodeo/ivs.html". 690 [MICE] Sasse, MA., Bilting, U., Schultz, CD., and T. Turletti, 691 "Remote Seminars through MultiMedia Conferencing: 692 Experiences from the MICE project", Proc. INET'94/JENC5, 693 Prague pp. 251/1-251/8, June !994. 695 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 696 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 697 RFC 3711, March 2004. 699 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 700 Registration Procedures", BCP 13, RFC 4288, December 2005. 702 [VIC] MacCanne, S., "VIC Videoconferencing tool, available by 703 anonymous ftp from ee.lbl.gov in the "conferencing/vic" 704 directory". 706 [rtcp-feedback] 707 Ott, J. and S. Wenger, "Extended RTP Profile for RTCP- 708 based Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-08 709 (work in progress), January 2004. 711 Author's Address 713 Roni Even 714 Polycom 715 94 Derech Em Hamoshavot 716 Petach Tikva 49130 717 Israel 719 Email: roni.even@polycom.co.il 721 Intellectual Property Statement 723 The IETF takes no position regarding the validity or scope of any 724 Intellectual Property Rights or other rights that might be claimed to 725 pertain to the implementation or use of the technology described in 726 this document or the extent to which any license under such rights 727 might or might not be available; nor does it represent that it has 728 made any independent effort to identify any such rights. Information 729 on the procedures with respect to rights in RFC documents can be 730 found in BCP 78 and BCP 79. 732 Copies of IPR disclosures made to the IETF Secretariat and any 733 assurances of licenses to be made available, or the result of an 734 attempt made to obtain a general license or permission for the use of 735 such proprietary rights by implementers or users of this 736 specification can be obtained from the IETF on-line IPR repository at 737 http://www.ietf.org/ipr. 739 The IETF invites any interested party to bring to its attention any 740 copyrights, patents or patent applications, or other proprietary 741 rights that may cover technology that may be required to implement 742 this standard. Please address the information to the IETF at 743 ietf-ipr@ietf.org. 745 Disclaimer of Validity 747 This document and the information contained herein are provided on an 748 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 749 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 750 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 751 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 752 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 753 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 755 Copyright Statement 757 Copyright (C) The Internet Society (2006). This document is subject 758 to the rights, licenses and restrictions contained in BCP 78, and 759 except as set forth therein, the authors retain all their rights. 761 Acknowledgment 763 Funding for the RFC Editor function is currently provided by the 764 Internet Society.