idnits 2.17.1 draft-ietf-avt-rfc2429-bis-04.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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1198. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 -- 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 (December 30, 2004) is 7047 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 1105, 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT J. Ott 2 Internet-Draft Univ. Bremen 3 Expires: June 30, 2005 G. Sullivan 4 Microsoft 5 S. Wenger 6 TU Berlin 7 R. Even 8 Polycom 9 December 30, 2004 11 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 12 (H.263+) 13 draft-ietf-avt-rfc2429-bis-04.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 30, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document describes a scheme to packetize an H.263 video stream 49 for transport using the Real-time Transport Protocol, RTP, with any 50 of the underlying protocols that carry RTP. 52 The document also describe the syntax and semantics of the SDP 53 parameters needed to support the H.263 video codec. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 61 4. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1 RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 8 63 4.2 Video Packet Structure . . . . . . . . . . . . . . . . . . 9 64 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . . 11 65 5.1 General H.263+ payload header . . . . . . . . . . . . . . 11 66 5.2 Video Redundancy Coding Header Extension . . . . . . . . . 12 67 6. Packetization schemes . . . . . . . . . . . . . . . . . . . . 15 68 6.1 Picture Segment Packets and Sequence Ending Packets 69 (P=1) . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1.1 Packets that begin with a Picture Start Code . . . . . 15 71 6.1.2 Packets that begin with GBSC or SSC . . . . . . . . . 16 72 6.1.3 Packets that Begin with an EOS or EOSBS Code . . . . . 17 73 6.2 Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . 17 74 7. Use of this payload specification . . . . . . . . . . . . . . 19 75 8. Payload Format Parameters . . . . . . . . . . . . . . . . . . 21 76 8.1 IANA Considerations . . . . . . . . . . . . . . . . . . . 21 77 8.1.1 Registration of MIME media type video/H263-1998 . . . 21 78 8.1.2 Registration of MIME media type video/H263-2000 . . . 24 79 8.2 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 25 80 8.2.1 Usage with the SDP Offer Answer Model . . . . . . . . 25 81 9. Backward Compatibility to RFC2429 . . . . . . . . . . . . . . 27 82 9.1 New SDP optional parameters . . . . . . . . . . . . . . . 27 83 10. Security Considerations . . . . . . . . . . . . . . . . . . 28 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 85 12. Changes from previous versions of the document . . . . . . . 30 86 12.1 changes from RFC 2429 . . . . . . . . . . . . . . . . . . 30 87 12.2 Changes from rfc2429-bis-00 . . . . . . . . . . . . . . . 30 88 12.3 Changes from rfc2429-bis-03 . . . . . . . . . . . . . . . 30 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 91 13.2 Informative References . . . . . . . . . . . . . . . . . . . 32 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 93 Intellectual Property and Copyright Statements . . . . . . . . 33 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 MAY also be used with the 1996 version of H.263 [H263], 102 and MUST be used by new implementations. This format SHALL replace 103 the payload format in RFC 2190[RFC2190], which continues to be used 104 by some existing implementations, and may be useful for backward 105 compatibility. New implementations supporting H.263 MUST use the 106 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, 159 signal-to-noise ratio (SNR), and spatial scalability. Temporal 160 scalability is achieved via the disposable nature of bi-directionally 161 predicted frames, or B-frames. (A low-delay form of temporal 162 scalability known as P-picture temporal scalability can also be 163 achieved by using the reference picture selection mode described in 164 the previous paragraph.) SNR scalability permits refinement of 165 encoded video frames, thereby improving the quality (or SNR). 166 Spatial scalability is similar to SNR scalability except the 167 refinement layer is twice the size of the base layer in the 168 horizontal dimension, vertical dimension, or both. 170 3. Design Considerations 172 The goals of this payload format are to specify an efficient way of 173 encapsulating an H.263+ standard compliant bitstream and to enhance 174 the resiliency towards packet losses. Due to the large number of 175 different possible coding schemes in H.263+, a copy of the picture 176 header with configuration information is inserted into the payload 177 header when appropriate. The use of that copy of the picture header 178 along with the payload data can allow decoding of a received packet 179 even in such cases in which another packet containing the original 180 picture header becomes lost. 182 There are a few assumptions and constraints associated with this 183 H.263+ payload header design. The purpose of this section is to 184 point out various design issues and also to discuss several coding 185 options provided by H.263+ that may impact the performance of 186 network-based H.263+ video. 188 o The optional slice structured mode described in Annex K of H.263+ 189 [H263P] enables more flexibility for packetization. Similar to a 190 picture segment that begins with a GOB header, the motion vector 191 predictors in a slice are restricted to reside within its boundaries. 192 However, slices provide much greater freedom in the selection of the 193 size and shape of the area which is represented as a distinct 194 decodable region. In particular, slices can have a size which is 195 dynamically selected to allow the data for each slice to fit into a 196 chosen packet size. Slices can also be chosen to have a rectangular 197 shape which is conducive for minimizing the impact of errors and 198 packet losses on motion compensated prediction. For these reasons, 199 the use of the slice structured mode is strongly recommended for any 200 applications used in environments where significant packet loss 201 occurs. 203 o In non-rectangular slice structured mode, only complete slices 204 should be included in a packet. In other words, slices should not be 205 fragmented across packet boundaries. The only reasonable need for a 206 slice to be fragmented across packet boundaries is when the encoder 207 which generated the H.263+ data stream could not be influenced by an 208 awareness of the packetization process (such as when sending H.263+ 209 data through a network other than the one to which the encoder is 210 attached, as in network gateway implementations). Optimally, each 211 packet will contain only one slice. 213 o The independent segment decoding (ISD) described in Annex R of 214 [H263P] prevents any data dependency across slice or GOB boundaries 215 in the reference picture. It can be utilized to further improve 216 resiliency in high loss conditions. 218 o If ISD is used in conjunction with the slice structure, the 219 rectangular slice submode shall be enabled and the dimensions and 220 quantity of the slices present in a frame shall remain the same 221 between each two intra-coded frames (I-frames), as required in 222 H.263+. The individual ISD segments may also be entirely intra coded 223 from time to time to realize quick error recovery without adding the 224 latency time associated with sending complete INTRA- pictures. 226 o When the slice structure is not applied, the insertion of a 227 (preferably byte-aligned) GOB header can be used to provide resync 228 boundaries in the bitstream, as the presence of a GOB header 229 eliminates the dependency of motion vector prediction across GOB 230 boundaries. These resync boundaries provide natural locations for 231 packet payload boundaries. 233 o H.263+ allows picture headers to be sent in an abbreviated form in 234 order to prevent repetition of overhead information that does not 235 change from picture to picture. For resiliency, sending a complete 236 picture header for every frame is often advisable. This means that 237 (especially in cases with high packet loss probability in which 238 picture header contents are not expected to be highly predictable), 239 the sender may find it advisable to always set the subfield UFEP in 240 PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263P] for 241 the definition of the UFEP and PLUSPTYPE fields). 243 o In a multi-layer scenario, each layer may be transmitted to a 244 different network address. The configuration of each layer such as 245 the enhancement layer number (ELNUM), reference layer number (RLNUM), 246 and scalability type should be determined at the start of the session 247 and should not change during the course of the session. 249 o All start codes can be byte aligned, and picture, slice, and EOSBS 250 start codes are always byte aligned. The boundaries of these 251 syntactical elements provide ideal locations for placing packet 252 boundaries. 254 o We assume that a maximum Picture Header size of 504 bits is 255 sufficient. The syntax of H.263+ does not explicitly prohibit larger 256 picture header sizes, but the use of such extremely large picture 257 headers is not expected. 259 4. Usage of RTP 261 When transmitting H.263+ video streams over the Internet, the output 262 of the encoder can be packetized directly. All the bits resulting 263 from the bitstream including the fixed length codes and variable 264 length codes will be included in the packet, with the only exception 265 being that when the payload of a packet begins with a Picture, GOB, 266 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 267 the start code shall be removed and replaced by setting an indicator 268 bit in the payload header. 270 For H.263+ bitstreams coded with temporal, spatial, or SNR 271 scalability, each layer may be transported to a different network 272 address. More specifically, each layer may use a unique IP address 273 and port number combination. The temporal relations between layers 274 shall be expressed using the RTP timestamp so that they can be 275 synchronized at the receiving ends in multicast or unicast 276 applications. 278 The H.263+ video stream will be carried as payload data within RTP 279 packets. A new H.263+ payload header is defined in section 4. This 280 section defines the usage of the RTP fixed header and H.263+ video 281 packet structure. 283 4.1 RTP Header Usage 285 Each RTP packet starts with a fixed RTP header. The following fields 286 of the RTP fixed header are used for H.263+ video streams: 288 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 289 the current packet carries the end of current frame, and is 0 290 otherwise. 292 Payload Type (PT): According to RFC 3551[RFC3551] table 5, a Dynamic 293 Payload Type SHALL be used to specify the H.263+ and H.263++ video 294 payload formats for RTP/AVP. 296 Timestamp: The RTP Timestamp encodes the sampling instance of the 297 first video frame data contained in the RTP data packet. The RTP 298 timestamp shall be the same on successive packets if a video frame 299 occupies more than one packet. In a multilayer scenario, all 300 pictures corresponding to the same temporal reference should use the 301 same timestamp. If temporal scalability is used (if B-frames are 302 present), the timestamp may not be monotonically increasing in the 303 RTP stream. If B-frames are transmitted on a separate layer and 304 address, they must be synchronized properly with the reference 305 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 306 information on required transmission order to a decoder. For an 307 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 308 the same as that of the RTP payload for H.261 stream [RFC2032]. 309 Since both the H.263+ data and the RTP header contain time 310 information, those timing information must run synchronously. That 311 is, both the RTP timestamp and the temporal reference (TR in the 312 picture header of H.263) should carry the same relative timing 313 information. Any H.263+ picture clock frequency can be expressed as 314 1800000/(cd*cf) source pictures per second, in which cd is an integer 315 from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock 316 of the RTP timestamp, the time increment between each coded H.263+ 317 picture should therefore be a integer multiple of (cd*cf)/20. This 318 will always be an integer for any "reasonable" picture clock 319 frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz 320 PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer 321 display update rates of 60, 72 and 75 Hz, respectively). For RTP 322 packetization of hypothetical H.263+ bitstreams using "unreasonable" 323 custom picture clock frequencies, mathematical rounding could become 324 necessary for generating the RTP timestamps. 326 4.2 Video Packet Structure 328 A section of an H.263+ compressed bitstream is carried as a payload 329 within each RTP packet. For each RTP packet, the RTP header is 330 followed by an H.263+ payload header, which is followed by a number 331 of bytes of a standard H.263+ compressed bitstream. The size of the 332 H.263+ payload header is variable depending on the payload involved 333 as detailed in the section 3. The layout of the RTP H.263+ video 334 packet is shown as: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | RTP Header 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | H.263+ Payload Header 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | H.263+ Compressed Data Stream 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Any H.263+ start codes can be byte aligned by an encoder by using the 347 stuffing mechanisms of H.263+. As specified in H.263+, picture, 348 slice, and EOSBS starts codes shall always be byte aligned, and GOB 349 and EOS start codes may be byte aligned. For packetization purposes, 350 GOB start codes should be byte aligned; however, since this is not 351 required in H.263+, there may be some cases where GOB start codes are 352 not aligned, such as when transmitting existing content, or when 353 using H.263 encoders that do not support GOB start code alignment. 355 In this case, follow-on packets (see section 5.2) should be used for 356 packetization. 358 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 359 with 16 zero-valued bits. If a start code is byte aligned and it 360 occurs at the beginning of a packet, these two bytes shall be removed 361 from the H.263+ compressed data stream in the packetization process 362 and shall instead be represented by setting a bit (the P bit) in the 363 payload header. 365 5. H.263+ Payload Header 367 For H.263+ video streams, each RTP packet shall carry only one H.263+ 368 video packet. The H.263+ payload header shall always be present for 369 each H.263+ video packet. The payload header is of variable length. 370 A 16 bit field of the basic payload header may be followed by an 8 371 bit field for Video Redundancy Coding (VRC) information, and/or by a 372 variable length extra picture header as indicated by PLEN. These 373 optional fields appear in the order given above when present. 375 If an extra picture header is included in the payload header, the 376 length of the picture header in number of bytes is specified by PLEN. 377 The minimum length of the payload header is 16 bits, corresponding to 378 PLEN equal to 0 and no VRC information present. 380 The remainder of this section defines the various components of the 381 RTP payload header. Section six defines the various packet types 382 that are used to carry different types of H.263+ coded data, and 383 section seven summarizes how to distinguish between the various 384 packet types. 386 5.1 General H.263+ payload header 388 The H.263+ payload header is structured as follows: 390 0 1 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | RR |P|V| PLEN |PEBIT| 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 RR: 5 bits 398 Reserved bits. Shall be zero. MUST be ignored by receivers 400 P: 1 bit 402 Indicates the picture start or a picture segment (GOB/Slice) start or 403 a video sequence end (EOS or EOSBS). Two bytes of zero bits then 404 have to be prefixed to the payload of such a packet to compose a 405 complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the 406 omission of the two first bytes of the start codes, thus improving 407 the compression ratio. 409 V: 1 bit 411 Indicates the presence of an 8 bit field containing information for 412 Video Redundancy Coding (VRC), which follows immediately after the 413 initial 16 bits of the payload header if present. For syntax and 414 semantics of that 8 bit VRC field see section 5.2. 416 PLEN: 6 bits 418 Length in bytes of the extra picture header. If no extra picture 419 header is attached, PLEN is 0. If PLEN>0, the extra picture header 420 is attached immediately following the rest of the payload header. 421 Note the length reflects the omission of the first two bytes of the 422 picture start code (PSC). See section 6.1. 424 PEBIT: 3 bits 426 Indicates the number of bits that shall be ignored in the last byte 427 of the picture header. If PLEN is not zero, the ignored bits shall 428 be the least significant bits of the byte. If PLEN is zero, then 429 PEBIT shall also be zero. 431 5.2 Video Redundancy Coding Header Extension 433 Video Redundancy Coding (VRC) is an optional mechanism intended to 434 improve error resilience over packet networks. Implementing VRC in 435 H.263+ will require the Reference Picture Selection option described 436 in Annex N of [H263P]. By having multiple "threads" of independently 437 inter-frame predicted pictures, damage of individual frame will cause 438 distortions only within its own thread but leave the other threads 439 unaffected. From time to time, all threads converge to a so-called 440 sync frame (an INTRA picture or a non-INTRA picture which is 441 redundantly represented within multiple threads); from this sync 442 frame, the independent threads are started again. For more 443 information on codec support for VRC see [Vredun]. 445 P-picture temporal scalability is another use of the reference 446 picture selection mode and can be considered a special case of VRC in 447 which only one copy of each sync frame may be sent. It offers a 448 thread-based method of temporal scalability without the increased 449 delay caused by the use of B pictures. In this use, sync frames sent 450 in the first thread of pictures are also used for the prediction of a 451 second thread of pictures which fall temporally between the sync 452 frames to increase the resulting frame rate. In this use, the 453 pictures in the second thread can be discarded in order to obtain a 454 reduction of bit rate or decoding complexity without harming the 455 ability to decode later pictures. A third or more threads can also 456 be added as well, but each thread is predicted only from the sync 457 frames (which are sent at least in thread 0) or from frames within 458 the same thread. 460 While a VRC data stream is - like all H.263+ data - totally 461 self-contained, it may be useful for the transport hierarchy 462 implementation to have knowledge about the current damage status of 463 each thread. On the Internet, this status can easily be determined 464 by observing the marker bit, the sequence number of the RTP header, 465 and the thread-id and a circling "packet per thread" number. The 466 latter two numbers are coded in the VRC header extension. 468 The format of the VRC header extension is as follows: 470 0 1 2 3 4 5 6 7 471 +-+-+-+-+-+-+-+-+ 472 | TID | Trun |S| 473 +-+-+-+-+-+-+-+-+ 475 TID: 3 bits 477 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 478 data will use as reference information only sync frames or frames 479 within the same thread. By convention, thread 0 is expected to be 480 the "canonical" thread, which is the thread from which the sync frame 481 should ideally be used. In the case of corruption or loss of the 482 thread 0 representation, a representation of the sync frame with a 483 higher thread number can be used by the decoder. Lower thread 484 numbers are expected to contain equal or better representations of 485 the sync frames than higher thread numbers in the absence of data 486 corruption or loss. See [Vredun] for a detailed discussion of VRC. 488 Trun: 4 bits 490 Monotonically increasing (modulo 16) 4 bit number counting the packet 491 number within each thread. 493 S: 1 bit 495 A bit that indicates that the packet content is for a sync frame. An 496 encoder using VRC may send several representations of the same "sync" 497 picture, in order to ensure that regardless of which thread of 498 pictures is corrupted by errors or packet losses, the reception of at 499 least one representation of a particular picture is ensured (within 500 at least one thread). The sync picture can then be used for the 501 prediction of any thread. If packet losses have not occurred, then 502 the sync frame contents of thread 0 can be used and those of other 503 threads can be discarded (and similarly for other threads). Thread 0 504 is considered the "canonical" thread, the use of which is preferable 505 to all others. The contents of packets having lower thread numbers 506 shall be considered as having a higher processing and delivery 507 priority than those with higher thread numbers. Thus packets having 508 lower thread numbers for a given sync frame shall be delivered first 509 to the decoder under loss-free and low-time-jitter conditions, which 510 will result in the discarding of the sync contents of the 511 higher-numbered threads as specified in Annex N of [H263P]. 513 6. Packetization schemes 515 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) 517 A picture segment packet is defined as a packet that starts at the 518 location of a Picture, GOB, or slice start code in the H.263+ data 519 stream. This corresponds to the definition of the start of a video 520 picture segment as defined in H.263+. For such packets, P=1 always. 522 An extra picture header can sometimes be attached in the payload 523 header of such packets. Whenever an extra picture header is attached 524 as signified by PLEN>0, only the last six bits of its picture start 525 code, '100000', are included in the payload header. A complete 526 H.263+ picture header with byte aligned picture start code can be 527 conveniently assembled on the receiving end by prepending the sixteen 528 leading '0' bits. 530 When PLEN>0, the end bit position corresponding to the last byte of 531 the picture header data is indicated by PEBIT. The actual bitstream 532 data shall begin on an 8-bit byte boundary following the payload 533 header. 535 A sequence ending packet is defined as a packet that starts at the 536 location of an EOS or EOSBS code in the H.263+ data stream. This 537 delineates the end of a sequence of H.263+ video data (more H.263+ 538 video data may still follow later, however, as specified in ITU-T 539 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 541 The optional header extension for VRC may or may not be present as 542 indicated by the V bit flag. 544 6.1.1 Packets that begin with a Picture Start Code 546 Any packet that contains the whole or the start of a coded picture 547 shall start at the location of the picture start code (PSC), and 548 should normally be encapsulated with no extra copy of the picture 549 header. In other words, normally PLEN=0 in such a case. However, if 550 the coded picture contains an incomplete picture header (UFEP = 551 "000"), then a representation of the complete (UFEP = "001") picture 552 header may be attached during packetization in order to provide 553 greater error resilience. Thus, for packets that start at the 554 location of a picture start code, PLEN shall be zero unless both of 555 the following conditions apply: 557 1) The picture header in the H.263+ bitstream payload is incomplete 558 (PLUSPTYPE present and UFEP="000"), and 560 2) The additional picture header which is attached is not incomplete 561 (UFEP="001"). 563 A packet which begins at the location of a Picture, GOB, slice, EOS, 564 or EOSBS start code shall omit the first two (all zero) bytes from 565 the H.263+ bitstream, and signify their presence by setting P=1 in 566 the payload header. 568 Here is an example of encapsulating the first packet in a frame 569 (without an attached redundant complete picture header): 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | first two 0 bytes of the PSC 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 6.1.2 Packets that begin with GBSC or SSC 581 For a packet that begins at the location of a GOB or slice start 582 code, PLEN may be zero or may be nonzero, depending on whether a 583 redundant picture header is attached to the packet. In environments 584 with very low packet loss rates, or when picture header contents are 585 very seldom likely to change (except as can be detected from the GFID 586 syntax of H.263+), a redundant copy of the picture header is not 587 required. However, in less ideal circumstances a redundant picture 588 header should be attached for enhanced error resilience, and its 589 presence is indicated by PLEN>0. 591 Assuming a PLEN of 9 and P=1, below is an example of a packet that 592 begins with a byte aligned GBSC or a SSC: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | starting with TR, PTYPE ... | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | ... | bitstream | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | data starting with GBSC/SSC without its first two 0 bytes 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Notice that only the last six bits of the picture start code, 607 '100000', are included in the payload header. A complete H.263+ 608 picture header with byte aligned picture start code can be 609 conveniently assembled if needed on the receiving end by prepending 610 the sixteen leading '0' bits. 612 6.1.3 Packets that Begin with an EOS or EOSBS Code 614 For a packet that begins with an EOS or EOSBS code, PLEN shall be 615 zero, and no Picture, GOB, or Slice start codes shall be included 616 within the same packet. As with other packets beginning with start 617 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 618 beginning of the packet shall be omitted, and their presence shall be 619 indicated by setting the P bit to 1 in the payload header. 621 System designers should be aware that some decoders may interpret the 622 loss of a packet containing only EOS or EOSBS information as the loss 623 of essential video data and may thus respond by not displaying some 624 subsequent video information. Since EOS and EOSBS codes do not 625 actually affect the decoding of video pictures, they are somewhat 626 unnecessary to send at all. Because of the danger of 627 misinterpretation of the loss of such a packet (which can be detected 628 by the sequence number), encoders are generally to be discouraged 629 from sending EOS and EOSBS. 631 Below is an example of a packet containing an EOS code: 633 0 1 2 634 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 6.2 Encapsulating Follow-On Packet (P=0) 641 A Follow-on packet contains a number of bytes of coded H.263+ data 642 which does not start at a synchronization point. That is, a 643 Follow-On packet does not start with a Picture, GOB, Slice, EOS, or 644 EOSBS header, and it may or may not start at a macroblock boundary. 645 Since Follow-on packets do not start at synchronization points, the 646 data at the beginning of a follow-on packet is not independently 647 decodable. For such packets, P=0 always. If the preceding packet of 648 a Follow-on packet got lost, the receiver may discard that Follow-on 649 packet as well as all other following Follow-on packets. Better 650 behavior, of course, would be for the receiver to scan the interior 651 of the packet payload content to determine whether any start codes 652 are found in the interior of the packet which can be used as resync 653 points. The use of an attached copy of a picture header for a 654 follow-on packet is useful only if the interior of the packet or some 655 subsequent follow-on packet contains a resync code such as a GOB or 656 slice start code. PLEN>0 is allowed, since it may allow resync in 657 the interior of the packet. The decoder may also be resynchronized 658 at the next segment or picture packet. 660 Here is an example of a follow-on packet (with PLEN=0): 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 665 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 668 7. Use of this payload specification 670 There is no syntactical difference between a picture segment packet 671 and a Follow-on packet, other than the indication P=1 for picture 672 segment or sequence ending packets and P=0 for Follow-on packets. 673 See the following for a summary of the entire packet types and ways 674 to distinguish between them. 676 It is possible to distinguish between the different packet types by 677 checking the P bit and the first 6 bits of the payload along with the 678 header information. The following table shows the packet type for 679 permutations of this information (see also the picture/GOB/Slice 680 header descriptions in H.263+ for details): 682 -------------+--------------+----------------------+---------------- 683 First 6 bits | P-Bit | PLEN | Packet | Remarks 684 of Payload |(payload hdr.)| | 685 -------------+--------------+----------------------+---------------- 686 100000 | 1 | 0 | Picture | Typical Picture 687 100000 | 1 | > 0 | Picture | Note UFEP 688 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 689 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 690 Xxxxxx | 0 | 0 | Follow-on | 691 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 692 -------------+--------------+----------------------+---------------- 694 The details regarding the possible values of the five bit Group 695 Number (GN) field which follows the initial "1" bit when the P-bit is 696 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 697 of H.263[H263P]. 699 As defined in this specification, every start of a coded frame (as 700 indicated by the presence of a PSC) has to be encapsulated as a 701 picture segment packet. If the whole coded picture fits into one 702 packet of reasonable size (which is dependent on the connection 703 characteristics), this is the only type of packet that may need to be 704 used. Due to the high compression ratio achieved by H.263+ it is 705 often possible to use this mechanism, especially for small spatial 706 picture formats such as QCIF and typical Internet packet sizes around 707 1500 bytes. 709 If the complete coded frame does not fit into a single packet, two 710 different ways for the packetization may be chosen. In case of very 711 low or zero packet loss probability, one or more Follow-on packets 712 may be used for coding the rest of the picture. Doing so leads to 713 minimal coding and packetization overhead as well as to an optimal 714 use of the maximal packet size, but does not provide any added error 715 resilience. 717 The alternative is to break the picture into reasonably small 718 partitions - called Segments - (by using the Slice or GOB mechanism), 719 that do offer synchronization points. By doing so and using the 720 Picture Segment payload with PLEN>0, decoding of the transmitted 721 packets is possible even in such cases in which the Picture packet 722 containing the picture header was lost (provided any necessary 723 reference picture is available). Picture Segment packets can also be 724 used in conjunction with Follow-on packets for large segment sizes. 726 8. Payload Format Parameters 728 This section updates the H.263(1998) and H.263 (2000) media types 729 described in RFC3555 [RFC3555]. 731 This section specifies optional parameters that MAY be used to select 732 optional features of the H.263 codec. The parameters are specified 733 here as part of the MIME subtype registration for the ITU-T H.263 734 codec. A mapping of the parameters into the Session Description 735 Protocol (SDP)[RFC2327] is also provided for those applications that 736 use SDP. Multiple parameters SHOULD be expressed as a MIME media 737 type string, in the form of a semicolon separated list of 738 parameter=value pairs 740 8.1 IANA Considerations 742 This section describes the MIME types and names associated with this 743 payload format. The section updates the previous registered version 744 in RFC 3555 [RFC3555]. The section registers the MIME types, as per 745 RFC2048[RFC2048] 747 8.1.1 Registration of MIME media type video/H263-1998 749 MIME media type name: video 751 MIME subtype name: H263-1998 753 Required parameters: None 755 Optional parameters: 757 SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF 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 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 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 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 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 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 773 resolution. Permissible value are integer values from 1 to 32, which 774 correspond to a maximum frame rate of 29.97/ the specified value 775 frames per second. 777 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 778 resolution. Permissible value are integer values from 1 to 32, which 779 correspond to a maximum frame rate of 29.97/ the specified value 780 frames per second. 782 CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom 783 defined resolution. The custom parameter receives three comma 784 separated values Xmax , Ymax and MPI. The Xmax and Ymax parameters 785 describe the number of pixels in the X and Y axis and must be evenly 786 dividable by 4. The permissible value for MPI, are integer values 787 from 1 to 32, which correspond to a maximum frame rate of 29.97/ the 788 specified value. 790 A system that declares support of a specific MPI for one of the 791 resolutions SHALL also implicitly support a lower resolution with the 792 same MPI. 794 A list of optional annexes specifies which annexes of H.263 are 795 supported. The optional annexes are defined as part of H263-1998, 796 H263-2000. Annex X of H.263-2000 defines profiles which group 797 annexes for specific applications. A system that support a specific 798 annex SHALL specify it support using the optional parameters. 800 The allowed optional parameters for the annexes are "F", "I", "J", 801 "T" which do not get any values and "K", "N" and "P". 803 "K" can receive one of four values 1-4: 805 1: - Slices In Order-Non Rectangular 807 2: - Slices In Order-Rectangular 809 3: - Slices Not Ordered - Non Rectangular 811 4: - Slices Not Ordered - Rectangular 813 "N" - Reference Picture Selection mode - Four numeric choices (1-4) 814 are available representing the following modes: 816 1: NEITHER: In which no back-channel data is returned from the 817 decoder to the encoder. 819 2: ACK: In which the decoder returns only acknowledgment messages. 821 3: NACK: In which the decoder returns only non-acknowledgment 822 messages 824 4: ACK+NACK: In which the decoder returns both acknowledgment and 825 non-acknowledgment messages. 827 No special provision is made herein for carrying back channel 828 information. The Extended RTP Profile for RTCP-based Feedback [AVPF] 829 MAY be used as a back channel mechanism. 831 "P" - Reference Picture Resampling with the following submodes 832 represented as a number fro 1 to 4: 834 1: dynamicPictureResizingByFour 836 2: dynamicPictureResizingBySixteenthPel 838 3: dynamicWarpingHalfPel 840 4: dynamicWarpingSixteenthPel 842 Example: P=1,3 844 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height ratio 845 by two colon separated integers between 0 and 255. Default ratio is 846 12:11 if not otherwise specified. 848 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a floating 849 point value. Default value is 29.97 Hz. 851 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 852 bits allowed to represent a single picture. If this parameter is not 853 present, then the default value, based on the maximum supported 854 resolution, is used. BPP is integer value between 0 and 65536. 856 HRD - Hypothetical Reference Decoder: See annex B of H.263 857 specification[H263P]. 859 Encoding considerations: 861 This type is only defined for transfer via RTP [RFC3550] 863 Security considerations: See Section 10 865 Interoperability considerations: These are receiver options, current 866 implementations will not send any optional parameters in their SDP. 867 They will ignore the optional parameters and will encode the H.263 868 stream without any of the annexes. Most decoders support at least 869 QCIF and CIF fixed resolutions and they are expected to be available 870 almost in every H.263 based video application. 872 Published specification: RFC yyy ( This RFC) 874 Applications which use this media type: 876 Audio and video streaming and conferencing tools. 878 Additional information: none 880 Person and email address to contact for further information : 882 Roni Even: roni.even@polycom.co.il 884 Intended usage: COMMON 886 Author/Change controller: 888 Roni Even 890 8.1.2 Registration of MIME media type video/H263-2000 892 MIME media type name: video 894 MIME subtype name: H263-2000 896 Required parameters: None 898 Optional parameters: 900 The optional parameters of the H263-1998 type MAY be used with this 901 MIME subtype. Specific optional parameters that may be used with the 902 H263-2000 type are: 904 PROFILE: H.263 profile number, in the range 0 through 10, specifying 905 the supported H.263 annexes/subparts based on H.263 annex X. 907 LEVEL: Level of bitstream operation, in the range 0 through 100, 908 specifying the level of computational complexity of the decoding 909 process. 911 A system that specifies support of a PROFILE MUST specify the 912 supported LEVEL. 914 INTERLACE: Interlaced or 60 fields indicates the support for 915 interlace display mode. 917 Encoding considerations: 919 This type is only defined for transfer via RTP [RFC3550] 921 Security considerations: See Section 10 923 Interoperability considerations: The optional parameters PROFILE and 924 LEVEL SHALL NOT be used with any of the other optional parameters. 926 Published specification: RFC yyy 928 Applications which use this media type: 930 Audio and video streaming and conferencing tools. 932 Additional information: none 934 Person and email address to contact for further information : 936 Roni Even: roni.even@polycom.co.il 938 Intended usage: COMMON 940 Author/Change controller: 942 Roni Even 944 8.2 SDP Parameters 946 The MIME media types video/H263-1998 and video/H263-2000 are mapped 947 to fields in the Session Description Protocol (SDP) as follows: 949 o The media name in the "m=" line of SDP MUST be video. 951 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 952 or H263-2000 (the MIME subtype). 954 o The clock rate in the "a=rtpmap" line MUST be 90000. 956 o The optional parameters if any, MUST be included in the "a=fmtp" 957 line of SDP. These parameters are expressed as a MIME media type 958 string, in the form of a semicolon separated list of parameter=value 959 pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used 960 with any of the other optional parameters. 962 8.2.1 Usage with the SDP Offer Answer Model 964 When offering H.263 over RTP using SDP in an Offer/Answer 965 model[RFC3264] the following considerations are necessary. 967 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 968 the sender of this SDP message is able to decode those options. 969 These options are receiver's capability even when send in a 970 "sendonly" offer. 972 Picture sizes and MPI: 974 Supported picture sizes and their corresponding minimum picture 975 interval (MPI) information for H.263 can be combined. All picture 976 sizes can be advertised to the other party, or only a subset of it. 977 Terminal announces only those picture sizes (with their MPIs) which 978 it is willing to receive. For example, MPI=2 means that maximum 979 (decodeable) picture rate per second is about 15. 981 If the receiver does not specify the picture size /MPI optional 982 parameter then it SHOULD be ready to receive QCIF resolution with 983 MPI=1. 985 Parameters offered first are the most preferred picture mode to be 986 received. 988 Example of the usage of these parameters: 990 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 992 This means that encoder SHOULD send CIF picture size, which it can 993 decode at MPI=4. If that is not possible, then QCIF with MPI value 994 3, if neither are possible, then SQCIF with MPI value=2. The 995 receiver is able of (but least preferred) decoding custom picture 996 sizes (max 360x240) with MPI=2. Note that most decoders support at 997 least QCIF and CIF fixed resolutions and they are expected to be 998 available almost in every H.263 based video application. 1000 Below is an example of H.263 SDP in an offer. 1002 a=fmtp:xx CIF=4;QCIF=2;F;K=1 1004 This means that the sender of this message can decode H.263 bit 1005 stream with following options and parameters: Preferred resolution is 1006 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 1007 AP and slicesInOrder-NonRect options MAY be used. 1009 9. Backward Compatibility to RFC2429 1011 The current draft updates RFC2429. This section will address the 1012 major backward compatibility issues. 1014 9.1 New SDP optional parameters 1016 The draft adds new optional parameters to the H263-1998 and H263-2000 1017 payload type. Since these are optional parameters we expect old 1018 implementation to ignore these parameters while new implementations 1019 that will receive the H263-1998 and H263-2000 payload type with no 1020 parameters will behave as if the other side can accept H.263 at QCIF 1021 resolution and 30 frames per second. 1023 10. Security Considerations 1025 RTP packets using the payload format defined in this specification 1026 are subject to the security considerations discussed in the RTP 1027 specification [RFC3550], and any appropriate RTP profile (for example 1028 [RFC3551]). This implies that confidentiality of the media streams 1029 is achieved by encryption. Because the data compression used with 1030 this payload format is applied end-to-end, encryption may be 1031 performed after compression so there is no conflict between the two 1032 operations. 1034 A potential denial-of-service threat exists for data encoding using 1035 compression techniques that have non-uniform receiver-end 1036 computational load. The attacker can inject pathological datagrams 1037 into the stream which are complex to decode and cause the receiver to 1038 be overloaded. The usage of authentication of at least the RTP 1039 packet is RECOMMENDED 1041 As with any IP-based protocol, in some circumstances a receiver may 1042 be overloaded simply by the receipt of too many packets, either 1043 desired or undesired. Network-layer authentication may be used to 1044 discard packets from undesired sources, but the processing cost of 1045 the authentication itself may be too high. In a multicast 1046 environment, pruning of specific sources may be implemented in future 1047 versions of IGMP [RFC2032] and in multicast routing protocols to 1048 allow a receiver to select which sources are allowed to reach it. 1050 A security review of this payload format found no additional 1051 considerations beyond those in the RTP specification. 1053 11. Acknowledgements 1055 This is to acknowledge the work done by Carsten Bormann from 1056 Universitaet Bremen and Chad Zhu, Linda Cline, Gim Deisher, Tom 1057 Gardos, Christian Maciocco, Donald Newell from Intel Corp. who 1058 co-authored RFC2429. 1060 I would also like to acknowledge the work of Petri Koskelainen from 1061 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1062 for the new MIME types. 1064 12. Changes from previous versions of the document 1066 12.1 changes from RFC 2429 1068 The changes from the RFC 2429 are: 1070 1. The H.263 1998 and 2000 MIME type are now in the payload 1071 specification. 1073 2. Added optional parameters to the H.263 MIME types 1075 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload 1076 format should be used only to interact with legacy systems. 1078 4. Editorial changes to be in line with RFC editing procedures 1080 12.2 Changes from rfc2429-bis-00 1082 1. Changed from space separated parameters to semi colon according 1083 to the AVT guidelines 1085 2. Took out the MaxBR optional parameter. 1087 12.3 Changes from rfc2429-bis-03 1089 1. Change the section order between section 3 and 4. 1091 2. check for correct usage of keywords. 1093 13. References 1095 13.1 Normative References 1097 [H263] International Telecommunications Union, "Video coding for 1098 low bit rate communication", ITU Recommendation H.263, 1099 March 1996. 1101 [H263P] International Telecommunications Union, "Video coding for 1102 low bit rate communication", ITU Recommendation H.263P, 1103 February 1998. 1105 [H263X] International Telecommunications Union, "Annex X: Profiles 1106 and levels definition", ITU Recommendation H.263AnxX, 1107 April 2001. 1109 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1110 Streams", RFC 2032, October 1996. 1112 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1113 Internet Mail Extensions (MIME) Part Four: Registration 1114 Procedures", BCP 13, RFC 2048, November 1996. 1116 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1117 Requirement Levels", BCP 14, RFC 2119, March 1997. 1119 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 1120 2190, September 1997. 1122 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1123 Protocol", RFC 2327, April 1998. 1125 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1126 with Session Description Protocol (SDP)", RFC 3264, June 1127 2002. 1129 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1130 Jacobson, "RTP: A Transport Protocol for Real-Time 1131 Applications", STD 64, RFC 3550, July 2003. 1133 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1134 Video Conferences with Minimal Control", STD 65, RFC 3551, 1135 July 2003. 1137 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1138 Payload Formats", RFC 3555, July 2003. 1140 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1142 Audio-Visual Services over Packet Networks, Aberdeen, U.K. 1143 9/1997, September 1997. 1145 13.2 Informative References 1147 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1148 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1149 January 2004. 1151 Authors' Addresses 1153 Joerg Ott 1154 Univ. Bremen 1156 EMail: jo@acm.org 1158 Gary Sullivan 1159 Microsoft 1161 EMail: garysull@windows.microsoft.com 1163 Stephan Wenger 1164 TU Berlin 1166 EMail: stewe@cs.tu-berlin.de 1168 Roni Even 1169 Polycom 1170 94 Derech Em Hamoshavot 1171 Petach Tikva 49130 1172 Israel 1174 EMail: roni.even@polycom.co.il 1176 Intellectual Property Statement 1178 The IETF takes no position regarding the validity or scope of any 1179 Intellectual Property Rights or other rights that might be claimed to 1180 pertain to the implementation or use of the technology described in 1181 this document or the extent to which any license under such rights 1182 might or might not be available; nor does it represent that it has 1183 made any independent effort to identify any such rights. Information 1184 on the procedures with respect to rights in RFC documents can be 1185 found in BCP 78 and BCP 79. 1187 Copies of IPR disclosures made to the IETF Secretariat and any 1188 assurances of licenses to be made available, or the result of an 1189 attempt made to obtain a general license or permission for the use of 1190 such proprietary rights by implementers or users of this 1191 specification can be obtained from the IETF on-line IPR repository at 1192 http://www.ietf.org/ipr. 1194 The IETF invites any interested party to bring to its attention any 1195 copyrights, patents or patent applications, or other proprietary 1196 rights that may cover technology that may be required to implement 1197 this standard. Please address the information to the IETF at 1198 ietf-ipr@ietf.org. 1200 Disclaimer of Validity 1202 This document and the information contained herein are provided on an 1203 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1204 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1205 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1206 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1207 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1208 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1210 Copyright Statement 1212 Copyright (C) The Internet Society (2004). This document is subject 1213 to the rights, licenses and restrictions contained in BCP 78, and 1214 except as set forth therein, the authors retain all their rights. 1216 Acknowledgment 1218 Funding for the RFC Editor function is currently provided by the 1219 Internet Society.