idnits 2.17.1 draft-ietf-avt-rfc2429-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 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 == Line 115 has weird spacing: '...the new optio...' == Line 724 has weird spacing: '...ameters into ...' -- 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 (March 29, 2004) is 7334 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 1072, 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: 6 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: September 27, 2004 G. Sullivan 5 Microsoft 6 S. Wenger 7 TU Berlin 8 R. Even 9 Polycom 10 March 29, 2004 12 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 13 (H.263+) 14 draft-ietf-avt-rfc2429-bis-01.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 27, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes a scheme to packetize an H.263 video stream 45 for transport using the Real-time Transport Protocol, RTP, with any 46 of the underlying protocols that carry RTP. 48 The document also describe the syntax and semantics of the SDP 49 parameters needed to support the H.263 video codec. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . 4 56 3. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2 Video Packet Structure . . . . . . . . . . . . . . . . . . . 7 59 4. Design Considerations . . . . . . . . . . . . . . . . . . . 9 60 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . 11 61 5.1 General H.263+ payload header . . . . . . . . . . . . . . . 11 62 5.2 Video Redundancy Coding Header Extension . . . . . . . . . . 12 63 6. Packetization schemes . . . . . . . . . . . . . . . . . . . 15 64 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) . 15 65 6.1.1 Packets that begin with a Picture Start Code . . . . . . . . 15 66 6.1.2 Packets that begin with GBSC or SSC . . . . . . . . . . . . 16 67 6.1.3 Packets that Begin with an EOS or EOSBS Code . . . . . . . . 17 68 6.2 Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . . 17 69 7. Use of this payload specification . . . . . . . . . . . . . 19 70 8. Payload Format Parameters . . . . . . . . . . . . . . . . . 21 71 8.1 IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 72 8.1.1 Registration of MIME media type video/H263-1998 . . . . . . 21 73 8.1.2 Registration of MIME media type video/H263-2000 . . . . . . 24 74 8.2 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 25 75 8.2.1 Usage with the SDP Offer Answer Model . . . . . . . . . . . 26 76 9. Security Considerations . . . . . . . . . . . . . . . . . . 27 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 78 11. Changes from previous versions of the document . . . . . . . 29 79 11.1 changes from RFC 2429 . . . . . . . . . . . . . . . . . . . 29 80 11.2 Changes from rfc2429-bis-00 . . . . . . . . . . . . . . . . 29 81 Normative References . . . . . . . . . . . . . . . . . . . . 30 82 Informative References . . . . . . . . . . . . . . . . . . . 31 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 84 Intellectual Property and Copyright Statements . . . . . . . 32 86 1. Introduction 88 This document specifies an RTP payload header format applicable to 89 the transmission of video streams generated based on the 1998 and 90 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 91 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, 92 this format can also be used with the 1996 version of H.263 [H263], 93 and MUST be use by new implementations. This format replaces the 94 payload format in RFC 2190[RFC2190], which continues to be used by 95 some existing implementations, and may be useful for backward 96 compatibility. New implementations supporting H.263 MUST use the 97 payload format described in this document. 99 This document updates RFC2429. 101 1.1 Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC2119[RFC2119] and 106 indicate requirement levels for compliant RTP implementations. 108 2. New H.263 features 110 The 1998 version of ITU-T Recommendation H.263 added numerous coding 111 options to improve codec performance over the 1996 version. The 1998 112 version is referred to as H.263+ in this document. The 2000 version 113 is referred to as H.263++ in this document. 115 Among the new options, the ones with the biggest impact on the RTP 116 payload specification and the error resilience of the video content 117 are the slice structured mode, the independent segment decoding mode, 118 the reference picture selection mode, and the scalability mode. This 119 section summarizes the impact of these new coding options on 120 packetization. Refer to [H263P] for more information on coding 121 options. 123 The slice structured mode was added to H.263+ for three purposes: to 124 provide enhanced error resilience capability, to make the bitstream 125 more amenable to use with an underlying packet transport such as RTP, 126 and to minimize video delay. The slice structured mode supports 127 fragmentation at macroblock boundaries. 129 With the independent segment decoding (ISD) option, a video picture 130 frame is broken into segments and encoded in such a way that each 131 segment is independently decodable. Utilizing ISD in a lossy network 132 environment helps to prevent the propagation of errors from one 133 segment of the picture to others. 135 The reference picture selection mode allows the use of an older 136 reference picture rather than the one immediately preceding the 137 current picture. Usually, the last transmitted frame is implicitly 138 used as the reference picture for inter-frame prediction. If the 139 reference picture selection mode is used, the data stream carries 140 information on what reference frame should be used, indicated by the 141 temporal reference as an ID for that reference frame. The reference 142 picture selection mode may be used with or without a back channel, 143 which provides information to the encoder about the internal status 144 of the decoder. However, no special provision is made herein for 145 carrying back channel information. The Extended RTP Profile for 146 RTCP-based Feedback [AVPF] MAY be used as a back channel mechanism. 148 H.263+ also includes bitstream scalability as an optional coding 149 mode. Three kinds of scalability are defined: temporal, signal-to- 150 noise ratio (SNR), and spatial scalability. Temporal scalability is 151 achieved via the disposable nature of bi-directionally predicted 152 frames, or B-frames. (A low-delay form of temporal scalability known 153 as P-picture temporal scalability can also be achieved by using the 154 reference picture selection mode described in the previous 155 paragraph.) SNR scalability permits refinement of encoded video 156 frames, thereby improving the quality (or SNR). Spatial scalability 157 is similar to SNR scalability except the refinement layer is twice 158 the size of the base layer in the horizontal dimension, vertical 159 dimension, or both. 161 3. Usage of RTP 163 When transmitting H.263+ video streams over the Internet, the output 164 of the encoder can be packetized directly. All the bits resulting 165 from the bitstream including the fixed length codes and variable 166 length codes will be included in the packet, with the only exception 167 being that when the payload of a packet begins with a Picture, GOB, 168 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 169 the start code are removed and replaced by setting an indicator bit 170 in the payload header. 172 For H.263+ bitstreams coded with temporal, spatial, or SNR 173 scalability, each layer may be transported to a different network 174 address. More specifically, each layer may use a unique IP address 175 and port number combination. The temporal relations between layers 176 shall be expressed using the RTP timestamp so that they can be 177 synchronized at the receiving ends in multicast or unicast 178 applications. 180 The H.263+ video stream will be carried as payload data within RTP 181 packets. A new H.263+ payload header is defined in section 4. This 182 section defines the usage of the RTP fixed header and H.263+ video 183 packet structure. 185 3.1 RTP Header Usage 187 Each RTP packet starts with a fixed RTP header. The following fields 188 of the RTP fixed header are used for H.263+ video streams: 190 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 191 the current packet carries the end of current frame, and is 0 192 otherwise. 194 Payload Type (PT): According to RFC 3551[RFC3551] table 5, a Dynamic 195 Payload Type SHALL be used to specify the H.263+ and H.263++ video 196 payload formats. 198 Timestamp: The RTP Timestamp encodes the sampling instance of the 199 first video frame data contained in the RTP data packet. The RTP 200 timestamp shall be the same on successive packets if a video frame 201 occupies more than one packet. In a multilayer scenario, all 202 pictures corresponding to the same temporal reference should use the 203 same timestamp. If temporal scalability is used (if B-frames are 204 present), the timestamp may not be monotonically increasing in the 205 RTP stream. If B-frames are transmitted on a separate layer and 206 address, they must be synchronized properly with the reference 207 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 208 information on required transmission order to a decoder. For an 209 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 210 the same as that of the RTP payload for H.261 stream [RFC2032]. 211 Since both the H.263+ data and the RTP header contain time 212 information, it is required that those timing information run 213 synchronously. That is, both the RTP timestamp and the temporal 214 reference (TR in the picture header of H.263) should carry the same 215 relative timing information. Any H.263+ picture clock frequency can 216 be expressed as 1800000/(cd*cf) source pictures per second, in which 217 cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using 218 the 90 kHz clock of the RTP timestamp, the time increment between 219 each coded H.263+ picture should therefore be a integer multiple of 220 (cd*cf)/20. This will always be an integer for any "reasonable" 221 picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 222 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for 223 the computer display update rates of 60, 72 and 75 Hz, respectively). 224 For RTP packetization of hypothetical H.263+ bitstreams using 225 "unreasonable" custom picture clock frequencies, mathematical 226 rounding could become necessary for generating the RTP timestamps. 228 3.2 Video Packet Structure 230 A section of an H.263+ compressed bitstream is carried as a payload 231 within each RTP packet. For each RTP packet, the RTP header is 232 followed by an H.263+ payload header, which is followed by a number 233 of bytes of a standard H.263+ compressed bitstream. The size of the 234 H.263+ payload header is variable depending on the payload involved 235 as detailed in the section 4. The layout of the RTP H.263+ video 236 packet is shown as: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | RTP Header 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | H.263+ Payload Header 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | H.263+ Compressed Data Stream 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Any H.263+ start codes can be byte aligned by an encoder by using the 249 stuffing mechanisms of H.263+. As specified in H.263+, picture, 250 slice, and EOSBS starts codes shall always be byte aligned, and GOB 251 and EOS start codes may be byte aligned. For packetization purposes, 252 GOB start codes should be byte aligned; however, since this is not 253 required in H.263+, there may be some cases where GOB start codes are 254 not aligned, such as when transmitting existing content, or when 255 using H.263 encoders that do not support GOB start code alignment. In 256 this case, follow-on packets (see section 5.2) should be used for 257 packetization. 259 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 260 with 16 zero-valued bits. If a start code is byte aligned and it 261 occurs at the beginning of a packet, these two bytes shall be removed 262 from the H.263+ compressed data stream in the packetization process 263 and shall instead be represented by setting a bit (the P bit) in the 264 payload header. 266 4. Design Considerations 268 The goals of this payload format are to specify an efficient way of 269 encapsulating an H.263+ standard compliant bitstream and to enhance 270 the resiliency towards packet losses. Due to the large number of 271 different possible coding schemes in H.263+, a copy of the picture 272 header with configuration information is inserted into the payload 273 header when appropriate. The use of that copy of the picture header 274 along with the payload data can allow decoding of a received packet 275 even in such cases in which another packet containing the original 276 picture header becomes lost. 278 There are a few assumptions and constraints associated with this 279 H.263+ payload header design. The purpose of this section is to 280 point out various design issues and also to discuss several coding 281 options provided by H.263+ that may impact the performance of 282 network-based H.263+ video. 284 o The optional slice structured mode described in Annex K of H.263+ 285 [H263P] enables more flexibility for packetization. Similar to a 286 picture segment that begins with a GOB header, the motion vector 287 predictors in a slice are restricted to reside within its boundaries. 288 However, slices provide much greater freedom in the selection of the 289 size and shape of the area which is represented as a distinct 290 decodable region. In particular, slices can have a size which is 291 dynamically selected to allow the data for each slice to fit into a 292 chosen packet size. Slices can also be chosen to have a rectangular 293 shape which is conducive for minimizing the impact of errors and 294 packet losses on motion compensated prediction. For these reasons, 295 the use of the slice structured mode is strongly recommended for any 296 applications used in environments where significant packet loss 297 occurs. 299 o In non-rectangular slice structured mode, only complete slices 300 should be included in a packet. In other words, slices should not be 301 fragmented across packet boundaries. The only reasonable need for a 302 slice to be fragmented across packet boundaries is when the encoder 303 which generated the H.263+ data stream could not be influenced by an 304 awareness of the packetization process (such as when sending H.263+ 305 data through a network other than the one to which the encoder is 306 attached, as in network gateway implementations). Optimally, each 307 packet will contain only one slice. 309 o The independent segment decoding (ISD) described in Annex R of 310 [H263P] prevents any data dependency across slice or GOB boundaries 311 in the reference picture. It can be utilized to further improve 312 resiliency in high loss conditions. 314 o If ISD is used in conjunction with the slice structure, the 315 rectangular slice submode shall be enabled and the dimensions and 316 quantity of the slices present in a frame shall remain the same 317 between each two intra-coded frames (I-frames), as required in 318 H.263+. The individual ISD segments may also be entirely intra coded 319 from time to time to realize quick error recovery without adding the 320 latency time associated with sending complete INTRA- pictures. 322 o When the slice structure is not applied, the insertion of a 323 (preferably byte-aligned) GOB header can be used to provide resync 324 boundaries in the bitstream, as the presence of a GOB header 325 eliminates the dependency of motion vector prediction across GOB 326 boundaries. These resync boundaries provide natural locations for 327 packet payload boundaries. 329 o H.263+ allows picture headers to be sent in an abbreviated form in 330 order to prevent repetition of overhead information that does not 331 change from picture to picture. For resiliency, sending a complete 332 picture header for every frame is often advisable. This means that 333 (especially in cases with high packet loss probability in which 334 picture header contents are not expected to be highly predictable), 335 the sender may find it advisable to always set the subfield UFEP in 336 PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263P] for 337 the definition of the UFEP and PLUSPTYPE fields). 339 o In a multi-layer scenario, each layer may be transmitted to a 340 different network address. The configuration of each layer such as 341 the enhancement layer number (ELNUM), reference layer number (RLNUM), 342 and scalability type should be determined at the start of the session 343 and should not change during the course of the session. 345 o All start codes can be byte aligned, and picture, slice, and EOSBS 346 start codes are always byte aligned. The boundaries of these 347 syntactical elements provide ideal locations for placing packet 348 boundaries. 350 o We assume that a maximum Picture Header size of 504 bits is 351 sufficient. The syntax of H.263+ does not explicitly prohibit larger 352 picture header sizes, but the use of such extremely large picture 353 headers is not expected. 355 5. H.263+ Payload Header 357 For H.263+ video streams, each RTP packet carries only one H.263+ 358 video packet. The H.263+ payload header is always present for each 359 H.263+ video packet. The payload header is of variable length. A 16 360 bit field of the basic payload header may be followed by an 8 bit 361 field for Video Redundancy Coding (VRC) information, and/or by a 362 variable length extra picture header as indicated by PLEN. These 363 optional fields appear in the order given above when present. 365 If an extra picture header is included in the payload header, the 366 length of the picture header in number of bytes is specified by PLEN. 367 The minimum length of the payload header is 16 bits, corresponding to 368 PLEN equal to 0 and no VRC information present. 370 The remainder of this section defines the various components of the 371 RTP payload header. Section five defines the various packet types 372 that are used to carry different types of H.263+ coded data, and 373 section six summarizes how to distinguish between the various packet 374 types. 376 5.1 General H.263+ payload header 378 The H.263+ payload header is structured as follows: 380 0 1 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | RR |P|V| PLEN |PEBIT| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 RR: 5 bits 388 Reserved bits. Shall be zero. MUST be ignored by receivers 390 P: 1 bit 392 Indicates the picture start or a picture segment (GOB/Slice) start or 393 a video sequence end (EOS or EOSBS). Two bytes of zero bits then 394 have to be prefixed to the payload of such a packet to compose a 395 complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the 396 omission of the two first bytes of the start codes, thus improving 397 the compression ratio. 399 V: 1 bit 401 Indicates the presence of an 8 bit field containing information for 402 Video Redundancy Coding (VRC), which follows immediately after the 403 initial 16 bits of the payload header if present. For syntax and 404 semantics of that 8 bit VRC field see section 4.2. 406 PLEN: 6 bits 408 Length in bytes of the extra picture header. If no extra picture 409 header is attached, PLEN is 0. If PLEN>0, the extra picture header 410 is attached immediately following the rest of the payload header. 411 Note the length reflects the omission of the first two bytes of the 412 picture start code (PSC). See section 5.1. 414 PEBIT: 3 bits 416 Indicates the number of bits that shall be ignored in the last byte 417 of the picture header. If PLEN is not zero, the ignored bits shall 418 be the least significant bits of the byte. If PLEN is zero, then 419 PEBIT shall also be zero. 421 5.2 Video Redundancy Coding Header Extension 423 Video Redundancy Coding (VRC) is an optional mechanism intended to 424 improve error resilience over packet networks. Implementing VRC in 425 H.263+ will require the Reference Picture Selection option described 426 in Annex N of [H263P]. By having multiple "threads" of independently 427 inter-frame predicted pictures, damage of individual frame will cause 428 distortions only within its own thread but leave the other threads 429 unaffected. From time to time, all threads converge to a so-called 430 sync frame (an INTRA picture or a non-INTRA picture which is 431 redundantly represented within multiple threads); from this sync 432 frame, the independent threads are started again. For more 433 information on codec support for VRC see [Vredun]. 435 P-picture temporal scalability is another use of the reference 436 picture selection mode and can be considered a special case of VRC in 437 which only one copy of each sync frame may be sent. It offers a 438 thread-based method of temporal scalability without the increased 439 delay caused by the use of B pictures. In this use, sync frames sent 440 in the first thread of pictures are also used for the prediction of a 441 second thread of pictures which fall temporally between the sync 442 frames to increase the resulting frame rate. In this use, the 443 pictures in the second thread can be discarded in order to obtain a 444 reduction of bit rate or decoding complexity without harming the 445 ability to decode later pictures. A third or more threads can also 446 be added as well, but each thread is predicted only from the sync 447 frames (which are sent at least in thread 0) or from frames within 448 the same thread. 450 While a VRC data stream is - like all H.263+ data - totally self- 451 contained, it may be useful for the transport hierarchy 452 implementation to have knowledge about the current damage status of 453 each thread. On the Internet, this status can easily be determined 454 by observing the marker bit, the sequence number of the RTP header, 455 and the thread-id and a circling "packet per thread" number. The 456 latter two numbers are coded in the VRC header extension. 458 The format of the VRC header extension is as follows: 460 0 1 2 3 4 5 6 7 461 +-+-+-+-+-+-+-+-+ 462 | TID | Trun |S| 463 +-+-+-+-+-+-+-+-+ 465 TID: 3 bits 467 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 468 data will use as reference information only sync frames or frames 469 within the same thread. By convention, thread 0 is expected to be 470 the "canonical" thread, which is the thread from which the sync frame 471 should ideally be used. In the case of corruption or loss of the 472 thread 0 representation, a representation of the sync frame with a 473 higher thread number can be used by the decoder. Lower thread 474 numbers are expected to contain equal or better representations of 475 the sync frames than higher thread numbers in the absence of data 476 corruption or loss. See [Vredun] for a detailed discussion of VRC. 478 Trun: 4 bits 480 Monotonically increasing (modulo 16) 4 bit number counting the packet 481 number within each thread. 483 S: 1 bit 485 A bit that indicates that the packet content is for a sync frame. An 486 encoder using VRC may send several representations of the same "sync" 487 picture, in order to ensure that regardless of which thread of 488 pictures is corrupted by errors or packet losses, the reception of at 489 least one representation of a particular picture is ensured (within 490 at least one thread). The sync picture can then be used for the 491 prediction of any thread. If packet losses have not occurred, then 492 the sync frame contents of thread 0 can be used and those of other 493 threads can be discarded (and similarly for other threads). Thread 0 494 is considered the "canonical" thread, the use of which is preferable 495 to all others. The contents of packets having lower thread numbers 496 shall be considered as having a higher processing and delivery 497 priority than those with higher thread numbers. Thus packets having 498 lower thread numbers for a given sync frame shall be delivered first 499 to the decoder under loss-free and low-time-jitter conditions, which 500 will result in the discarding of the sync contents of the 501 higher-numbered threads as specified in Annex N of [H263P]. 503 6. Packetization schemes 505 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) 507 A picture segment packet is defined as a packet that starts at the 508 location of a Picture, GOB, or slice start code in the H.263+ data 509 stream. This corresponds to the definition of the start of a video 510 picture segment as defined in H.263+. For such packets, P=1 always. 512 An extra picture header can sometimes be attached in the payload 513 header of such packets. Whenever an extra picture header is attached 514 as signified by PLEN>0, only the last six bits of its picture start 515 code, '100000', are included in the payload header. A complete 516 H.263+ picture header with byte aligned picture start code can be 517 conveniently assembled on the receiving end by prepending the sixteen 518 leading '0' bits. 520 When PLEN>0, the end bit position corresponding to the last byte of 521 the picture header data is indicated by PEBIT. The actual bitstream 522 data shall begin on an 8-bit byte boundary following the payload 523 header. 525 A sequence ending packet is defined as a packet that starts at the 526 location of an EOS or EOSBS code in the H.263+ data stream. This 527 delineates the end of a sequence of H.263+ video data (more H.263+ 528 video data may still follow later, however, as specified in ITU-T 529 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 531 The optional header extension for VRC may or may not be present as 532 indicated by the V bit flag. 534 6.1.1 Packets that begin with a Picture Start Code 536 Any packet that contains the whole or the start of a coded picture 537 shall start at the location of the picture start code (PSC), and 538 should normally be encapsulated with no extra copy of the picture 539 header. In other words, normally PLEN=0 in such a case. However, if 540 the coded picture contains an incomplete picture header (UFEP = 541 "000"), then a representation of the complete (UFEP = "001") picture 542 header may be attached during packetization in order to provide 543 greater error resilience. Thus, for packets that start at the 544 location of a picture start code, PLEN shall be zero unless both of 545 the following conditions apply: 547 1) The picture header in the H.263+ bitstream payload is incomplete 548 (PLUSPTYPE present and UFEP="000"), and 550 2) The additional picture header which is attached is not incomplete 551 (UFEP="001"). 553 A packet which begins at the location of a Picture, GOB, slice, EOS, 554 or EOSBS start code shall omit the first two (all zero) bytes from 555 the H.263+ bitstream, and signify their presence by setting P=1 in 556 the payload header. 558 Here is an example of encapsulating the first packet in a frame 559 (without an attached redundant complete picture header): 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | first two 0 bytes of the PSC 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 6.1.2 Packets that begin with GBSC or SSC 571 For a packet that begins at the location of a GOB or slice start 572 code, PLEN may be zero or may be nonzero, depending on whether a 573 redundant picture header is attached to the packet. In environments 574 with very low packet loss rates, or when picture header contents are 575 very seldom likely to change (except as can be detected from the GFID 576 syntax of H.263+), a redundant copy of the picture header is not 577 required. However, in less ideal circumstances a redundant picture 578 header should be attached for enhanced error resilience, and its 579 presence is indicated by PLEN>0. 581 Assuming a PLEN of 9 and P=1, below is an example of a packet that 582 begins with a byte aligned GBSC or a SSC: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | starting with TR, PTYPE ... | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | ... | bitstream | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | data starting with GBSC/SSC without its first two 0 bytes 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Notice that only the last six bits of the picture start code, 597 '100000', are included in the payload header. A complete H.263+ 598 picture header with byte aligned picture start code can be 599 conveniently assembled if needed on the receiving end by prepending 600 the sixteen leading '0' bits. 602 6.1.3 Packets that Begin with an EOS or EOSBS Code 604 For a packet that begins with an EOS or EOSBS code, PLEN shall be 605 zero, and no Picture, GOB, or Slice start codes shall be included 606 within the same packet. As with other packets beginning with start 607 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 608 beginning of the packet shall be omitted, and their presence shall be 609 indicated by setting the P bit to 1 in the payload header. 611 System designers should be aware that some decoders may interpret the 612 loss of a packet containing only EOS or EOSBS information as the loss 613 of essential video data and may thus respond by not displaying some 614 subsequent video information. Since EOS and EOSBS codes do not 615 actually affect the decoding of video pictures, they are somewhat 616 unnecessary to send at all. Because of the danger of 617 misinterpretation of the loss of such a packet (which can be detected 618 by the sequence number), encoders are generally to be discouraged 619 from sending EOS and EOSBS. 621 Below is an example of a packet containing an EOS code: 623 0 1 2 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 6.2 Encapsulating Follow-On Packet (P=0) 631 A Follow-on packet contains a number of bytes of coded H.263+ data 632 which does not start at a synchronization point. That is, a Follow- 633 On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS 634 header, and it may or may not start at a macroblock boundary. Since 635 Follow-on packets do not start at synchronization points, the data at 636 the beginning of a follow-on packet is not independently decodable. 637 For such packets, P=0 always. If the preceding packet of a Follow-on 638 packet got lost, the receiver may discard that Follow-on packet as 639 well as all other following Follow-on packets. Better behavior, of 640 course, would be for the receiver to scan the interior of the packet 641 payload content to determine whether any start codes are found in the 642 interior of the packet which can be used as resync points. The use 643 of an attached copy of a picture header for a follow-on packet is 644 useful only if the interior of the packet or some subsequent follow- 645 on packet contains a resync code such as a GOB or slice start code. 646 PLEN>0 is allowed, since it may allow resync in the interior of the 647 packet. The decoder may also be resynchronized at the next segment 648 or picture packet. 650 Here is an example of a follow-on packet (with PLEN=0): 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 655 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 658 7. Use of this payload specification 660 There is no syntactical difference between a picture segment packet 661 and a Follow-on packet, other than the indication P=1 for picture 662 segment or sequence ending packets and P=0 for Follow-on packets. 663 See the following for a summary of the entire packet types and ways 664 to distinguish between them. 666 It is possible to distinguish between the different packet types by 667 checking the P bit and the first 6 bits of the payload along with the 668 header information. The following table shows the packet type for 669 permutations of this information (see also the picture/GOB/Slice 670 header descriptions in H.263+ for details): 672 -------------+--------------+----------------------+---------------- 673 First 6 bits | P-Bit | PLEN | Packet | Remarks 674 of Payload |(payload hdr.)| | 675 -------------+--------------+----------------------+---------------- 676 100000 | 1 | 0 | Picture | Typical Picture 677 100000 | 1 | > 0 | Picture | Note UFEP 678 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 679 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 680 Xxxxxx | 0 | 0 | Follow-on | 681 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 682 -------------+--------------+----------------------+---------------- 684 The details regarding the possible values of the five bit Group 685 Number (GN) field which follows the initial "1" bit when the P-bit is 686 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 687 of [H263P]. 689 As defined in this specification, every start of a coded frame (as 690 indicated by the presence of a PSC) has to be encapsulated as a 691 picture segment packet. If the whole coded picture fits into one 692 packet of reasonable size (which is dependent on the connection 693 characteristics), this is the only type of packet that may need to be 694 used. Due to the high compression ratio achieved by H.263+ it is 695 often possible to use this mechanism, especially for small spatial 696 picture formats such as QCIF and typical Internet packet sizes around 697 1500 bytes. 699 If the complete coded frame does not fit into a single packet, two 700 different ways for the packetization may be chosen. In case of very 701 low or zero packet loss probability, one or more Follow-on packets 702 may be used for coding the rest of the picture. Doing so leads to 703 minimal coding and packetization overhead as well as to an optimal 704 use of the maximal packet size, but does not provide any added error 705 resilience. 707 The alternative is to break the picture into reasonably small 708 partitions - called Segments - (by using the Slice or GOB mechanism), 709 that do offer synchronization points. By doing so and using the 710 Picture Segment payload with PLEN>0, decoding of the transmitted 711 packets is possible even in such cases in which the Picture packet 712 containing the picture header was lost (provided any necessary 713 reference picture is available). Picture Segment packets can also be 714 used in conjunction with Follow-on packets for large segment sizes. 716 8. Payload Format Parameters 718 This section updates the H.263(1998) and H.263 (2000) media types 719 described in RFC3555 [RFC3555]. 721 This section specifies optional parameters that MAY be used to select 722 optional features of the H.263 codec. The parameters are specified 723 here as part of the MIME subtype registration for the ITU-T H.263 724 codec. A mapping of the parameters into the Session Description 725 Protocol (SDP) [RFC2327] is also provided for those applications 726 that use SDP. Multiple parameters SHOULD be expressed as a MIME 727 media type string, in the form of a semicolon separated list of 728 parameter=value pairs 730 8.1 IANA Considerations 732 This section describes the MIME types and names associated with this 733 payload format. The section updates the previous registered version 734 in RFC 3555 [RFC3555]. The section registers the MIME types, as per 735 RFC2048[RFC2048] 737 8.1.1 Registration of MIME media type video/H263-1998 739 MIME media type name: video 741 MIME subtype name: H263-1998 743 Required parameters: None 745 Optional parameters: 747 SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF 748 resolution. Permissible value are integer values from 1 to 32, which 749 correspond to a maximum frame rate of 29.97/ the specified value 750 frames per second. 752 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 753 resolution. Permissible value are integer values from 1 to 32, which 754 correspond to a maximum frame rate of 29.97/ the specified value 755 frames per second. 757 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 758 resolution. Permissible value are integer values from 1 to 32, which 759 correspond to a maximum frame rate of 29.97/ the specified value 760 frames per second. 762 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 763 resolution.Permissible value are integer values from 1 to 32, which 764 correspond to a maximum frame rate of 29.97/ the specified value 765 frames per second. 767 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 768 resolution. Permissible value are integer values from 1 to 32, which 769 correspond to a maximum frame rate of 29.97/ the specified value 770 frames per second. 772 CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom 773 defined resolution. The custom parameter receives three comma 774 separated values Xmax , Ymax and MPI. The Xmax and Ymax parameters 775 describe the number of pixels in the X and Y axis and must be evenly 776 divisable by 4. The permissible value for MPI, are integer values 777 from 1 to 32, which correspond to a maximum frame rate of 29.97/ the 778 specified value. 780 A system that declares support of a specific MPI for one of the 781 resolutions SHALL also implicitly support a lower resolution with the 782 same MPI. 784 A list of optional annexes specifies which annexes of H.263 are 785 supported. The optional annexes are defined as part of H263-1998, 786 H263-2000. Annex X of H.263-2000 defines profiles which group annexes 787 for specific applications. A system that support a specific annex 788 SHALL specify it support using the the optional parameters. 790 The allowed optional parameters for the annexes are "F", "I", "J", 791 "T" which do not get any values and "K", "N" and "P". 793 "K" can receive one of four values 1-4: 795 1: - Slices In Order-Non Rectangular 797 2: - Slices In Order-Rectangular 799 3: - Slices Not Ordered - Non Rectangular 801 4: - Slices Not Ordered - Rectangular 803 "N" - Reference Picture Selection mode - Four numeric choices (1-4) 804 are available representing the following modes: 806 1: NEITHER: In which no back-channel data is returned from the 807 decoder to the encoder. 809 2: ACK: In which the decoder returns only acknowledgment messages. 811 3: NACK: In which the decoder returns only non-acknowledgment 812 messages 814 4: ACK+NACK: In which the decoder returns both acknowledgment and 815 non-acknowledgment messages. 817 No special provision is made herein for carrying back channel 818 information. The Extended RTP Profile for RTCP-based Feedback [AVPF] 819 MAY be used as a back channel mechanism. 821 "P" - Reference Picture Resampling with the following submodes 822 represented as a number fro 1 to 4: 824 1: dynamicPictureResizingByFour 826 2: dynamicPictureResizingBySixteenthPel 828 3: dynamicWarpingHalfPel 830 4: dynamicWarpingSixteenthPel 832 Example: P=1,3 834 Editor's note: Other H.263 annexes are not part of the list and the 835 author is looking for input on the need to specify them explicitly. 836 This includes annexes "D", "E", "G", "L", "M", "O", "Q," "R", 837 "S". 839 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height ratio 840 by two colon separated integers between 0 and 255. Default ratio is 841 12:11 if not otherwise specified. 843 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a floating 844 point value. Default value is 29.97 Hz. 846 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 847 bits allowed to represent a single picture. If this parameter is not 848 present, then the default value, based on the maximum supported 849 resolution, is used. BPP is integer value between 0 and 65536. 851 HRD - Hypothetical Reference Decoder: See annex B of H.263 852 specification[H263P]. 854 Encoding considerations: 856 This type is only defined for transfer via RTP [RFC3550] 858 Security considerations: See Section 9 859 Interoperability considerations: These are receiver options, current 860 implementations will not send any optional parameters in their SDP. 861 They will ignore the optional parameters and will encode the H.263 862 stream without any of the annexes. Most decoders support at least 863 QCIF and CIF fixed resolutions and they are expected to be available 864 almost in every H.263 based video application. 866 Published specification: RFC yyy ( This RFC) 868 Applications which use this media type: 870 Audio and video streaming and conferencing tools. 872 Additional information: none 874 Person and email address to contact for further information : 876 Roni Even: roni.even@polycom.co.il 878 Intended usage: COMMON 880 Author/Change controller: 882 Roni Even 884 8.1.2 Registration of MIME media type video/H263-2000 886 MIME media type name: video 888 MIME subtype name: H263-2000 890 Required parameters: None 892 Optional parameters: 894 The optional parameters of the H263-1998 type MAY be used with this 895 MIME subtype. Specific optional parameters that may be used with the 896 H263-2000 type are: 898 PROFILE: H.263 profile number, in the range 0 through 10, specifying 899 the supported H.263 annexes/subparts. 901 LEVEL: Level of bitstream operation, in the range 0 through 100, 902 specifying the level of computational complexity of the decoding 903 process. 905 A system that specifies support of a PROFILE MUST specify the 906 supported LEVEL. 908 INTERLACE: Interlaced or 60 fields indicates the support for 909 interlace display mode. 911 Encoding considerations: 913 This type is only defined for transfer via RTP [RFC3550] 915 Security considerations: See Section 9 917 Interoperability considerations: The optional parameters PROFILE and 918 LEVEL SHALL NOT be used with any of the other optional parameters. 920 Published specification: RFC yyy 922 Applications which use this media type: 924 Audio and video streaming and conferencing tools. 926 Additional information: none 928 Person and email address to contact for further information : 930 Roni Even: roni.even@polycom.co.il 932 Intended usage: COMMON 934 >Author/Change controller: 936 Roni Even 938 8.2 SDP Parameters 940 The MIME media types video/H263-1998 and video/H263-2000 are mapped 941 to fields in the Session Description Protocol (SDP) as follows: 943 o The media name in the "m=" line of SDP MUST be video. 945 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 946 or H263-2000 (the MIME subtype). 948 o The clock rate in the "a=rtpmap" line MUST be 90000. 950 o The optional parameters if any, MUST be included in the "a=fmtp" 951 line of SDP. These parameters are expressed as a MIME media type 952 string, in the form of a semicolon separated list of parameter=value 953 pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used 954 with any of the other optional parameters. 956 8.2.1 Usage with the SDP Offer Answer Model 958 When offering H.263 over RTP using SDP in an Offer/Answer 959 model[RFC3264] the following considerations are necessary. 961 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 962 the sender of this SDP message is able to decode those options. These 963 options are receiver's capability even when send in a "sendonly" 964 offer. 966 Picture sizes and MPI: 968 Supported picture sizes and their corresponding minimum picture 969 interval (MPI) information for H.263 can be combined. All picture 970 sizes can be advertised to the other party, or only a subset of it. 971 Terminal announces only those picture sizes (with their MPIs) which 972 it is willing to receive. For example, MPI=2 means that maximum 973 (decodeable) picture rate per second is about 15. 975 Parameters offered first are the most preferred picture mode to be 976 received. 978 Example of the usage of these parameters: 980 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 982 This means that encoder SHOULD send CIF picture size, which it can 983 decode at MPI=4. If that is not possible, then QCIF with MPI value 984 3, if neither are possible, then SQCIF with MPI value=2. The receiver 985 is able of (but least preferred) decoding custom picture sizes (max 986 360x240) with MPI=2. Note that most decoders support at least QCIF 987 and CIF fixed resolutions and they are expected to be available 988 almost in every H.263 based video application. 990 Below is an example of H.263 SDP in an offer. 992 a=fmtp:xx CIF=4;QCIF=2;F;K=1 994 This means that the sender of this message can decode H.263 bit 995 stream with following options and parameters: Preferred resolution is 996 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 997 AP and slicesInOrder-NonRect options MAY be used. 999 9. Security Considerations 1001 RTP packets using the payload format defined in this specification 1002 are subject to the security considerations discussed in the RTP 1003 specification [RFC3550], and any appropriate RTP profile (for example 1004 [RFC3551]). This implies that confidentiality of the media streams is 1005 achieved by encryption. Because the data compression used with this 1006 payload format is applied end-to-end, encryption may be performed 1007 after compression so there is no conflict between the two operations. 1009 A potential denial-of-service threat exists for data encoding using 1010 compression techniques that have non-uniform receiver-end 1011 computational load. The attacker can inject pathological datagrams 1012 into the stream which are complex to decode and cause the receiver to 1013 be overloaded. The usage of authentication of at least the RTP 1014 packet is RECOMMENDED 1016 As with any IP-based protocol, in some circumstances a receiver may 1017 be overloaded simply by the receipt of too many packets, either 1018 desired or undesired. Network-layer authentication may be used to 1019 discard packets from undesired sources, but the processing cost of 1020 the authentication itself may be too high. In a multicast 1021 environment, pruning of specific sources may be implemented in future 1022 versions of IGMP [RFC2032] and in multicast routing protocols to 1023 allow a receiver to select which sources are allowed to reach it. 1025 A security review of this payload format found no additional 1026 considerations beyond those in the RTP specification. 1028 10. Acknowledgements 1030 This is to acknowledge the work done by Carsten Bormann from 1031 Universitaet Bremen and Chad Zhu, Linda Cline, Gim Deisher, Tom 1032 Gardos, Christian Maciocco, Donald Newell from Intel Corp. who 1033 co-authored RFC2429. 1035 I would also like to acknowledge the work of Petri Koskelainen from 1036 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1037 for the new MIME types. 1039 11. Changes from previous versions of the document 1041 11.1 changes from RFC 2429 1043 The changes from the RFC 2429 are: 1045 1. The H.263 1998 and 2000 MIME type are now in the payload 1046 specification. 1048 2. Added optional parameters to the H.263 MIME types 1050 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload format 1051 should be used only to interact with legacy systems. 1053 4. Editorial changes to be in line with RFC editing procedures 1055 11.2 Changes from rfc2429-bis-00 1057 1. Changed from space separted parameters to semi colon acording to 1058 the AVT guidelines 1060 2. Took out the MaxBR optional parameter. 1062 Normative References 1064 [H263] International Telecommunications Union, "Video coding for 1065 low bit rate communication", ITU Recommendation H.263, 1066 March 1996. 1068 [H263P] International Telecommunications Union, "Video coding for 1069 low bit rate communication", ITU Recommendation H.263P, 1070 February 1998. 1072 [H263X] International Telecommunications Union, "Annex X: Profiles 1073 and levels definition", ITU Recommendation H.263AnxX, 1074 April 2001. 1076 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1077 Streams", RFC 2032, October 1996. 1079 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1080 Internet Mail Extensions (MIME) Part Four: Registration 1081 Procedures", BCP 13, RFC 2048, November 1996. 1083 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1084 Requirement Levels", BCP 14, RFC 2119, March 1997. 1086 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 1087 2190, September 1997. 1089 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1090 Protocol", RFC 2327, April 1998. 1092 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1093 with Session Description Protocol (SDP)", RFC 3264, June 1094 2002. 1096 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1097 Jacobson, "RTP: A Transport Protocol for Real-Time 1098 Applications", RFC 3550, July 2003. 1100 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1101 Video Conferences with Minimal Control", RFC 3551, July 1102 2003. 1104 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1105 Payload Formats", RFC 3555, July 2003. 1107 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1108 Audio-Visual Services over Packet Networks, Aberdeen, U.K. 1109 9/1997, September 1997. 1111 Informative References 1113 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1114 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1115 January 2004. 1117 Authors' Addresses 1119 Joerg Ott 1120 Univ. Bremen 1122 EMail: jo@acm.org 1124 Gary Sullivan 1125 Microsoft 1127 EMail: garysull@windows.microsoft.com 1129 Stephan Wenger 1130 TU Berlin 1132 EMail: stewe@cs.tu-berlin.de 1134 Roni Even 1135 Polycom 1136 94 Derech Em Hamoshavot 1137 Petach Tikva 49130 1138 Israel 1140 EMail: roni.even@polycom.co.il 1142 Intellectual Property Statement 1144 The IETF takes no position regarding the validity or scope of any 1145 intellectual property or other rights that might be claimed to 1146 pertain to the implementation or use of the technology described in 1147 this document or the extent to which any license under such rights 1148 might or might not be available; neither does it represent that it 1149 has made any effort to identify any such rights. Information on the 1150 IETF's procedures with respect to rights in standards-track and 1151 standards-related documentation can be found in BCP-11. Copies of 1152 claims of rights made available for publication and any assurances of 1153 licenses to be made available, or the result of an attempt made to 1154 obtain a general license or permission for the use of such 1155 proprietary rights by implementors or users of this specification can 1156 be obtained from the IETF Secretariat. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights which may cover technology that may be required to practice 1161 this standard. Please address the information to the IETF Executive 1162 Director. 1164 Full Copyright Statement 1166 Copyright (C) The Internet Society (2004). All Rights Reserved. 1168 This document and translations of it may be copied and furnished to 1169 others, and derivative works that comment on or otherwise explain it 1170 or assist in its implementation may be prepared, copied, published 1171 and distributed, in whole or in part, without restriction of any 1172 kind, provided that the above copyright notice and this paragraph are 1173 included on all such copies and derivative works. However, this 1174 document itself may not be modified in any way, such as by removing 1175 the copyright notice or references to the Internet Society or other 1176 Internet organizations, except as needed for the purpose of 1177 developing Internet standards in which case the procedures for 1178 copyrights defined in the Internet Standards process must be 1179 followed, or as required to translate it into languages other than 1180 English. 1182 The limited permissions granted above are perpetual and will not be 1183 revoked by the Internet Society or its successors or assignees. 1185 This document and the information contained herein is provided on an 1186 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1187 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1188 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1189 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1190 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1192 Acknowledgment 1194 Funding for the RFC Editor function is currently provided by the 1195 Internet Society.