idnits 2.17.1 draft-ietf-avt-rfc2429-bis-05.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 1225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1215. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages 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 (April 26, 2005) is 6911 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: 'H263X' is defined on line 1122, 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' ** Obsolete normative reference: RFC 2032 (Obsoleted by RFC 4587) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Downref: Normative reference to an Historic RFC: RFC 2190 ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Possible downref: Non-RFC (?) normative reference: ref. 'Vredun' Summary: 8 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: October 28, 2005 G. Sullivan 5 Microsoft 6 S. Wenger 7 TU Berlin 8 R. Even 9 Polycom 10 April 26, 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-05.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 October 28, 2005. 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 . . . 24 78 8.2 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 25 79 8.2.1 Usage with the SDP Offer Answer Model . . . . . . . . 26 80 9. Backward Compatibility to RFC2429 . . . . . . . . . . . . . . 28 81 9.1 New SDP optional parameters . . . . . . . . . . . . . . . 28 82 10. Security Considerations . . . . . . . . . . . . . . . . . . 29 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 84 12. Changes from previous versions of the document . . . . . . . 31 85 12.1 changes from RFC 2429 . . . . . . . . . . . . . . . . . . 31 86 12.2 Changes from rfc2429-bis-00 . . . . . . . . . . . . . . . 31 87 12.3 Changes from rfc2429-bis-03 . . . . . . . . . . . . . . . 31 88 12.4 Changes from rfc2429-bis-03 . . . . . . . . . . . . . . . 31 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 13.1 Normative References . . . . . . . . . . . . . . . . . . . 32 91 13.2 Informative References . . . . . . . . . . . . . . . . . . 33 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 93 Intellectual Property and Copyright Statements . . . . . . . . 34 95 1. Introduction 97 This document specifies an RTP payload header format applicable to 98 the transmission of video streams generated based on the 1998 and 99 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 100 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, 101 this format can also be used with the 1996 version of H.263 [H263], 102 and is recommended for this use by new implementations. This format 103 replaces the payload format in RFC 2190[RFC2190], which continues to 104 be used by some existing implementations, and can be useful for 105 backward compatibility. New implementations supporting H.263 will 106 use the payload format described in this document. 108 This document updates 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 are used for H.263+ video streams: 199 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 200 the current packet carries the end of current frame, and is 0 201 otherwise. 203 Payload Type (PT): The RTP profile for a particular class of 204 applications will assign a payload type for this encoding, or if that 205 is not done, then a payload type in the dynamic range shall be chosen 206 by the sender. 208 Timestamp: The RTP Timestamp encodes the sampling instance of the 209 first video frame data contained in the RTP data packet. The RTP 210 timestamp shall be the same on successive packets if a video frame 211 occupies more than one packet. In a multilayer scenario, all 212 pictures corresponding to the same temporal reference should use the 213 same timestamp. If temporal scalability is used (if B-frames are 214 present), the timestamp may not be monotonically increasing in the 215 RTP stream. If B-frames are transmitted on a separate layer and 216 address, they must be synchronized properly with the reference 217 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 218 information on required transmission order to a decoder. For an 219 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 220 the same as that of the RTP payload for H.261 stream [RFC2032]. 221 Since both the H.263+ data and the RTP header contain time 222 information, those timing information must run synchronously. That 223 is, both the RTP timestamp and the temporal reference (TR in the 224 picture header of H.263) should carry the same relative timing 225 information. Any H.263+ picture clock frequency can be expressed as 226 1800000/(cd*cf) source pictures per second, in which cd is an integer 227 from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock 228 of the RTP timestamp, the time increment between each coded H.263+ 229 picture should therefore be a integer multiple of (cd*cf)/20. This 230 will always be an integer for any "reasonable" picture clock 231 frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz 232 PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer 233 display update rates of 60, 72 and 75 Hz, respectively). For RTP 234 packetization of hypothetical H.263+ bitstreams using "unreasonable" 235 custom picture clock frequencies, mathematical rounding could become 236 necessary for generating the RTP timestamps. 238 3.2 Video Packet Structure 240 A section of an H.263+ compressed bitstream is carried as a payload 241 within each RTP packet. For each RTP packet, the RTP header is 242 followed by an H.263+ payload header, which is followed by a number 243 of bytes of a standard H.263+ compressed bitstream. The size of the 244 H.263+ payload header is variable depending on the payload involved 245 as detailed in the section 4. The layout of the RTP H.263+ video 246 packet is shown as: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | RTP Header 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | H.263+ Payload Header 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | H.263+ Compressed Data Stream 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Any H.263+ start codes can be byte aligned by an encoder by using the 259 stuffing mechanisms of H.263+. As specified in H.263+, picture, 260 slice, and EOSBS starts codes shall always be byte aligned, and GOB 261 and EOS start codes may be byte aligned. For packetization purposes, 262 GOB start codes should be byte aligned; however, since this is not 263 required in H.263+, there may be some cases where GOB start codes are 264 not aligned, such as when transmitting existing content, or when 265 using H.263 encoders that do not support GOB start code alignment. 266 In this case, follow-on packets (see section 5.2) should be used for 267 packetization. 269 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 270 with 16 zero-valued bits. If a start code is byte aligned and it 271 occurs at the beginning of a packet, these two bytes shall be removed 272 from the H.263+ compressed data stream in the packetization process 273 and shall instead be represented by setting a bit (the P bit) in the 274 payload header. 276 4. Design Considerations 278 The goals of this payload format are to specify an efficient way of 279 encapsulating an H.263+ standard compliant bitstream and to enhance 280 the resiliency towards packet losses. Due to the large number of 281 different possible coding schemes in H.263+, a copy of the picture 282 header with configuration information is inserted into the payload 283 header when appropriate. The use of that copy of the picture header 284 along with the payload data can allow decoding of a received packet 285 even in such cases in which another packet containing the original 286 picture header becomes lost. 288 There are a few assumptions and constraints associated with this 289 H.263+ payload header design. The purpose of this section is to 290 point out various design issues and also to discuss several coding 291 options provided by H.263+ that may impact the performance of 292 network-based H.263+ video. 294 o The optional slice structured mode described in Annex K of H.263+ 295 [H263P] enables more flexibility for packetization. Similar to a 296 picture segment that begins with a GOB header, the motion vector 297 predictors in a slice are restricted to reside within its 298 boundaries. However, slices provide much greater freedom in the 299 selection of the size and shape of the area which is represented 300 as a distinct decodable region. In particular, slices can have a 301 size which is dynamically selected to allow the data for each 302 slice to fit into a chosen packet size. Slices can also be chosen 303 to have a rectangular shape which is conducive for minimizing the 304 impact of errors and packet losses on motion compensated 305 prediction. For these reasons, the use of the slice structured 306 mode is strongly recommended for any applications used in 307 environments where significant packet loss occurs. 309 o In non-rectangular slice structured mode, only complete slices 310 should be included in a packet. In other words, slices should not 311 be fragmented across packet boundaries. The only reasonable need 312 for a slice to be fragmented across packet boundaries is when the 313 encoder which generated the H.263+ data stream could not be 314 influenced by an awareness of the packetization process (such as 315 when sending H.263+ data through a network other than the one to 316 which the encoder is attached, as in network gateway 317 implementations). Optimally, each packet will contain only one 318 slice. 320 o The independent segment decoding (ISD) described in Annex R of 321 [H263P] prevents any data dependency across slice or GOB 322 boundaries in the reference picture. It can be utilized to 323 further improve resiliency in high loss conditions. 325 o If ISD is used in conjunction with the slice structure, the 326 rectangular slice submode shall be enabled and the dimensions and 327 quantity of the slices present in a frame shall remain the same 328 between each two intra-coded frames (I-frames), as required in 329 H.263+. The individual ISD segments may also be entirely intra 330 coded from time to time to realize quick error recovery without 331 adding the latency time associated with sending complete INTRA- 332 pictures. 334 o When the slice structure is not applied, the insertion of a 335 (preferably byte-aligned) GOB header can be used to provide resync 336 boundaries in the bitstream, as the presence of a GOB header 337 eliminates the dependency of motion vector prediction across GOB 338 boundaries. These resync boundaries provide natural locations for 339 packet payload boundaries. 341 o H.263+ allows picture headers to be sent in an abbreviated form in 342 order to prevent repetition of overhead information that does not 343 change from picture to picture. For resiliency, sending a 344 complete picture header for every frame is often advisable. This 345 means that (especially in cases with high packet loss probability 346 in which picture header contents are not expected to be highly 347 predictable), the sender may find it advisable to always set the 348 subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. 349 (See [H263P] for the definition of the UFEP and PLUSPTYPE fields). 351 o In a multi-layer scenario, each layer may be transmitted to a 352 different network address. The configuration of each layer such 353 as the enhancement layer number (ELNUM), reference layer number 354 (RLNUM), and scalability type should be determined at the start of 355 the session and should not change during the course of the 356 session. 358 o All start codes can be byte aligned, and picture, slice, and EOSBS 359 start codes are always byte aligned. The boundaries of these 360 syntactical elements provide ideal locations for placing packet 361 boundaries. 363 o We assume that a maximum Picture Header size of 504 bits is 364 sufficient. The syntax of H.263+ does not explicitly prohibit 365 larger picture header sizes, but the use of such extremely large 366 picture headers is not expected. 368 5. H.263+ Payload Header 370 For H.263+ video streams, each RTP packet shall carry only one H.263+ 371 video packet. The H.263+ payload header shall always be present for 372 each H.263+ video packet. The payload header is of variable length. 373 A 16 bit field of the basic payload header may be followed by an 8 374 bit field for Video Redundancy Coding (VRC) information, and/or by a 375 variable length extra picture header as indicated by PLEN. These 376 optional fields appear in the order given above when present. 378 If an extra picture header is included in the payload header, the 379 length of the picture header in number of bytes is specified by PLEN. 380 The minimum length of the payload header is 16 bits, corresponding to 381 PLEN equal to 0 and no VRC information present. 383 The remainder of this section defines the various components of the 384 RTP payload header. Section six defines the various packet types 385 that are used to carry different types of H.263+ coded data, and 386 section seven summarizes how to distinguish between the various 387 packet types. 389 5.1 General H.263+ payload header 391 The H.263+ payload header is structured as follows: 393 0 1 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | RR |P|V| PLEN |PEBIT| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 RR: 5 bits 401 Reserved bits. Shall be zero. MUST be ignored by receivers 403 P: 1 bit 405 Indicates the picture start or a picture segment (GOB/Slice) start 406 or a video sequence end (EOS or EOSBS). Two bytes of zero bits 407 then have to be prefixed to the payload of such a packet to 408 compose a complete picture/GOB/slice/EOS/EOSBS start code. This 409 bit allows the omission of the two first bytes of the start codes, 410 thus improving the compression ratio. 412 V: 1 bit 413 Indicates the presence of an 8 bit field containing information 414 for Video Redundancy Coding (VRC), which follows immediately after 415 the initial 16 bits of the payload header if present. For syntax 416 and semantics of that 8 bit VRC field see section 5.2. 418 PLEN: 6 bits 420 Length in bytes of the extra picture header. If no extra picture 421 header is attached, PLEN is 0. If PLEN>0, the extra picture 422 header is attached immediately following the rest of the payload 423 header. Note the length reflects the omission of the first two 424 bytes of the picture start code (PSC). See section 6.1. 426 PEBIT: 3 bits 428 Indicates the number of bits that shall be ignored in the last 429 byte of the picture header. If PLEN is not zero, the ignored bits 430 shall be the least significant bits of the byte. If PLEN is zero, 431 then PEBIT shall also be zero. 433 5.2 Video Redundancy Coding Header Extension 435 Video Redundancy Coding (VRC) is an optional mechanism intended to 436 improve error resilience over packet networks. Implementing VRC in 437 H.263+ will require the Reference Picture Selection option described 438 in Annex N of [H263P]. By having multiple "threads" of independently 439 inter-frame predicted pictures, damage of individual frame will cause 440 distortions only within its own thread but leave the other threads 441 unaffected. From time to time, all threads converge to a so-called 442 sync frame (an INTRA picture or a non-INTRA picture which is 443 redundantly represented within multiple threads); from this sync 444 frame, the independent threads are started again. For more 445 information on codec support for VRC see [Vredun]. 447 P-picture temporal scalability is another use of the reference 448 picture selection mode and can be considered a special case of VRC in 449 which only one copy of each sync frame may be sent. It offers a 450 thread-based method of temporal scalability without the increased 451 delay caused by the use of B pictures. In this use, sync frames sent 452 in the first thread of pictures are also used for the prediction of a 453 second thread of pictures which fall temporally between the sync 454 frames to increase the resulting frame rate. In this use, the 455 pictures in the second thread can be discarded in order to obtain a 456 reduction of bit rate or decoding complexity without harming the 457 ability to decode later pictures. A third or more threads can also 458 be added as well, but each thread is predicted only from the sync 459 frames (which are sent at least in thread 0) or from frames within 460 the same thread. 462 While a VRC data stream is - like all H.263+ data - totally self- 463 contained, it may be useful for the transport hierarchy 464 implementation to have knowledge about the current damage status of 465 each thread. On the Internet, this status can easily be determined 466 by observing the marker bit, the sequence number of the RTP header, 467 and the thread-id and a circling "packet per thread" number. The 468 latter two numbers are coded in the VRC header extension. 470 The format of the VRC header extension is as follows: 472 0 1 2 3 4 5 6 7 473 +-+-+-+-+-+-+-+-+ 474 | TID | Trun |S| 475 +-+-+-+-+-+-+-+-+ 477 TID: 3 bits 479 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 480 data will use as reference information only sync frames or frames 481 within the same thread. By convention, thread 0 is expected to be 482 the "canonical" thread, which is the thread from which the sync frame 483 should ideally be used. In the case of corruption or loss of the 484 thread 0 representation, a representation of the sync frame with a 485 higher thread number can be used by the decoder. Lower thread 486 numbers are expected to contain equal or better representations of 487 the sync frames than higher thread numbers in the absence of data 488 corruption or loss. See [Vredun] for a detailed discussion of VRC. 490 Trun: 4 bits 492 Monotonically increasing (modulo 16) 4 bit number counting the packet 493 number within each thread. 495 S: 1 bit 497 A bit that indicates that the packet content is for a sync frame. An 498 encoder using VRC may send several representations of the same "sync" 499 picture, in order to ensure that regardless of which thread of 500 pictures is corrupted by errors or packet losses, the reception of at 501 least one representation of a particular picture is ensured (within 502 at least one thread). The sync picture can then be used for the 503 prediction of any thread. If packet losses have not occurred, then 504 the sync frame contents of thread 0 can be used and those of other 505 threads can be discarded (and similarly for other threads). Thread 0 506 is considered the "canonical" thread, the use of which is preferable 507 to all others. The contents of packets having lower thread numbers 508 shall be considered as having a higher processing and delivery 509 priority than those with higher thread numbers. Thus packets having 510 lower thread numbers for a given sync frame shall be delivered first 511 to the decoder under loss-free and low-time-jitter conditions, which 512 will result in the discarding of the sync contents of the higher- 513 numbered threads as specified in Annex N of [H263P]. 515 6. Packetization schemes 517 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) 519 A picture segment packet is defined as a packet that starts at the 520 location of a Picture, GOB, or slice start code in the H.263+ data 521 stream. This corresponds to the definition of the start of a video 522 picture segment as defined in H.263+. For such packets, P=1 always. 524 An extra picture header can sometimes be attached in the payload 525 header of such packets. Whenever an extra picture header is attached 526 as signified by PLEN>0, only the last six bits of its picture start 527 code, '100000', are included in the payload header. A complete 528 H.263+ picture header with byte aligned picture start code can be 529 conveniently assembled on the receiving end by prepending the sixteen 530 leading '0' bits. 532 When PLEN>0, the end bit position corresponding to the last byte of 533 the picture header data is indicated by PEBIT. The actual bitstream 534 data shall begin on an 8-bit byte boundary following the payload 535 header. 537 A sequence ending packet is defined as a packet that starts at the 538 location of an EOS or EOSBS code in the H.263+ data stream. This 539 delineates the end of a sequence of H.263+ video data (more H.263+ 540 video data may still follow later, however, as specified in ITU-T 541 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 543 The optional header extension for VRC may or may not be present as 544 indicated by the V bit flag. 546 6.1.1 Packets that begin with a Picture Start Code 548 Any packet that contains the whole or the start of a coded picture 549 shall start at the location of the picture start code (PSC), and 550 should normally be encapsulated with no extra copy of the picture 551 header. In other words, normally PLEN=0 in such a case. However, if 552 the coded picture contains an incomplete picture header (UFEP = 553 "000"), then a representation of the complete (UFEP = "001") picture 554 header may be attached during packetization in order to provide 555 greater error resilience. Thus, for packets that start at the 556 location of a picture start code, PLEN shall be zero unless both of 557 the following conditions apply: 559 1) The picture header in the H.263+ bitstream payload is incomplete 560 (PLUSPTYPE present and UFEP="000"), and 562 2) The additional picture header which is attached is not incomplete 563 (UFEP="001"). 565 A packet which begins at the location of a Picture, GOB, slice, EOS, 566 or EOSBS start code shall omit the first two (all zero) bytes from 567 the H.263+ bitstream, and signify their presence by setting P=1 in 568 the payload header. 570 Here is an example of encapsulating the first packet in a frame 571 (without an attached redundant complete picture header): 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | first two 0 bytes of the PSC 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 6.1.2 Packets that begin with GBSC or SSC 583 For a packet that begins at the location of a GOB or slice start 584 code, PLEN may be zero or may be nonzero, depending on whether a 585 redundant picture header is attached to the packet. In environments 586 with very low packet loss rates, or when picture header contents are 587 very seldom likely to change (except as can be detected from the GFID 588 syntax of H.263+), a redundant copy of the picture header is not 589 required. However, in less ideal circumstances a redundant picture 590 header should be attached for enhanced error resilience, and its 591 presence is indicated by PLEN>0. 593 Assuming a PLEN of 9 and P=1, below is an example of a packet that 594 begins with a byte aligned GBSC or a SSC: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | starting with TR, PTYPE ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | ... | bitstream | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | data starting with GBSC/SSC without its first two 0 bytes 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Notice that only the last six bits of the picture start code, 609 '100000', are included in the payload header. A complete H.263+ 610 picture header with byte aligned picture start code can be 611 conveniently assembled if needed on the receiving end by prepending 612 the sixteen leading '0' bits. 614 6.1.3 Packets that Begin with an EOS or EOSBS Code 616 For a packet that begins with an EOS or EOSBS code, PLEN shall be 617 zero, and no Picture, GOB, or Slice start codes shall be included 618 within the same packet. As with other packets beginning with start 619 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 620 beginning of the packet shall be omitted, and their presence shall be 621 indicated by setting the P bit to 1 in the payload header. 623 System designers should be aware that some decoders may interpret the 624 loss of a packet containing only EOS or EOSBS information as the loss 625 of essential video data and may thus respond by not displaying some 626 subsequent video information. Since EOS and EOSBS codes do not 627 actually affect the decoding of video pictures, they are somewhat 628 unnecessary to send at all. Because of the danger of 629 misinterpretation of the loss of such a packet (which can be detected 630 by the sequence number), encoders are generally to be discouraged 631 from sending EOS and EOSBS. 633 Below is an example of a packet containing an EOS code: 635 0 1 2 636 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 6.2 Encapsulating Follow-On Packet (P=0) 643 A Follow-on packet contains a number of bytes of coded H.263+ data 644 which does not start at a synchronization point. That is, a 645 Follow-On packet does not start with a Picture, GOB, Slice, EOS, or 646 EOSBS header, and it may or may not start at a macroblock boundary. 647 Since Follow-on packets do not start at synchronization points, the 648 data at the beginning of a follow-on packet is not independently 649 decodable. For such packets, P=0 always. If the preceding packet of 650 a Follow-on packet got lost, the receiver may discard that Follow-on 651 packet as well as all other following Follow-on packets. Better 652 behavior, of course, would be for the receiver to scan the interior 653 of the packet payload content to determine whether any start codes 654 are found in the interior of the packet which can be used as resync 655 points. The use of an attached copy of a picture header for a 656 follow-on packet is useful only if the interior of the packet or some 657 subsequent follow-on packet contains a resync code such as a GOB or 658 slice start code. PLEN>0 is allowed, since it may allow resync in 659 the interior of the packet. The decoder may also be resynchronized 660 at the next segment or picture packet. 662 Here is an example of a follow-on packet (with PLEN=0): 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 667 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 670 7. Use of this payload specification 672 There is no syntactical difference between a picture segment packet 673 and a Follow-on packet, other than the indication P=1 for picture 674 segment or sequence ending packets and P=0 for Follow-on packets. 675 See the following for a summary of the entire packet types and ways 676 to distinguish between them. 678 It is possible to distinguish between the different packet types by 679 checking the P bit and the first 6 bits of the payload along with the 680 header information. The following table shows the packet type for 681 permutations of this information (see also the picture/GOB/Slice 682 header descriptions in H.263+ for details): 684 -------------+--------------+----------------------+---------------- 685 First 6 bits | P-Bit | PLEN | Packet | Remarks 686 of Payload |(payload hdr.)| | 687 -------------+--------------+----------------------+---------------- 688 100000 | 1 | 0 | Picture | Typical Picture 689 100000 | 1 | > 0 | Picture | Note UFEP 690 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 691 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 692 Xxxxxx | 0 | 0 | Follow-on | 693 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 694 -------------+--------------+----------------------+---------------- 696 The details regarding the possible values of the five bit Group 697 Number (GN) field which follows the initial "1" bit when the P-bit is 698 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 699 of H.263[H263P]. 701 As defined in this specification, every start of a coded frame (as 702 indicated by the presence of a PSC) has to be encapsulated as a 703 picture segment packet. If the whole coded picture fits into one 704 packet of reasonable size (which is dependent on the connection 705 characteristics), this is the only type of packet that may need to be 706 used. Due to the high compression ratio achieved by H.263+ it is 707 often possible to use this mechanism, especially for small spatial 708 picture formats such as QCIF and typical Internet packet sizes around 709 1500 bytes. 711 If the complete coded frame does not fit into a single packet, two 712 different ways for the packetization may be chosen. In case of very 713 low or zero packet loss probability, one or more Follow-on packets 714 may be used for coding the rest of the picture. Doing so leads to 715 minimal coding and packetization overhead as well as to an optimal 716 use of the maximal packet size, but does not provide any added error 717 resilience. 719 The alternative is to break the picture into reasonably small 720 partitions - called Segments - (by using the Slice or GOB mechanism), 721 that do offer synchronization points. By doing so and using the 722 Picture Segment payload with PLEN>0, decoding of the transmitted 723 packets is possible even in such cases in which the Picture packet 724 containing the picture header was lost (provided any necessary 725 reference picture is available). Picture Segment packets can also be 726 used in conjunction with Follow-on packets for large segment sizes. 728 8. IANA Considerations 730 This section updates the H.263(1998) and H.263 (2000) media types 731 described in RFC3555 [RFC3555]. 733 This section specifies optional parameters that MAY be used to select 734 optional features of the H.263 codec. The parameters are specified 735 here as part of the MIME subtype registration for the ITU-T H.263 736 codec. A mapping of the parameters into the Session Description 737 Protocol (SDP)[RFC2327] is also provided for those applications that 738 use SDP. Multiple parameters SHOULD be expressed as a MIME media 739 type string, in the form of a semicolon separated list of 740 parameter=value pairs 742 8.1 Media Type Registrations 744 This section describes the Media types and names associated with this 745 payload format. The section updates the previous registered version 746 in RFC 3555 [RFC3555]. The section registers the Media types, as per 747 RFC2048[RFC2048] 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, which 761 correspond to a maximum frame rate of 29.97/ the specified value 762 frames per second. 764 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 765 resolution. Permissible value are integer values from 1 to 32, which 766 correspond to a maximum frame rate of 29.97/ the specified value 767 frames per second. 769 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 770 resolution. Permissible value are integer values from 1 to 32, which 771 correspond to a maximum frame rate of 29.97/ the specified value 772 frames per second. 774 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 775 resolution. Permissible value are integer values from 1 to 32, which 776 correspond to a maximum frame rate of 29.97/ the specified value 777 frames per second. 779 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 780 resolution. Permissible value are integer values from 1 to 32, which 781 correspond to a maximum frame rate of 29.97/ the specified value 782 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 parameters 787 describe the number of pixels in the X and Y axis and must be evenly 788 dividable by 4. The permissible value for MPI, are integer values 789 from 1 to 32, which correspond to a maximum frame rate of 29.97/ the 790 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 the 794 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 specific 800 annex SHALL specify it support using the optional parameters. 802 The allowed optional parameters for the annexes are "F", "I", "J", 803 "T" which do not get any values and "K", "N" and "P". 805 "K" can receive one of four values 1-4: 807 1: - Slices In Order-Non Rectangular 809 2: - Slices In Order-Rectangular 811 3: - Slices Not Ordered - Non Rectangular 813 4: - Slices Not Ordered - Rectangular 815 "N" - Reference Picture Selection mode - Four numeric choices (1-4) 816 are available representing the following modes: 818 1: NEITHER: In which no back-channel data is returned from the 819 decoder to the encoder. 821 2: ACK: In which the decoder returns only acknowledgment messages. 823 3: NACK: In which the decoder returns only non-acknowledgment 824 messages 826 4: ACK+NACK: In which the decoder returns both acknowledgment and 827 non-acknowledgment messages. 829 No special provision is made herein for carrying back channel 830 information. The Extended RTP Profile for RTCP-based Feedback [AVPF] 831 MAY be used as a back channel mechanism. 833 "P" - Reference Picture Resampling with the following submodes 834 represented as a number fro 1 to 4: 836 1: dynamicPictureResizingByFour 838 2: dynamicPictureResizingBySixteenthPel 840 3: dynamicWarpingHalfPel 842 4: dynamicWarpingSixteenthPel 844 Example: P=1,3 846 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height ratio 847 by two colon separated integers between 0 and 255. Default ratio is 848 12:11 if not otherwise specified. 850 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a floating 851 point value. Default value is 29.97 Hz. 853 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 854 bits allowed to represent a single picture. If this parameter is not 855 present, then the default value, based on the maximum supported 856 resolution, is used. BPP is integer value between 0 and 65536. 858 HRD - Hypothetical Reference Decoder: See annex B of H.263 859 specification[H263P]. 861 Encoding considerations: 863 This type is only defined for transfer via RTP [RFC3550] 865 Security considerations: See Section 10 867 Interoperability considerations: These are receiver options, current 868 implementations will not send any optional parameters in their SDP. 869 They will ignore the optional parameters and will encode the H.263 870 stream without any of the annexes. Most decoders support at least 871 QCIF and CIF fixed resolutions and they are expected to be available 872 almost in every H.263 based video application. 874 Published specification: RFC yyy ( This RFC) 876 Applications which use this media type: 878 Audio and video streaming and conferencing tools. 880 Additional information: none 882 Person and email address to contact for further information : 884 Roni Even: roni.even@polycom.co.il 886 Intended usage: COMMON 888 Author: 890 Roni Even 892 Change controller: 894 IETF Audio/Video Transport working group delegated from the IESG. 896 8.1.2 Registration of MIME media type video/H263-2000 898 MIME media type name: video 900 MIME subtype name: H263-2000 902 Required parameters: None 904 Optional parameters: 906 The optional parameters of the H263-1998 type MAY be used with this 907 MIME subtype. Specific optional parameters that may be used with the 908 H263-2000 type are: 910 PROFILE: H.263 profile number, in the range 0 through 10, specifying 911 the supported H.263 annexes/subparts based on H.263 annex X. 913 LEVEL: Level of bitstream operation, in the range 0 through 100, 914 specifying the level of computational complexity of the decoding 915 process. 917 A system that specifies support of a PROFILE MUST specify the 918 supported LEVEL. 920 INTERLACE: Interlaced or 60 fields indicates the support for 921 interlace display mode. 923 Encoding considerations: 925 This type is only defined for transfer via RTP [RFC3550] 927 Security considerations: See Section 10 929 Interoperability considerations: The optional parameters PROFILE and 930 LEVEL SHALL NOT be used with any of the other optional parameters. 932 Published specification: RFC yyy 934 Applications which use this media type: 936 Audio and video streaming and conferencing tools. 938 Additional information: none 940 Person and email address to contact for further information : 942 Roni Even: roni.even@polycom.co.il 944 Intended usage: COMMON 946 Author: 948 Roni Even 950 Change controller: 952 IETF Audio/Video Transport working group delegated from the IESG. 954 8.2 SDP Parameters 956 The media types video/H263-1998 and video/H263-2000 are mapped to 957 fields in the Session Description Protocol (SDP) as follows: 959 o The media name in the "m=" line of SDP MUST be video. 961 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 962 or H263-2000 (the MIME subtype). 964 o The clock rate in the "a=rtpmap" line MUST be 90000. 966 o The optional parameters if any, MUST be included in the "a=fmtp" 967 line of SDP. These parameters are expressed as a media type string, 968 in the form of a semicolon separated list of parameter=value pairs. 969 The optional parameters PROFILE and LEVEL SHALL NOT be used with any 970 of the other optional parameters. 972 8.2.1 Usage with the SDP Offer Answer Model 974 When offering H.263 over RTP using SDP in an Offer/Answer 975 model[RFC3264] the following considerations are necessary. 977 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 978 the sender of this SDP message is able to decode those options. 979 These options are receiver's capability even when send in a 980 "sendonly" offer. 982 Picture sizes and MPI: 984 Supported picture sizes and their corresponding minimum picture 985 interval (MPI) information for H.263 can be combined. All picture 986 sizes can be advertised to the other party, or only a subset of it. 987 Terminal announces only those picture sizes (with their MPIs) which 988 it is willing to receive. For example, MPI=2 means that maximum 989 (decodeable) picture rate per second is about 15. 991 If the receiver does not specify the picture size /MPI optional 992 parameter then it SHOULD be ready to receive QCIF resolution with 993 MPI=1. 995 Parameters offered first are the most preferred picture mode to be 996 received. 998 Example of the usage of these parameters: 1000 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 1002 This means that encoder SHOULD send CIF picture size, which it can 1003 decode at MPI=4. If that is not possible, then QCIF with MPI value 1004 3, if neither are possible, then SQCIF with MPI value=2. The 1005 receiver is able of (but least preferred) decoding custom picture 1006 sizes (max 360x240) with MPI=2. Note that most decoders support at 1007 least QCIF and CIF fixed resolutions and they are expected to be 1008 available almost in every H.263 based video application. 1010 Below is an example of H.263 SDP in an offer. 1012 a=fmtp:xx CIF=4;QCIF=2;F;K=1 1014 This means that the sender of this message can decode H.263 bit 1015 stream with following options and parameters: Preferred resolution is 1016 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 1017 AP and slicesInOrder-NonRect options MAY be used. 1019 9. Backward Compatibility to RFC2429 1021 The current draft updates RFC2429. This section will address the 1022 major backward compatibility issues. 1024 9.1 New SDP optional parameters 1026 The draft adds new optional parameters to the H263-1998 and H263-2000 1027 payload type. Since these are optional parameters we expect old 1028 implementation to ignore these parameters while new implementations 1029 that will receive the H263-1998 and H263-2000 payload type with no 1030 parameters will behave as if the other side can accept H.263 at QCIF 1031 resolution and 30 frames per second. 1033 10. Security Considerations 1035 RTP packets using the payload format defined in this specification 1036 are subject to the security considerations discussed in the RTP 1037 specification [RFC3550], and any appropriate RTP profile (for example 1038 [RFC3551]). This implies that confidentiality of the media streams 1039 is achieved by encryption. Because the data compression used with 1040 this payload format is applied end-to-end, encryption may be 1041 performed after compression so there is no conflict between the two 1042 operations. 1044 A potential denial-of-service threat exists for data encoding using 1045 compression techniques that have non-uniform receiver-end 1046 computational load. The attacker can inject pathological datagrams 1047 into the stream which are complex to decode and cause the receiver to 1048 be overloaded. The usage of authentication of at least the RTP 1049 packet is RECOMMENDED 1051 As with any IP-based protocol, in some circumstances a receiver may 1052 be overloaded simply by the receipt of too many packets, either 1053 desired or undesired. Network-layer authentication may be used to 1054 discard packets from undesired sources, but the processing cost of 1055 the authentication itself may be too high. In a multicast 1056 environment, pruning of specific sources may be implemented in future 1057 versions of IGMP [RFC2032] and in multicast routing protocols to 1058 allow a receiver to select which sources are allowed to reach it. 1060 A security review of this payload format found no additional 1061 considerations beyond those in the RTP specification. 1063 11. Acknowledgements 1065 This is to acknowledge the work done by Carsten Bormann from 1066 Universitaet Bremen and Chad Zhu, Linda Cline, Gim Deisher, Tom 1067 Gardos, Christian Maciocco, Donald Newell from Intel Corp. who co- 1068 authored RFC2429. 1070 I would also like to acknowledge the work of Petri Koskelainen from 1071 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1072 for the new media types. 1074 12. Changes from previous versions of the document 1076 12.1 changes from RFC 2429 1078 The changes from the RFC 2429 are: 1080 1. The H.263 1998 and 2000 MIME type are now in the payload 1081 specification. 1083 2. Added optional parameters to the H.263 MIME types 1085 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload 1086 format should be used only to interact with legacy systems. 1088 4. Editorial changes to be in line with RFC editing procedures 1090 12.2 Changes from rfc2429-bis-00 1092 1. Changed from space separated parameters to semi colon according 1093 to the AVT guidelines 1095 2. Took out the MaxBR optional parameter. 1097 12.3 Changes from rfc2429-bis-03 1099 1. Change the section order between section 3 and 4. 1101 2. check for correct usage of keywords. 1103 12.4 Changes from rfc2429-bis-03 1105 1. Change the section order between section 4 and 3 to reduce the 1106 difference from RFC2429 1108 2. Editorial changes to reduce diff from RFC2429 1110 13. References 1112 13.1 Normative References 1114 [H263] International Telecommunications Union, "Video coding for 1115 low bit rate communication", ITU Recommendation H.263, 1116 March 1996. 1118 [H263P] International Telecommunications Union, "Video coding for 1119 low bit rate communication", ITU Recommendation H.263P, 1120 February 1998. 1122 [H263X] International Telecommunications Union, "Annex X: Profiles 1123 and levels definition", ITU Recommendation H.263AnxX, 1124 April 2001. 1126 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1127 Streams", RFC 2032, October 1996. 1129 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 1130 Internet Mail Extensions (MIME) Part Four: Registration 1131 Procedures", BCP 13, RFC 2048, November 1996. 1133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1134 Requirement Levels", BCP 14, RFC 2119, March 1997. 1136 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", 1137 RFC 2190, September 1997. 1139 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1140 Protocol", RFC 2327, April 1998. 1142 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1143 with Session Description Protocol (SDP)", RFC 3264, 1144 June 2002. 1146 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1147 Jacobson, "RTP: A Transport Protocol for Real-Time 1148 Applications", STD 64, RFC 3550, July 2003. 1150 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1151 Video Conferences with Minimal Control", STD 65, RFC 3551, 1152 July 2003. 1154 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1155 Payload Formats", RFC 3555, July 2003. 1157 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1159 Audio-Visual Services over Packet Networks, Aberdeen, 1160 U.K. 9/1997, September 1997. 1162 13.2 Informative References 1164 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1165 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1166 January 2004. 1168 Authors' Addresses 1170 Joerg Ott 1171 Univ. Bremen 1173 Email: jo@acm.org 1175 Gary Sullivan 1176 Microsoft 1178 Email: garysull@windows.microsoft.com 1180 Stephan Wenger 1181 TU Berlin 1183 Email: stewe@cs.tu-berlin.de 1185 Roni Even 1186 Polycom 1187 94 Derech Em Hamoshavot 1188 Petach Tikva 49130 1189 Israel 1191 Email: roni.even@polycom.co.il 1193 Intellectual Property Statement 1195 The IETF takes no position regarding the validity or scope of any 1196 Intellectual Property Rights or other rights that might be claimed to 1197 pertain to the implementation or use of the technology described in 1198 this document or the extent to which any license under such rights 1199 might or might not be available; nor does it represent that it has 1200 made any independent effort to identify any such rights. Information 1201 on the procedures with respect to rights in RFC documents can be 1202 found in BCP 78 and BCP 79. 1204 Copies of IPR disclosures made to the IETF Secretariat and any 1205 assurances of licenses to be made available, or the result of an 1206 attempt made to obtain a general license or permission for the use of 1207 such proprietary rights by implementers or users of this 1208 specification can be obtained from the IETF on-line IPR repository at 1209 http://www.ietf.org/ipr. 1211 The IETF invites any interested party to bring to its attention any 1212 copyrights, patents or patent applications, or other proprietary 1213 rights that may cover technology that may be required to implement 1214 this standard. Please address the information to the IETF at 1215 ietf-ipr@ietf.org. 1217 Disclaimer of Validity 1219 This document and the information contained herein are provided on an 1220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1222 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1223 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1224 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1227 Copyright Statement 1229 Copyright (C) The Internet Society (2005). This document is subject 1230 to the rights, licenses and restrictions contained in BCP 78, and 1231 except as set forth therein, the authors retain all their rights. 1233 Acknowledgment 1235 Funding for the RFC Editor function is currently provided by the 1236 Internet Society.