idnits 2.17.1 draft-ietf-avt-rfc2429-bis-07.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1232. ** 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 -- 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 (November 23, 2005) is 6729 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: 'I-D.freed-media-type-reg' is defined on line 1166, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'H263' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263P' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263X' == 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 2032 (Obsoleted by RFC 4587) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT J. Ott 3 Internet-Draft Univ. Bremen 4 Expires: May 27, 2006 G. Sullivan 5 Microsoft 6 S. Wenger 7 TU Berlin 8 R. Even, Ed. 9 Polycom 10 November 23, 2005 12 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 13 (H.263+) 14 draft-ietf-avt-rfc2429-bis-07.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 27, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document describes a scheme to packetize an H.263 video stream 48 for transport using the Real-time Transport Protocol, RTP, with any 49 of the underlying protocols that carry RTP. 51 The document also describe the syntax and semantics of the SDP 52 parameters needed to support the H.263 video codec. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Video Packet Structure . . . . . . . . . . . . . . . . . . 7 62 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 9 63 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . . 11 64 5.1. General H.263+ payload header . . . . . . . . . . . . . . 11 65 5.2. Video Redundancy Coding Header Extension . . . . . . . . . 12 66 6. Packetization schemes . . . . . . . . . . . . . . . . . . . . 15 67 6.1. Picture Segment Packets and Sequence Ending Packets 68 (P=1) . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.1.1. Packets that begin with a Picture Start Code . . . . . 15 70 6.1.2. Packets that begin with GBSC or SSC . . . . . . . . . 16 71 6.1.3. Packets that Begin with an EOS or EOSBS Code . . . . . 17 72 6.2. Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . 17 73 7. Use of this payload specification . . . . . . . . . . . . . . 19 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 75 8.1. Media Type Registrations . . . . . . . . . . . . . . . . . 21 76 8.1.1. Registration of MIME media type video/H263-1998 . . . 21 77 8.1.2. Registration of MIME media type video/H263-2000 . . . 25 78 8.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 26 79 8.2.1. Usage with the SDP Offer Answer Model . . . . . . . . 27 80 9. Backward Compatibility to RFC2429 . . . . . . . . . . . . . . 29 81 9.1. New SDP optional parameters . . . . . . . . . . . . . . . 29 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 84 12. Changes from previous versions of the document . . . . . . . . 32 85 12.1. changes from RFC 2429 . . . . . . . . . . . . . . . . . . 32 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 90 Intellectual Property and Copyright Statements . . . . . . . . . . 36 92 1. Introduction 94 This document specifies an RTP payload header format applicable to 95 the transmission of video streams generated based on the 1998 and 96 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 97 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, 98 this format can also be used with the 1996 version of H.263 [H263], 99 and is recommended for this use by new implementations. This format 100 replaces the payload format in RFC 2190[RFC2190], which continues to 101 be used by some existing implementations, and can be useful for 102 backward compatibility. New implementations supporting H.263 will 103 use the payload format described in this document. 105 The document updates the media type registration that was previously 106 in RFC 3555. 108 This document obsoletes RFC2429. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119[RFC2119] and 115 indicate requirement levels for compliant RTP implementations. 117 2. New H.263 features 119 The 1998 version of ITU-T Recommendation H.263 added numerous coding 120 options to improve codec performance over the 1996 version. The 1998 121 version is referred to as H.263+ in this document. The 2000 version 122 is referred to as H.263++ in this document. 124 Among the new options, the ones with the biggest impact on the RTP 125 payload specification and the error resilience of the video content 126 are the slice structured mode, the independent segment decoding mode, 127 the reference picture selection mode, and the scalability mode. This 128 section summarizes the impact of these new coding options on 129 packetization. Refer to [H263P] for more information on coding 130 options. 132 The slice structured mode was added to H.263+ for three purposes: to 133 provide enhanced error resilience capability, to make the bitstream 134 more amenable to use with an underlying packet transport such as RTP, 135 and to minimize video delay. The slice structured mode supports 136 fragmentation at macroblock boundaries. 138 With the independent segment decoding (ISD) option, a video picture 139 frame is broken into segments and encoded in such a way that each 140 segment is independently decodable. Utilizing ISD in a lossy network 141 environment helps to prevent the propagation of errors from one 142 segment of the picture to others. 144 The reference picture selection mode allows the use of an older 145 reference picture rather than the one immediately preceding the 146 current picture. Usually, the last transmitted frame is implicitly 147 used as the reference picture for inter-frame prediction. If the 148 reference picture selection mode is used, the data stream carries 149 information on what reference frame should be used, indicated by the 150 temporal reference as an ID for that reference frame. The reference 151 picture selection mode may be used with or without a back channel, 152 which provides information to the encoder about the internal status 153 of the decoder. However, no special provision is made herein for 154 carrying back channel information. The Extended RTP Profile for 155 RTCP-based Feedback [AVPF] MAY be used as a back channel mechanism. 157 H.263+ also includes bitstream scalability as an optional coding 158 mode. Three kinds of scalability are defined: temporal, signal-to- 159 noise ratio (SNR), and spatial scalability. Temporal scalability is 160 achieved via the disposable nature of bi-directionally predicted 161 frames, or B-frames. (A low-delay form of temporal scalability known 162 as P-picture temporal scalability can also be achieved by using the 163 reference picture selection mode described in the previous 164 paragraph.) SNR scalability permits refinement of encoded video 165 frames, thereby improving the quality (or SNR). Spatial scalability 166 is similar to SNR scalability except the refinement layer is twice 167 the size of the base layer in the horizontal dimension, vertical 168 dimension, or both. 170 3. Usage of RTP 172 When transmitting H.263+ video streams over the Internet, the output 173 of the encoder can be packetized directly. All the bits resulting 174 from the bitstream including the fixed length codes and variable 175 length codes will be included in the packet, with the only exception 176 being that when the payload of a packet begins with a Picture, GOB, 177 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 178 the start code shall be removed and replaced by setting an indicator 179 bit in the payload header. 181 For H.263+ bitstreams coded with temporal, spatial, or SNR 182 scalability, each layer may be transported to a different network 183 address. More specifically, each layer may use a unique IP address 184 and port number combination. The temporal relations between layers 185 shall be expressed using the RTP timestamp so that they can be 186 synchronized at the receiving ends in multicast or unicast 187 applications. 189 The H.263+ video stream will be carried as payload data within RTP 190 packets. A new H.263+ payload header is defined in section 3. This 191 section defines the usage of the RTP fixed header and H.263+ video 192 packet structure. 194 3.1. RTP Header Usage 196 Each RTP packet starts with a fixed RTP header. The following fields 197 of the RTP fixed header used for H.263+ video streams are further 198 emphasized here: 200 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 201 the current packet carries the end of current frame, and is 0 202 otherwise. 204 Payload Type (PT): The RTP profile for a particular class of 205 applications will assign a payload type for this encoding, or if that 206 is not done, then a payload type in the dynamic range shall be chosen 207 by the sender. 209 Timestamp: The RTP Timestamp encodes the sampling instance of the 210 first video frame data contained in the RTP data packet. The RTP 211 timestamp shall be the same on successive packets if a video frame 212 occupies more than one packet. In a multilayer scenario, all 213 pictures corresponding to the same temporal reference should use the 214 same timestamp. If temporal scalability is used (if B-frames are 215 present), the timestamp may not be monotonically increasing in the 216 RTP stream. If B-frames are transmitted on a separate layer and 217 address, they must be synchronized properly with the reference 218 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 219 information on required transmission order to a decoder. For an 220 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 221 the same as that of the RTP payload for H.261 stream [RFC2032]. 222 Since both the H.263+ data and the RTP header contain time 223 information, those timing information must run synchronously. That 224 is, both the RTP timestamp and the temporal reference (TR in the 225 picture header of H.263) should carry the same relative timing 226 information. Any H.263+ picture clock frequency can be expressed as 227 1800000/(cd*cf) source pictures per second, in which cd is an integer 228 from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock 229 of the RTP timestamp, the time increment between each coded H.263+ 230 picture should therefore be a integer multiple of (cd*cf)/20. This 231 will always be an integer for any "reasonable" picture clock 232 frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz 233 PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer 234 display update rates of 60, 72 and 75 Hz, respectively). For RTP 235 packetization of hypothetical H.263+ bitstreams using "unreasonable" 236 custom picture clock frequencies, mathematical rounding could become 237 necessary for generating the RTP timestamps. 239 3.2. Video Packet Structure 241 A section of an H.263+ compressed bitstream is carried as a payload 242 within each RTP packet. For each RTP packet, the RTP header is 243 followed by an H.263+ payload header, which is followed by a number 244 of bytes of a standard H.263+ compressed bitstream. The size of the 245 H.263+ payload header is variable depending on the payload involved 246 as detailed in the section 4. The layout of the RTP H.263+ video 247 packet is shown as: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | RTP Header 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | H.263+ Payload Header 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | H.263+ Compressed Data Stream 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Any H.263+ start codes can be byte aligned by an encoder by using the 260 stuffing mechanisms of H.263+. As specified in H.263+, picture, 261 slice, and EOSBS starts codes shall always be byte aligned, and GOB 262 and EOS start codes may be byte aligned. For packetization purposes, 263 GOB start codes should be byte aligned; however, since this is not 264 required in H.263+, there may be some cases where GOB start codes are 265 not aligned, such as when transmitting existing content, or when 266 using H.263 encoders that do not support GOB start code alignment. 267 In this case, follow-on packets (see section 5.2) should be used for 268 packetization. 270 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 271 with 16 zero-valued bits. If a start code is byte aligned and it 272 occurs at the beginning of a packet, these two bytes shall be removed 273 from the H.263+ compressed data stream in the packetization process 274 and shall instead be represented by setting a bit (the P bit) in the 275 payload header. 277 4. Design Considerations 279 The goals of this payload format are to specify an efficient way of 280 encapsulating an H.263+ standard compliant bitstream and to enhance 281 the resiliency towards packet losses. Due to the large number of 282 different possible coding schemes in H.263+, a copy of the picture 283 header with configuration information is inserted into the payload 284 header when appropriate. The use of that copy of the picture header 285 along with the payload data can allow decoding of a received packet 286 even in such cases in which another packet containing the original 287 picture header becomes lost. 289 There are a few assumptions and constraints associated with this 290 H.263+ payload header design. The purpose of this section is to 291 point out various design issues and also to discuss several coding 292 options provided by H.263+ that may impact the performance of 293 network-based H.263+ video. 295 o The optional slice structured mode described in Annex K of H.263+ 296 [H263P] enables more flexibility for packetization. Similar to a 297 picture segment that begins with a GOB header, the motion vector 298 predictors in a slice are restricted to reside within its 299 boundaries. However, slices provide much greater freedom in the 300 selection of the size and shape of the area which is represented 301 as a distinct decodable region. In particular, slices can have a 302 size which is dynamically selected to allow the data for each 303 slice to fit into a chosen packet size. Slices can also be chosen 304 to have a rectangular shape which is conducive for minimizing the 305 impact of errors and packet losses on motion compensated 306 prediction. For these reasons, the use of the slice structured 307 mode is strongly recommended for any applications used in 308 environments where significant packet loss occurs. 310 o In non-rectangular slice structured mode, only complete slices 311 should be included in a packet. In other words, slices should not 312 be fragmented across packet boundaries. The only reasonable need 313 for a slice to be fragmented across packet boundaries is when the 314 encoder which generated the H.263+ data stream could not be 315 influenced by an awareness of the packetization process (such as 316 when sending H.263+ data through a network other than the one to 317 which the encoder is attached, as in network gateway 318 implementations). Optimally, each packet will contain only one 319 slice. 321 o The independent segment decoding (ISD) described in Annex R of 322 [H263P] prevents any data dependency across slice or GOB 323 boundaries in the reference picture. It can be utilized to 324 further improve resiliency in high loss conditions. 326 o If ISD is used in conjunction with the slice structure, the 327 rectangular slice submode shall be enabled and the dimensions and 328 quantity of the slices present in a frame shall remain the same 329 between each two intra-coded frames (I-frames), as required in 330 H.263+. The individual ISD segments may also be entirely intra 331 coded from time to time to realize quick error recovery without 332 adding the latency time associated with sending complete INTRA- 333 pictures. 335 o When the slice structure is not applied, the insertion of a 336 (preferably byte-aligned) GOB header can be used to provide resync 337 boundaries in the bitstream, as the presence of a GOB header 338 eliminates the dependency of motion vector prediction across GOB 339 boundaries. These resync boundaries provide natural locations for 340 packet payload boundaries. 342 o H.263+ allows picture headers to be sent in an abbreviated form in 343 order to prevent repetition of overhead information that does not 344 change from picture to picture. For resiliency, sending a 345 complete picture header for every frame is often advisable. This 346 means that (especially in cases with high packet loss probability 347 in which picture header contents are not expected to be highly 348 predictable), the sender may find it advisable to always set the 349 subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. 350 (See [H263P] for the definition of the UFEP and PLUSPTYPE fields). 352 o In a multi-layer scenario, each layer may be transmitted to a 353 different network address. The configuration of each layer such 354 as the enhancement layer number (ELNUM), reference layer number 355 (RLNUM), and scalability type should be determined at the start of 356 the session and should not change during the course of the 357 session. 359 o All start codes can be byte aligned, and picture, slice, and EOSBS 360 start codes are always byte aligned. The boundaries of these 361 syntactical elements provide ideal locations for placing packet 362 boundaries. 364 o We assume that a maximum Picture Header size of 504 bits is 365 sufficient. The syntax of H.263+ does not explicitly prohibit 366 larger picture header sizes, but the use of such extremely large 367 picture headers is not expected. 369 5. H.263+ Payload Header 371 For H.263+ video streams, each RTP packet shall carry only one H.263+ 372 video packet. The H.263+ payload header shall always be present for 373 each H.263+ video packet. The payload header is of variable length. 374 A 16 bit field of the basic payload header may be followed by an 8 375 bit field for Video Redundancy Coding (VRC) information, and/or by a 376 variable length extra picture header as indicated by PLEN. These 377 optional fields appear in the order given above when present. 379 If an extra picture header is included in the payload header, the 380 length of the picture header in number of bytes is specified by PLEN. 381 The minimum length of the payload header is 16 bits, corresponding to 382 PLEN equal to 0 and no VRC information present. 384 The remainder of this section defines the various components of the 385 RTP payload header. Section six defines the various packet types 386 that are used to carry different types of H.263+ coded data, and 387 section seven summarizes how to distinguish between the various 388 packet types. 390 5.1. General H.263+ payload header 392 The H.263+ payload header is structured as follows: 394 0 1 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | RR |P|V| PLEN |PEBIT| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 RR: 5 bits 402 Reserved bits. SHALL be zero. MUST be ignored by receivers 404 P: 1 bit 406 Indicates the picture start or a picture segment (GOB/Slice) start 407 or a video sequence end (EOS or EOSBS). Two bytes of zero bits 408 then have to be prefixed to the payload of such a packet to 409 compose a complete picture/GOB/slice/EOS/EOSBS start code. This 410 bit allows the omission of the two first bytes of the start codes, 411 thus improving the compression ratio. 413 V: 1 bit 414 Indicates the presence of an 8 bit field containing information 415 for Video Redundancy Coding (VRC), which follows immediately after 416 the initial 16 bits of the payload header if present. For syntax 417 and semantics of that 8 bit VRC field see section 5.2. 419 PLEN: 6 bits 421 Length in bytes of the extra picture header. If no extra picture 422 header is attached, PLEN is 0. If PLEN>0, the extra picture 423 header is attached immediately following the rest of the payload 424 header. Note the length reflects the omission of the first two 425 bytes of the picture start code (PSC). See section 6.1. 427 PEBIT: 3 bits 429 Indicates the number of bits that shall be ignored in the last 430 byte of the picture header. If PLEN is not zero, the ignored bits 431 shall be the least significant bits of the byte. If PLEN is zero, 432 then PEBIT shall also be zero. 434 5.2. Video Redundancy Coding Header Extension 436 Video Redundancy Coding (VRC) is an optional mechanism intended to 437 improve error resilience over packet networks. Implementing VRC in 438 H.263+ will require the Reference Picture Selection option described 439 in Annex N of [H263P]. By having multiple "threads" of independently 440 inter-frame predicted pictures, damage of individual frame will cause 441 distortions only within its own thread but leave the other threads 442 unaffected. From time to time, all threads converge to a so-called 443 sync frame (an INTRA picture or a non-INTRA picture which is 444 redundantly represented within multiple threads); from this sync 445 frame, the independent threads are started again. For more 446 information on codec support for VRC see [Vredun]. 448 P-picture temporal scalability is another use of the reference 449 picture selection mode and can be considered a special case of VRC in 450 which only one copy of each sync frame may be sent. It offers a 451 thread-based method of temporal scalability without the increased 452 delay caused by the use of B pictures. In this use, sync frames sent 453 in the first thread of pictures are also used for the prediction of a 454 second thread of pictures which fall temporally between the sync 455 frames to increase the resulting frame rate. In this use, the 456 pictures in the second thread can be discarded in order to obtain a 457 reduction of bit rate or decoding complexity without harming the 458 ability to decode later pictures. A third or more threads can also 459 be added as well, but each thread is predicted only from the sync 460 frames (which are sent at least in thread 0) or from frames within 461 the same thread. 463 While a VRC data stream is - like all H.263+ data - totally self- 464 contained, it may be useful for the transport hierarchy 465 implementation to have knowledge about the current damage status of 466 each thread. On the Internet, this status can easily be determined 467 by observing the marker bit, the sequence number of the RTP header, 468 and the thread-id and a circling "packet per thread" number. The 469 latter two numbers are coded in the VRC header extension. 471 The format of the VRC header extension is as follows: 473 0 1 2 3 4 5 6 7 474 +-+-+-+-+-+-+-+-+ 475 | TID | Trun |S| 476 +-+-+-+-+-+-+-+-+ 478 TID: 3 bits 480 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 481 data will use as reference information only sync frames or frames 482 within the same thread. By convention, thread 0 is expected to be 483 the "canonical" thread, which is the thread from which the sync frame 484 should ideally be used. In the case of corruption or loss of the 485 thread 0 representation, a representation of the sync frame with a 486 higher thread number can be used by the decoder. Lower thread 487 numbers are expected to contain equal or better representations of 488 the sync frames than higher thread numbers in the absence of data 489 corruption or loss. See [Vredun] for a detailed discussion of VRC. 491 Trun: 4 bits 493 Monotonically increasing (modulo 16) 4 bit number counting the packet 494 number within each thread. 496 S: 1 bit 498 A bit that indicates that the packet content is for a sync frame. An 499 encoder using VRC may send several representations of the same "sync" 500 picture, in order to ensure that regardless of which thread of 501 pictures is corrupted by errors or packet losses, the reception of at 502 least one representation of a particular picture is ensured (within 503 at least one thread). The sync picture can then be used for the 504 prediction of any thread. If packet losses have not occurred, then 505 the sync frame contents of thread 0 can be used and those of other 506 threads can be discarded (and similarly for other threads). Thread 0 507 is considered the "canonical" thread, the use of which is preferable 508 to all others. The contents of packets having lower thread numbers 509 shall be considered as having a higher processing and delivery 510 priority than those with higher thread numbers. Thus packets having 511 lower thread numbers for a given sync frame shall be delivered first 512 to the decoder under loss-free and low-time-jitter conditions, which 513 will result in the discarding of the sync contents of the higher- 514 numbered threads as specified in Annex N of [H263P]. 516 6. Packetization schemes 518 6.1. Picture Segment Packets and Sequence Ending Packets (P=1) 520 A picture segment packet is defined as a packet that starts at the 521 location of a Picture, GOB, or slice start code in the H.263+ data 522 stream. This corresponds to the definition of the start of a video 523 picture segment as defined in H.263+. For such packets, P=1 always. 525 An extra picture header can sometimes be attached in the payload 526 header of such packets. Whenever an extra picture header is attached 527 as signified by PLEN>0, only the last six bits of its picture start 528 code, '100000', are included in the payload header. A complete 529 H.263+ picture header with byte aligned picture start code can be 530 conveniently assembled on the receiving end by prepending the sixteen 531 leading '0' bits. 533 When PLEN>0, the end bit position corresponding to the last byte of 534 the picture header data is indicated by PEBIT. The actual bitstream 535 data shall begin on an 8-bit byte boundary following the payload 536 header. 538 A sequence ending packet is defined as a packet that starts at the 539 location of an EOS or EOSBS code in the H.263+ data stream. This 540 delineates the end of a sequence of H.263+ video data (more H.263+ 541 video data may still follow later, however, as specified in ITU-T 542 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 544 The optional header extension for VRC may or may not be present as 545 indicated by the V bit flag. 547 6.1.1. Packets that begin with a Picture Start Code 549 Any packet that contains the whole or the start of a coded picture 550 shall start at the location of the picture start code (PSC), and 551 should normally be encapsulated with no extra copy of the picture 552 header. In other words, normally PLEN=0 in such a case. However, if 553 the coded picture contains an incomplete picture header (UFEP = 554 "000"), then a representation of the complete (UFEP = "001") picture 555 header may be attached during packetization in order to provide 556 greater error resilience. Thus, for packets that start at the 557 location of a picture start code, PLEN shall be zero unless both of 558 the following conditions apply: 560 1) The picture header in the H.263+ bitstream payload is incomplete 561 (PLUSPTYPE present and UFEP="000"), and 563 2) The additional picture header which is attached is not incomplete 564 (UFEP="001"). 566 A packet which begins at the location of a Picture, GOB, slice, EOS, 567 or EOSBS start code shall omit the first two (all zero) bytes from 568 the H.263+ bitstream, and signify their presence by setting P=1 in 569 the payload header. 571 Here is an example of encapsulating the first packet in a frame 572 (without an attached redundant complete picture header): 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | first two 0 bytes of the PSC 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 6.1.2. Packets that begin with GBSC or SSC 584 For a packet that begins at the location of a GOB or slice start 585 code, PLEN may be zero or may be nonzero, depending on whether a 586 redundant picture header is attached to the packet. In environments 587 with very low packet loss rates, or when picture header contents are 588 very seldom likely to change (except as can be detected from the GFID 589 syntax of H.263+), a redundant copy of the picture header is not 590 required. However, in less ideal circumstances a redundant picture 591 header should be attached for enhanced error resilience, and its 592 presence is indicated by PLEN>0. 594 Assuming a PLEN of 9 and P=1, below is an example of a packet that 595 begins with a byte aligned GBSC or a SSC: 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | starting with TR, PTYPE ... | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | ... | bitstream | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | data starting with GBSC/SSC without its first two 0 bytes 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Notice that only the last six bits of the picture start code, 610 '100000', are included in the payload header. A complete H.263+ 611 picture header with byte aligned picture start code can be 612 conveniently assembled if needed on the receiving end by prepending 613 the sixteen leading '0' bits. 615 6.1.3. Packets that Begin with an EOS or EOSBS Code 617 For a packet that begins with an EOS or EOSBS code, PLEN shall be 618 zero, and no Picture, GOB, or Slice start codes shall be included 619 within the same packet. As with other packets beginning with start 620 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 621 beginning of the packet shall be omitted, and their presence shall be 622 indicated by setting the P bit to 1 in the payload header. 624 System designers should be aware that some decoders may interpret the 625 loss of a packet containing only EOS or EOSBS information as the loss 626 of essential video data and may thus respond by not displaying some 627 subsequent video information. Since EOS and EOSBS codes do not 628 actually affect the decoding of video pictures, they are somewhat 629 unnecessary to send at all. Because of the danger of 630 misinterpretation of the loss of such a packet (which can be detected 631 by the sequence number), encoders are generally to be discouraged 632 from sending EOS and EOSBS. 634 Below is an example of a packet containing an EOS code: 636 0 1 2 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 6.2. Encapsulating Follow-On Packet (P=0) 644 A Follow-on packet contains a number of bytes of coded H.263+ data 645 which does not start at a synchronization point. That is, a 646 Follow-On packet does not start with a Picture, GOB, Slice, EOS, or 647 EOSBS header, and it may or may not start at a macroblock boundary. 648 Since Follow-on packets do not start at synchronization points, the 649 data at the beginning of a follow-on packet is not independently 650 decodable. For such packets, P=0 always. If the preceding packet of 651 a Follow-on packet got lost, the receiver may discard that Follow-on 652 packet as well as all other following Follow-on packets. Better 653 behavior, of course, would be for the receiver to scan the interior 654 of the packet payload content to determine whether any start codes 655 are found in the interior of the packet which can be used as resync 656 points. The use of an attached copy of a picture header for a 657 follow-on packet is useful only if the interior of the packet or some 658 subsequent follow-on packet contains a resync code such as a GOB or 659 slice start code. PLEN>0 is allowed, since it may allow resync in 660 the interior of the packet. The decoder may also be resynchronized 661 at the next segment or picture packet. 663 Here is an example of a follow-on packet (with PLEN=0): 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 668 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 671 7. Use of this payload specification 673 There is no syntactical difference between a picture segment packet 674 and a Follow-on packet, other than the indication P=1 for picture 675 segment or sequence ending packets and P=0 for Follow-on packets. 676 See the following for a summary of the entire packet types and ways 677 to distinguish between them. 679 It is possible to distinguish between the different packet types by 680 checking the P bit and the first 6 bits of the payload along with the 681 header information. The following table shows the packet type for 682 permutations of this information (see also the picture/GOB/Slice 683 header descriptions in H.263+ for details): 685 -------------+--------------+----------------------+---------------- 686 First 6 bits | P-Bit | PLEN | Packet | Remarks 687 of Payload |(payload hdr.)| | 688 -------------+--------------+----------------------+---------------- 689 100000 | 1 | 0 | Picture | Typical Picture 690 100000 | 1 | > 0 | Picture | Note UFEP 691 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 692 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 693 Xxxxxx | 0 | 0 | Follow-on | 694 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 695 -------------+--------------+----------------------+---------------- 697 The details regarding the possible values of the five bit Group 698 Number (GN) field which follows the initial "1" bit when the P-bit is 699 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 700 of H.263[H263P]. 702 As defined in this specification, every start of a coded frame (as 703 indicated by the presence of a PSC) has to be encapsulated as a 704 picture segment packet. If the whole coded picture fits into one 705 packet of reasonable size (which is dependent on the connection 706 characteristics), this is the only type of packet that may need to be 707 used. Due to the high compression ratio achieved by H.263+ it is 708 often possible to use this mechanism, especially for small spatial 709 picture formats such as QCIF and typical Internet packet sizes around 710 1500 bytes. 712 If the complete coded frame does not fit into a single packet, two 713 different ways for the packetization may be chosen. In case of very 714 low or zero packet loss probability, one or more Follow-on packets 715 may be used for coding the rest of the picture. Doing so leads to 716 minimal coding and packetization overhead as well as to an optimal 717 use of the maximal packet size, but does not provide any added error 718 resilience. 720 The alternative is to break the picture into reasonably small 721 partitions - called Segments - (by using the Slice or GOB mechanism), 722 that do offer synchronization points. By doing so and using the 723 Picture Segment payload with PLEN>0, decoding of the transmitted 724 packets is possible even in such cases in which the Picture packet 725 containing the picture header was lost (provided any necessary 726 reference picture is available). Picture Segment packets can also be 727 used in conjunction with Follow-on packets for large segment sizes. 729 8. IANA Considerations 731 This section updates the H.263(1998) and H.263 (2000) media types 732 described in RFC3555 [RFC3555]. 734 This section specifies optional parameters that MAY be used to select 735 optional features of the H.263 codec. The parameters are specified 736 here as part of the MIME subtype registration for the ITU-T H.263 737 codec. A mapping of the parameters into the Session Description 738 Protocol (SDP)[I-D.ietf-mmusic-sdp-new] is also provided for those 739 applications that use SDP. Multiple parameters SHOULD be expressed 740 as a MIME media type string, in the form of a semicolon separated 741 list of parameter=value pairs 743 8.1. Media Type Registrations 745 This section describes the Media types and names associated with this 746 payload format. The section updates the previous registered version 747 in RFC 3555 [RFC3555]. 749 8.1.1. Registration of MIME media type video/H263-1998 751 MIME media type name: video 753 MIME subtype name: H263-1998 755 Required parameters: None 757 Optional parameters: 759 SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF 760 resolution. Permissible value are integer values from 1 to 32, 761 which correspond to a maximum frame rate of 29.97/ the specified 762 value frames per second. 764 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 765 resolution. Permissible value are integer values from 1 to 32, 766 which correspond to a maximum frame rate of 29.97/ the specified 767 value frames per second. 769 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 770 resolution. Permissible value are integer values from 1 to 32, 771 which correspond to a maximum frame rate of 29.97/ the specified 772 value frames per second. 774 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 775 resolution. Permissible value are integer values from 1 to 32, 776 which correspond to a maximum frame rate of 29.97/ the specified 777 value frames per second. 779 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 780 resolution. Permissible value are integer values from 1 to 32, 781 which correspond to a maximum frame rate of 29.97/ the specified 782 value frames per second. 784 CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom 785 defined resolution. The custom parameter receives three comma 786 separated values Xmax , Ymax and MPI. The Xmax and Ymax 787 parameters describe the number of pixels in the X and Y axis and 788 must be evenly dividable by 4. The permissible value for MPI, are 789 integer values from 1 to 32, which correspond to a maximum frame 790 rate of 29.97/ the specified value. 792 A system that declares support of a specific MPI for one of the 793 resolutions SHALL also implicitly support a lower resolution with 794 the same MPI. 796 A list of optional annexes specifies which annexes of H.263 are 797 supported. The optional annexes are defined as part of H263-1998, 798 H263-2000. Annex X of H.263-2000 defines profiles which group 799 annexes for specific applications. A system that support a 800 specific annex SHALL specify it support using the optional 801 parameters. If no annex is specified than the stream is Baseline 802 H.263. 804 The allowed optional parameters for the annexes are "F", "I", "J", 805 "T", "K", "N" and "P". 807 "F", "I", "J", "T" if supported SHALL have the values "1". If not 808 supported it should not be listed or SHALL have the value "0". 810 "K" can receive one of four values 1-4: 812 1: - Slices In Order-Non Rectangular 814 2: - Slices In Order-Rectangular 816 3: - Slices Not Ordered - Non Rectangular 818 4: - Slices Not Ordered - Rectangular 819 "N" - Reference Picture Selection mode - Four numeric choices 820 (1-4) are available representing the following modes: 822 1: NEITHER: In which no back-channel data is returned from the 823 decoder to the encoder. 825 2: ACK: In which the decoder returns only acknowledgment messages. 827 3: NACK: In which the decoder returns only non-acknowledgment 828 messages 830 4: ACK+NACK: In which the decoder returns both acknowledgment and 831 non-acknowledgment messages. 833 No special provision is made herein for carrying back channel 834 information. The Extended RTP Profile for RTCP-based Feedback 835 [AVPF] MAY be used as a back channel mechanism. 837 "P" - Reference Picture Resampling with the following submodes 838 represented as a number fro 1 to 4: 840 1: dynamicPictureResizingByFour 842 2: dynamicPictureResizingBySixteenthPel 844 3: dynamicWarpingHalfPel 846 4: dynamicWarpingSixteenthPel 848 Example: P=1,3 850 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height 851 ratio by two colon separated integers between 0 and 255. Default 852 ratio is 12:11 if not otherwise specified. 854 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a 855 floating point value. Default value is 29.97 Hz. 857 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 858 bits allowed to represent a single picture. If this parameter is 859 not present, then the default value, based on the maximum 860 supported resolution, is used. BPP is integer value between 0 and 861 65536. 863 HRD - Hypothetical Reference Decoder: See annex B of H.263 864 specification[H263P]. This parameter if supported SHALL have the 865 values "1". If not supported it should not be listed or SHALL 866 have the value "0". 868 Encoding considerations: 870 This media type is framed and binary, see section 4.8 in[I- 871 D.freed-media-type-reg] 873 Security considerations: See Section 10 875 Interoperability considerations: 877 These are receiver options, current implementations will not send 878 any optional parameters in their SDP. They will ignore the 879 optional parameters and will encode the H.263 stream without any 880 of the annexes. Most decoders support at least QCIF and CIF fixed 881 resolutions and they are expected to be available almost in every 882 H.263 based video application. 884 Published specification: RFC yyy ( This RFC) 886 Applications which use this media type: 888 Audio and video streaming and conferencing tools. 890 Additional information: none 892 Person and email address to contact for further information : 894 Roni Even: roni.even@polycom.co.il 896 Intended usage: COMMON 898 Restrictions on usage: 900 This media type depends on RTP framing, and hence is only defined 901 for transfer via RTP[RFC3550]. Transport within other framing 902 protocols is not defined at this time. 904 Author: Roni Even 906 Change controller: 908 IETF Audio/Video Transport working group delegated from the IESG. 910 8.1.2. Registration of MIME media type video/H263-2000 912 MIME media type name: video 914 MIME subtype name: H263-2000 916 Required parameters: None 918 Optional parameters: 920 The optional parameters of the H263-1998 type MAY be used with 921 this MIME subtype. Specific optional parameters that may be used 922 with the H263-2000 type are: 924 PROFILE: H.263 profile number, in the range 0 through 10, 925 specifying the supported H.263 annexes/subparts based on H.263 926 annex X[H263X]. The annexes supported in each profile are listed 927 in table X.1 of H.263 annex X. If no profile or H.263 annex is 928 specified than the stream is Baseline H.263 (profile 0 of H.263 929 annex X). 931 LEVEL: Level of bitstream operation, in the range 0 through 100, 932 specifying the level of computational complexity of the decoding 933 process. The level are described in table X.2 of H.263 annex X. 935 According to H.263 annex X, support of any level other than level 936 45 implies support of all lower levels. Support of level 45 937 implies support of level 10 939 A system that specifies support of a PROFILE MUST specify the 940 supported LEVEL. 942 INTERLACE: Interlaced or 60 fields indicates the support for 943 interlace display mode. This parameter if supported SHALL have 944 the values "1". If not supported it should not be listed or SHALL 945 have the value "0" 947 Encoding considerations: 949 This media type is framed and binary, see section 4.8 in[I- 950 D.freed-media-type-reg] 952 Security considerations: See Section 10 954 Interoperability considerations: 956 The optional parameters PROFILE and LEVEL SHALL NOT be used with 957 any of the other optional parameters. 959 Published specification: RFC yyy 961 Applications which use this media type: 963 Audio and video streaming and conferencing tools. 965 Additional information: none 967 Person and email address to contact for further information : 969 Roni Even: roni.even@polycom.co.il 971 Intended usage: COMMON 973 Restrictions on usage: 975 This media type depends on RTP framing, and hence is only defined 976 for transfer via RTP[RFC3550]. Transport within other framing 977 protocols is not defined at this time. 979 Author: Roni Even 981 Change controller: 983 IETF Audio/Video Transport working group delegated from the IESG. 985 8.2. SDP Parameters 987 The media types video/H263-1998 and video/H263-2000 are mapped to 988 fields in the Session Description Protocol (SDP) as follows: 990 o The media name in the "m=" line of SDP MUST be video. 992 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 993 or H263-2000 (the MIME subtype). 995 o The clock rate in the "a=rtpmap" line MUST be 90000. 997 o The optional parameters if any, MUST be included in the "a=fmtp" 998 line of SDP. These parameters are expressed as a media type string, 999 in the form of a semicolon separated list of parameter=value pairs. 1000 The optional parameters PROFILE and LEVEL SHALL NOT be used with any 1001 of the other optional parameters. 1003 8.2.1. Usage with the SDP Offer Answer Model 1005 When offering H.263 over RTP using SDP in an Offer/Answer 1006 model[RFC3264] the following considerations are necessary. 1008 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 1009 the sender of these SDP parameters is able to decode those options. 1010 These options are receiver's capability even when send in a 1011 "sendonly" offer. 1013 Profile: The offer of a SDP profile parameter signal that the sender 1014 can decode a stream that uses the specified profile. Each profile 1015 uses different H.263 annexes so there is no implied relationship 1016 between them. In the offer/answer exchange this parameter SHOULD be 1017 the same in the offer and answer. A decoder that support a profile 1018 SHALL also support H.263 baseline profile (profile 0). 1020 Picture sizes and MPI: 1022 Supported picture sizes and their corresponding minimum picture 1023 interval (MPI) information for H.263 can be combined. All picture 1024 sizes can be advertised to the other party, or only a subset of it. 1025 Terminal announces only those picture sizes (with their MPIs) which 1026 it is willing to receive. For example, MPI=2 means that maximum 1027 (decodable) picture rate per second is about 15. 1029 If the receiver does not specify the picture size /MPI optional 1030 parameter then it SHOULD be ready to receive QCIF resolution with 1031 MPI=1. 1033 Parameters offered first are the most preferred picture mode to be 1034 received. 1036 Example of the usage of these parameters: 1038 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 1040 This means that encoder SHOULD send CIF picture size, which it can 1041 decode at MPI=4. If that is not possible, then QCIF with MPI value 1042 3, if neither are possible, then SQCIF with MPI value=2. The 1043 receiver is able of (but least preferred) decoding custom picture 1044 sizes (max 360x240) with MPI=2. Note that most decoders support at 1045 least QCIF and CIF fixed resolutions and they are expected to be 1046 available almost in every H.263 based video application. 1048 Below is an example of H.263 SDP in an offer. 1050 a=fmtp:xx CIF=4;QCIF=2;F=1;K=1 1051 This means that the sender of this message can decode H.263 bit 1052 stream with following options and parameters: Preferred resolution is 1053 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 1054 AP and slicesInOrder-NonRect options MAY be used. 1056 9. Backward Compatibility to RFC2429 1058 The current draft updates RFC2429. This section will address the 1059 backward compatibility issues. 1061 9.1. New SDP optional parameters 1063 The draft adds new optional parameters to the H263-1998 and H263-2000 1064 payload type. Since these are optional parameters we expect old 1065 implementation to ignore these parameters while new implementations 1066 that will receive the H263-1998 and H263-2000 payload type with no 1067 parameters will behave as if the other side can accept H.263 at QCIF 1068 resolution and 30 frames per second. 1070 10. Security Considerations 1072 RTP packets using the payload format defined in this specification 1073 are subject to the security considerations discussed in the RTP 1074 specification [RFC3550], and any appropriate RTP profile (for example 1075 [RFC3551]). This implies that confidentiality of the media streams 1076 is achieved by encryption. Because the data compression used with 1077 this payload format is applied end-to-end, encryption may be 1078 performed after compression so there is no conflict between the two 1079 operations. 1081 A potential denial-of-service threat exists for data encoding using 1082 compression techniques that have non-uniform receiver-end 1083 computational load. The attacker can inject pathological datagrams 1084 into the stream which are complex to decode and cause the receiver to 1085 be overloaded. The usage of authentication of at least the RTP 1086 packet is RECOMMENDED 1088 As with any IP-based protocol, in some circumstances a receiver may 1089 be overloaded simply by the receipt of too many packets, either 1090 desired or undesired. Network-layer authentication may be used to 1091 discard packets from undesired sources, but the processing cost of 1092 the authentication itself may be too high. In a multicast 1093 environment, pruning of specific sources may be implemented in future 1094 versions of IGMP [RFC2032] and in multicast routing protocols to 1095 allow a receiver to select which sources are allowed to reach it. 1097 A security review of this payload format found no additional 1098 considerations beyond those in the RTP specification. 1100 11. Acknowledgements 1102 This is to acknowledge the work done by Carsten Bormann from 1103 Universitaet Bremen and Chad Zhu, Linda Cline, Gim Deisher, Tom 1104 Gardos, Christian Maciocco, Donald Newell from Intel Corp. who co- 1105 authored RFC2429. 1107 I would also like to acknowledge the work of Petri Koskelainen from 1108 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1109 for the new media types. 1111 12. Changes from previous versions of the document 1113 12.1. changes from RFC 2429 1115 The changes from the RFC 2429 are: 1117 1. The H.263 1998 and 2000 MIME type are now in the payload 1118 specification. 1120 2. Added optional parameters to the H.263 1998 and 2000 MIME types 1122 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload 1123 format should be used only to interact with legacy systems. 1125 13. References 1127 13.1. Normative References 1129 [H263] International Telecommunications Union, "Video coding for 1130 low bit rate communication", ITU Recommendation H.263, 1131 March 1996. 1133 [H263P] International Telecommunications Union, "Video coding for 1134 low bit rate communication", ITU Recommendation H.263P, 1135 February 1998. 1137 [H263X] International Telecommunications Union, "Annex X: Profiles 1138 and levels definition", ITU Recommendation H.263AnxX, 1139 April 2001. 1141 [I-D.ietf-mmusic-sdp-new] 1142 Handley, M., "SDP: Session Description Protocol", 1143 draft-ietf-mmusic-sdp-new-25 (work in progress), 1144 July 2005. 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", BCP 14, RFC 2119, March 1997. 1149 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1150 Jacobson, "RTP: A Transport Protocol for Real-Time 1151 Applications", STD 64, RFC 3550, July 2003. 1153 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1154 Video Conferences with Minimal Control", STD 65, RFC 3551, 1155 July 2003. 1157 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1158 Payload Formats", RFC 3555, July 2003. 1160 13.2. Informative References 1162 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1163 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1164 January 2004. 1166 [I-D.freed-media-type-reg] 1167 Freed, N. and J. Klensin, "Media Type Specifications and 1168 Registration Procedures", draft-freed-media-type-reg-05 1169 (work in progress), August 2005. 1171 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1172 Streams", RFC 2032, October 1996. 1174 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", 1175 RFC 2190, September 1997. 1177 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1178 with Session Description Protocol (SDP)", RFC 3264, 1179 June 2002. 1181 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1182 Audio-Visual Services over Packet Networks, Aberdeen, 1183 U.K. 9/1997, September 1997. 1185 Authors' Addresses 1187 Joerg Ott 1188 Univ. Bremen 1190 Email: jo@acm.org 1192 Gary Sullivan 1193 Microsoft 1195 Email: garysull@windows.microsoft.com 1197 Stephan Wenger 1198 TU Berlin 1200 Email: stewe@cs.tu-berlin.de 1202 Roni Even (editor) 1203 Polycom 1204 94 Derech Em Hamoshavot 1205 Petach Tikva 49130 1206 Israel 1208 Email: roni.even@polycom.co.il 1210 Intellectual Property Statement 1212 The IETF takes no position regarding the validity or scope of any 1213 Intellectual Property Rights or other rights that might be claimed to 1214 pertain to the implementation or use of the technology described in 1215 this document or the extent to which any license under such rights 1216 might or might not be available; nor does it represent that it has 1217 made any independent effort to identify any such rights. Information 1218 on the procedures with respect to rights in RFC documents can be 1219 found in BCP 78 and BCP 79. 1221 Copies of IPR disclosures made to the IETF Secretariat and any 1222 assurances of licenses to be made available, or the result of an 1223 attempt made to obtain a general license or permission for the use of 1224 such proprietary rights by implementers or users of this 1225 specification can be obtained from the IETF on-line IPR repository at 1226 http://www.ietf.org/ipr. 1228 The IETF invites any interested party to bring to its attention any 1229 copyrights, patents or patent applications, or other proprietary 1230 rights that may cover technology that may be required to implement 1231 this standard. Please address the information to the IETF at 1232 ietf-ipr@ietf.org. 1234 Disclaimer of Validity 1236 This document and the information contained herein are provided on an 1237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1244 Copyright Statement 1246 Copyright (C) The Internet Society (2005). This document is subject 1247 to the rights, licenses and restrictions contained in BCP 78, and 1248 except as set forth therein, the authors retain all their rights. 1250 Acknowledgment 1252 Funding for the RFC Editor function is currently provided by the 1253 Internet Society.