doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc4629.txt b/doc/rfc/rfc4629.txt
new file mode 100644
index 0000000..fba70ac
--- /dev/null
+++ b/doc/rfc/rfc4629.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                             J. Ott
+Request for Comments: 4629             Helsinki University of Technology
+Obsoletes: 2429                                               C. Bormann
+Updates: 3555                                    Universitaet Bremen TZI
+Category: Standards Track                                    G. Sullivan
+                                                               Microsoft
+                                                               S. Wenger
+                                                                   Nokia
+                                                            R. Even, Ed.
+                                                                 Polycom
+                                                            January 2007
+
+
+             RTP Payload Format for ITU-T Rec. H.263 Video
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document describes a scheme to packetize an H.263 video stream
+   for transport using the Real-time Transport Protocol (RTP) with any
+   of the underlying protocols that carry RTP.
+
+   The document also describes the syntax and semantics of the Session
+   Description Protocol (SDP) parameters needed to support the H.263
+   video codec.
+
+   The document obsoletes RFC 2429 and updates the H263-1998 and
+   H263-2000 media type in RFC 3555.
+
+
+
+
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 1]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+   2. New H.263 Features ..............................................3
+   3. Usage of RTP ....................................................4
+      3.1. RTP Header Usage ...........................................5
+      3.2. Video Packet Structure .....................................6
+   4. Design Considerations ...........................................7
+   5. H.263+ Payload Header ...........................................9
+      5.1. General H.263+ Payload Header ..............................9
+      5.2. Video Redundancy Coding Header Extension ..................10
+   6. Packetization Schemes ..........................................12
+      6.1. Picture Segment Packets and Sequence Ending
+           Packets (P=1) .............................................12
+           6.1.1. Packets that begin with a Picture Start Code .......12
+           6.1.2. Packets that begin with GBSC or SSC ................13
+           6.1.3. Packets that begin with an EOS or EOSBS Code .......14
+      6.2. Encapsulating Follow-on Packet (P=0) ......................15
+   7. Use of this Payload Specification ..............................15
+   8. Media Type Definition ..........................................17
+      8.1. Media Type Registrations ..................................17
+           8.1.1. Registration of Media Type video/H263-1998 .........17
+           8.1.2. Registration of Media Type video/H263-2000 .........21
+      8.2. SDP Usage .................................................22
+           8.2.1. Usage with the SDP Offer Answer Model ..............23
+   9. Backward Compatibility to RFC 2429 .............................25
+      9.1. New Optional Parameters for SDP ...........................25
+   10. IANA Considerations ...........................................25
+   11. Security Considerations .......................................25
+   12. Acknowledgments ...............................................26
+   13. Changes from Previous Versions of the Documents ...............26
+      13.1. Changes from RFC 2429 ....................................26
+      13.2. Changes from RFC 3555 ....................................26
+   14. References ....................................................26
+      14.1. Normative References .....................................26
+      14.2. Informative References ...................................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 2]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+1.  Introduction
+
+   This document specifies an RTP payload header format applicable to
+   the transmission of video streams based on the 1998 and 2000 versions
+   of International Telecommunication Union-Telecommunication
+   Standardization Sector (ITU-T) Recommendation H.263 [H263].  Because
+   the 1998 and 2000 versions of H.263 are a superset of the 1996
+   syntax, this format can also be used with the 1996 version of H.263
+   and is recommended for this use by new implementations.  This format
+   replaces the payload format in RFC 2190 [RFC2190], which continues to
+   be used by some existing implementations, and can be useful for
+   backward compatibility.  New implementations supporting H.263 SHALL
+   use the payload format described in this document.  RFC 2190 is moved
+   to historic status [RFC4628].
+
+   The document updates the media type registration that was previously
+   in RFC 3555 [RFC3555].
+
+   This document obsoletes RFC 2429 [RFC2429].
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119] and
+   indicate requirement levels for compliant RTP implementations.
+
+2.  New H.263 Features
+
+   The 1998 version of ITU-T Recommendation H.263 added numerous coding
+   options to improve codec performance over the 1996 version.  In this
+   document, the 1998 version is referred to as H.263+ and the 2000
+   version as H.263++.
+
+   Among the new options, the ones with the biggest impact on the RTP
+   payload specification and the error resilience of the video content
+   are the slice structured mode, the independent segment decoding mode,
+   the reference picture selection mode, and the scalability mode.  This
+   section summarizes the impact of these new coding options on
+   packetization.  Refer to [H263] for more information on coding
+   options.
+
+   The slice structured mode was added to H.263+ for three purposes: to
+   provide enhanced error resilience capability, to make the bitstream
+   more amenable for use with an underlying packet transport such as
+   RTP, and to minimize video delay.  The slice structured mode supports
+   fragmentation at macroblock boundaries.
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 3]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   With the independent segment decoding (ISD) option, a video picture
+   frame is broken into segments and encoded in such a way that each
+   segment is independently decodable.  Utilizing ISD in a lossy network
+   environment helps to prevent the propagation of errors from one
+   segment of the picture to others.
+
+   The reference picture selection mode allows the use of an older
+   reference picture rather than the one immediately preceding the
+   current picture.  Usually, the last transmitted frame is implicitly
+   used as the reference picture for inter-frame prediction.  If the
+   reference picture selection mode is used, the data stream carries
+   information on what reference frame should be used, indicated by the
+   temporal reference as an ID for that reference frame.  The reference
+   picture selection mode may be used with or without a back channel,
+   which provides information to the encoder about the internal status
+   of the decoder.  However, no special provision is made herein for
+   carrying back channel information.  The Extended RTP Profile for RTP
+   Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a
+   back channel mechanism.
+
+   H.263+ also includes bitstream scalability as an optional coding
+   mode.  Three kinds of scalability are defined: temporal, signal-to-
+   noise ratio (SNR), and spatial scalability.  Temporal scalability is
+   achieved via the disposable nature of bi-directionally predicted
+   frames, or B-frames.  (A low-delay form of temporal scalability known
+   as P-picture temporal scalability can also be achieved by using the
+   reference picture selection mode, described in the previous
+   paragraph.)  SNR scalability permits refinement of encoded video
+   frames, thereby improving the quality (or SNR).  Spatial scalability
+   is similar to SNR scalability except that the refinement layer is
+   twice the size of the base layer in the horizontal dimension,
+   vertical dimension, or both.
+
+   H.263++ added some new functionalities.  Among the new
+   functionalities are support for interlace mode, specified in H.263,
+   annex W.6.3.11, and the definition of profiles and levels in H.263
+   annex X.
+
+3.  Usage of RTP
+
+   When transmitting H.263+ video streams over the Internet, the output
+   of the encoder can be packetized directly.  All the bits resulting
+   from the bitstream (including the fixed length codes and variable
+   length codes) will be included in the packet, the only exception
+   being that when the payload of a packet begins with a Picture, GOB,
+   Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start
+   code, the first 2 (all-zero) bytes of the start code shall be removed
+   and replaced by setting an indicator bit in the payload header.
+
+
+
+Ott, et al.                 Standards Track                     [Page 4]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   For H.263+ bitstreams coded with temporal, spatial, or SNR
+   scalability, each layer may be transported to a different network
+   address.  More specifically, each layer may use a unique IP address
+   and port number combination.  The temporal relations between layers
+   shall be expressed using the RTP timestamp so that they can be
+   synchronized at the receiving ends in multicast or unicast
+   applications.
+
+   The H.263+ video stream will be carried as payload data within RTP
+   packets.  A new H.263+ payload header is defined in Section 5; it
+   updates the one specified in RFC 2190.  This section defines the
+   usage of the RTP fixed header and H.263+ video packet structure.
+
+3.1.  RTP Header Usage
+
+   Each RTP packet starts with a fixed RTP header.  The following fields
+   of the RTP fixed header used for H.263+ video streams are further
+   emphasized here.
+
+   Marker bit (M bit): The Marker bit of the RTP header is set to 1 when
+   the current packet carries the end of current frame and is 0
+   otherwise.
+
+   Payload Type (PT): The RTP profile for a particular class of
+   applications will assign a payload type for this encoding, or, if
+   that is not done, a payload type in the dynamic range shall be chosen
+   by the sender.
+
+   Timestamp: The RTP Timestamp encodes the sampling instance of the
+   first video frame data contained in the RTP data packet.  The RTP
+   timestamp shall be the same on successive packets if a video frame
+   occupies more than one packet.  In a multilayer scenario, all
+   pictures corresponding to the same temporal reference should use the
+   same timestamp.  If temporal scalability is used (if B-frames are
+   present), the timestamp may not be monotonically increasing in the
+   RTP stream.  If B-frames are transmitted on a separate layer and
+   address, they must be synchronized properly with the reference
+   frames.  Refer to ITU-T Recommendation H.263 [H263] for information
+   on required transmission order to a decoder.  For an H.263+ video
+   stream, the RTP timestamp is based on a 90 kHz clock, the same as
+   that of the RTP payload for H.261 stream [RFC2032].  Since both the
+   H.263+ data and the RTP header contain time information, that timing
+   information must run synchronously.  That is, both the RTP timestamp
+   and the temporal reference (TR in the picture header of H.263) should
+   carry the same relative timing information.  Any H.263+ picture clock
+   frequency can be expressed as 1800000/(cd*cf) source pictures per
+   second, in which cd is an integer from 1 to 127 and cf is either 1000
+   or 1001.  Using the 90 kHz clock of the RTP timestamp, the time
+
+
+
+Ott, et al.                 Standards Track                     [Page 5]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   increment between each coded H.263+ picture should therefore be an
+   integer multiple of (cd*cf)/20.  This will always be an integer for
+   any "reasonable" picture clock frequency (for example, it is 3003 for
+   30/1.001 Hz NTSC; 3600 for 25 Hz PAL; 3750 for 24 Hz film; and 1500,
+   1250, or 1200 for the computer display update rates of 60, 72, or 75
+   Hz, respectively).  For RTP packetization of hypothetical H.263+
+   bitstreams using "unreasonable" custom picture clock frequencies,
+   mathematical rounding could become necessary for generating the RTP
+   timestamps.
+
+3.2.  Video Packet Structure
+
+   A section of an H.263+ compressed bitstream is carried as a payload
+   within each RTP packet.  For each RTP packet, the RTP header is
+   followed by an H.263+ payload header, which is followed by a number
+   of bytes of a standard H.263+ compressed bitstream.  The size of the
+   H.263+ payload header is variable, depending on the payload involved,
+   as detailed in the Section 4.  The layout of the RTP H.263+ video
+   packet is shown as
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      :    RTP Header                                                 :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      :    H.263+ Payload Header                                      :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      :    H.263+ Compressed Data Stream                              :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any H.263+ start codes can be byte aligned by an encoder by using the
+   stuffing mechanisms of H.263+.  As specified in H.263+, picture,
+   slice, and EOSBS starts codes shall always be byte aligned, and GOB
+   and EOS start codes may be byte aligned.  For packetization purposes,
+   GOB start codes should be byte aligned; however, since this is not
+   required in H.263+, there may be some cases where GOB start codes are
+   not aligned, such as when transmitting existing content, or when
+   using H.263 encoders that do not support GOB start code alignment.
+   In this case, Follow-on Packets (see Section 5.2) should be used for
+   packetization.
+
+   All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin
+   with 16 zero-valued bits.  If a start code is byte aligned and it
+   occurs at the beginning of a packet, these two bytes shall be removed
+   from the H.263+ compressed data stream in the packetization process
+   and shall instead be represented by setting a bit (the P bit) in the
+   payload header.
+
+
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 6]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+4.  Design Considerations
+
+   The goals of this payload format are to specify an efficient way of
+   encapsulating an H.263+ standard compliant bitstream and to enhance
+   the resiliency towards packet losses.  Due to the large number of
+   different possible coding schemes in H.263+, a copy of the picture
+   header with configuration information is inserted into the payload
+   header when appropriate.  The use of that copy of the picture header
+   along with the payload data can allow decoding of a received packet
+   even in cases when another packet containing the original picture
+   header becomes lost.
+
+   There are a few assumptions and constraints associated with this
+   H.263+ payload header design.  The purpose of this section is to
+   point out various design issues and also to discuss several coding
+   options provided by H.263+ that may impact the performance of
+   network-based H.263+ video.
+
+   o  The optional slice structured mode described in Annex K of [H263]
+      enables more flexibility for packetization.  Similar to a picture
+      segment that begins with a GOB header, the motion vector
+      predictors in a slice are restricted to reside within its
+      boundaries.  However, slices provide much greater freedom in the
+      selection of the size and shape of the area that is represented as
+      a distinct decodable region.  In particular, slices can have a
+      size that is dynamically selected to allow the data for each slice
+      to fit into a chosen packet size.  Slices can also be chosen to
+      have a rectangular shape, which is conducive for minimizing the
+      impact of errors and packet losses on motion-compensated
+      prediction.  For these reasons, the use of the slice structured
+      mode is strongly recommended for any applications used in
+      environments where significant packet loss occurs.
+
+   o  In non-rectangular slice structured mode, only complete slices
+      SHOULD be included in a packet.  In other words, slices should not
+      be fragmented across packet boundaries.  The only reasonable need
+      for a slice to be fragmented across packet boundaries is when the
+      encoder that generated the H.263+ data stream could not be
+      influenced by an awareness of the packetization process (such as
+      when sending H.263+ data through a network other than the one to
+      which the encoder is attached, as in network gateway
+      implementations).  Optimally, each packet will contain only one
+      slice.
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 7]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   o  The independent segment decoding (ISD) described in Annex R of
+      [H263] prevents any data dependency across slice or GOB boundaries
+      in the reference picture.  It can be utilized to improve
+      resiliency further in high loss conditions.
+
+   o  If ISD is used in conjunction with the slice structure, the
+      rectangular slice submode shall be enabled, and the dimensions and
+      quantity of the slices present in a frame shall remain the same
+      between each two intra-coded frames (I-frames), as required in
+      H.263+.  The individual ISD segments may also be entirely intra
+      coded from time to time to realize quick error recovery without
+      adding the latency time associated with sending complete INTRA-
+      pictures.
+
+   o  When the slice structure is not applied, the insertion of a
+      (preferably byte-aligned) GOB header can be used to provide resync
+      boundaries in the bitstream, as the presence of a GOB header
+      eliminates the dependency of motion vector prediction across GOB
+      boundaries.  These resync boundaries provide natural locations for
+      packet payload boundaries.
+
+   o  H.263+ allows picture headers to be sent in an abbreviated form in
+      order to prevent repetition of overhead information that does not
+      change from picture to picture.  For resiliency, sending a
+      complete picture header for every frame is often advisable.  This
+      means (especially in cases with high packet loss probability in
+      which picture header contents are not expected to be highly
+      predictable) that the sender may find it advisable always to set
+      the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video
+      bitstream.  (See [H263] for the definition of the UFEP and
+      PLUSPTYPE fields).
+
+   o  In a multi-layer scenario, each layer may be transmitted to a
+      different network address.  The configuration of each layer, such
+      as the enhancement layer number (ELNUM), reference layer number
+      (RLNUM), and scalability type should be determined at the start of
+      the session and should not change during the course of the
+      session.
+
+   o  All start codes can be byte aligned, and picture, slice, and EOSBS
+      start codes are always byte aligned.  The boundaries of these
+      syntactical elements provide ideal locations for placing packet
+      boundaries.
+
+   o  We assume that a maximum Picture Header size of 504 bits is
+      sufficient.  The syntax of H.263+ does not explicitly prohibit
+      larger picture header sizes, but the use of such extremely large
+      picture headers is not expected.
+
+
+
+Ott, et al.                 Standards Track                     [Page 8]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+5.  H.263+ Payload Header
+
+   For H.263+ video streams, each RTP packet shall carry only one H.263+
+   video packet.  The H.263+ payload header shall always be present for
+   each H.263+ video packet.  The payload header is of variable length.
+   A 16-bit field of the general payload header, defined in 5.1, may be
+   followed by an 8 bit field for Video Redundancy Coding (VRC)
+   information, and/or by a variable-length extra picture header as
+   indicated by PLEN.  These optional fields appear in the order given
+   above, when present.
+
+   If an extra picture header is included in the payload header, the
+   length of the picture header in number of bytes is specified by PLEN.
+   The minimum length of the payload header is 16 bits, PLEN equal to 0
+   and no VRC information being present.
+
+   The remainder of this section defines the various components of the
+   RTP payload header.  Section 6 defines the various packet types that
+   are used to carry different types of H.263+ coded data, and Section 7
+   summarizes how to distinguish between the various packet types.
+
+5.1.  General H.263+ Payload Header
+
+   The H.263+ payload header is structured as follows:
+
+         0                   1
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        |   RR    |P|V|   PLEN    |PEBIT|
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   RR: 5 bits
+
+      Reserved bits.  It SHALL be zero and MUST be ignored by receivers.
+
+   P: 1 bit
+
+      Indicates the picture start or a picture segment (GOB/Slice) start
+      or a video sequence end (EOS or EOSBS).  Two bytes of zero bits
+      then have to be prefixed to the payload of such a packet to
+      compose a complete picture/GOB/slice/EOS/EOSBS start code.  This
+      bit allows the omission of the two first bytes of the start codes,
+      thus improving the compression ratio.
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                     [Page 9]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   V: 1 bit
+
+      Indicates the presence of an 8-bit field containing information
+      for Video Redundancy Coding (VRC), which follows immediately after
+      the initial 16 bits of the payload header, if present.  For syntax
+      and semantics of that 8-bit VRC field, see Section 5.2.
+
+   PLEN: 6 bits
+
+      Length, in bytes, of the extra picture header.  If no extra
+      picture header is attached, PLEN is 0.  If PLEN>0, the extra
+      picture header is attached immediately following the rest of the
+      payload header.  Note that the length reflects the omission of the
+      first two bytes of the picture start code (PSC).  See Section 6.1.
+
+   PEBIT: 3 bits
+
+      Indicates the number of bits that shall be ignored in the last
+      byte of the picture header.  If PLEN is not zero, the ignored bits
+      shall be the least significant bits of the byte.  If PLEN is zero,
+      then PEBIT shall also be zero.
+
+5.2.  Video Redundancy Coding Header Extension
+
+   Video Redundancy Coding (VRC) is an optional mechanism intended to
+   improve error resilience over packet networks.  Implementing VRC in
+   H.263+ will require the Reference Picture Selection option described
+   in Annex N of [H263].  By having multiple "threads" of independently
+   inter-frame predicted pictures, damage to an individual frame will
+   cause distortions only within its own thread, leaving the other
+   threads unaffected.  From time to time, all threads converge to a
+   so-called sync frame (an INTRA picture or a non-INTRA picture that is
+   redundantly represented within multiple threads); from this sync
+   frame, the independent threads are started again.  For more
+   information on codec support for VRC, see [Vredun].
+
+   P-picture temporal scalability is another use of the reference
+   picture selection mode and can be considered a special case of VRC in
+   which only one copy of each sync frame may be sent.  It offers a
+   thread-based method of temporal scalability without the increased
+   delay caused by the use of B pictures.  In this use, sync frames sent
+   in the first thread of pictures are also used for the prediction of a
+   second thread of pictures that fall temporally between the sync
+   frames to increase the resulting frame rate.  In this use, the
+   pictures in the second thread can be discarded in order to obtain a
+   reduction of bit rate or decoding complexity without harming the
+   ability to decode later pictures.  A third or more threads, can also
+   be added, but each thread is predicted only from the sync frames
+
+
+
+Ott, et al.                 Standards Track                    [Page 10]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   (which are sent at least in thread 0) or from frames within the same
+   thread.
+
+   While a VRC data stream is (like all H.263+ data) totally self-
+   contained, it may be useful for the transport hierarchy
+   implementation to have knowledge about the current damage status of
+   each thread.  On the Internet, this status can easily be determined
+   by observing the marker bit, the sequence number of the RTP header,
+   the thread-id, and a circling "packet per thread" number.  The latter
+   two numbers are coded in the VRC header extension.
+
+   The format of the VRC header extension is as follows:
+
+         0 1 2 3 4 5 6 7
+        +-+-+-+-+-+-+-+-+
+        | TID | Trun  |S|
+        +-+-+-+-+-+-+-+-+
+
+   TID: 3 bits
+
+   Thread ID.  Up to 7 threads are allowed.  Each frame of H.263+ VRC
+   data will use as reference information only sync frames or frames
+   within the same thread.  By convention, thread 0 is expected to be
+   the "canonical" thread, which is the thread from which the sync frame
+   should ideally be used.  In the case of corruption or loss of the
+   thread 0 representation, a representation of the sync frame with a
+   higher thread number can be used by the decoder.  Lower thread
+   numbers are expected to contain representations of the sync frames
+   equal to or better than higher thread numbers in the absence of data
+   corruption or loss.  See [Vredun] for a detailed discussion of VRC.
+
+   Trun: 4 bits
+
+   Monotonically increasing (modulo 16) 4-bit number counting the packet
+   number within each thread.
+
+   S: 1 bit
+
+   A bit that indicates that the packet content is for a sync frame.  An
+   encoder using VRC may send several representations of the same "sync"
+   picture, in order to ensure that, regardless of which thread of
+   pictures is corrupted by errors or packet losses, the reception of at
+   least one representation of a particular picture is ensured (within
+   at least one thread).  The sync picture can then be used for the
+   prediction of any thread.  If packet losses have not occurred, then
+   the sync frame contents of thread 0 can be used, and those of other
+   threads can be discarded (and similarly for other threads).  Thread 0
+   is considered the "canonical" thread, the use of which is preferable
+
+
+
+Ott, et al.                 Standards Track                    [Page 11]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   to all others.  The contents of packets having lower thread numbers
+   shall be considered as having a higher processing and delivery
+   priority than those with higher thread numbers.  Thus, packets having
+   lower thread numbers for a given sync frame shall be delivered first
+   to the decoder under loss-free and low-time-jitter conditions, which
+   will result in the discarding of the sync contents of the higher-
+   numbered threads as specified in Annex N of [H263].
+
+6.  Packetization Schemes
+
+6.1.  Picture Segment Packets and Sequence Ending Packets (P=1)
+
+   A picture segment packet is defined as a packet that starts at the
+   location of a Picture, GOB, or slice start code in the H.263+ data
+   stream.  This corresponds to the definition of the start of a video
+   picture segment as defined in H.263+.  For such packets, P=1 always.
+
+   An extra picture header can sometimes be attached in the payload
+   header of such packets.  Whenever an extra picture header is attached
+   as signified by PLEN>0, only the last six bits of its picture start
+   code, '100000', are included in the payload header.  A complete
+   H.263+ picture header with byte-aligned picture start code can be
+   conveniently assembled on the receiving end by prepending the sixteen
+   leading '0' bits.
+
+   When PLEN>0, the end bit position corresponding to the last byte of
+   the picture header data is indicated by PEBIT.  The actual bitstream
+   data shall begin on an 8-bit byte boundary following the payload
+   header.
+
+   A sequence ending packet is defined as a packet that starts at the
+   location of an EOS or EOSBS code in the H.263+ data stream.  This
+   delineates the end of a sequence of H.263+ video data (more H.263+
+   video data may still follow later, however, as specified in ITU-T
+   Recommendation H.263).  For such packets, P=1 and PLEN=0 always.
+
+   The optional header extension for VRC may or may not be present as
+   indicated by the V bit flag.
+
+6.1.1.  Packets that begin with a Picture Start Code
+
+   Any packet that contains the whole or the start of a coded picture
+   shall start at the location of the picture start code (PSC) and
+   should normally be encapsulated with no extra copy of the picture
+   header.  In other words, normally PLEN=0 in such a case.  However, if
+   the coded picture contains an incomplete picture header (UFEP =
+   "000"), then a representation of the complete (UFEP = "001") picture
+   header may be attached during packetization in order to provide
+
+
+
+Ott, et al.                 Standards Track                    [Page 12]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   greater error resilience.  Thus, for packets that start at the
+   location of a picture start code, PLEN shall be zero unless both of
+   the following conditions apply:
+
+   1) The picture header in the H.263+ bitstream payload is incomplete
+      (PLUSPTYPE present and UFEP="000").
+
+   2) The additional picture header that is attached is not incomplete
+      (UFEP="001").
+
+   A packet that begins at the location of a Picture, GOB, slice, EOS,
+   or EOSBS start code shall omit the first two (all zero) bytes from
+   the H.263+ bitstream and signify their presence by setting P=1 in the
+   payload header.
+
+   Here is an example of encapsulating the first packet in a frame
+   (without an attached redundant complete picture header):
+
+      0                   1                   2                   3
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the    :
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     : first two 0 bytes of the PSC
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+6.1.2.  Packets that begin with GBSC or SSC
+
+   For a packet that begins at the location of a GOB or slice start code
+   (GBSC), PLEN may be zero or nonzero, depending on whether a redundant
+   picture header is attached to the packet.  In environments with very
+   low packet loss rates, or when picture header contents are very
+   seldom likely to change (except as can be detected from the GOB Frame
+   ID (GFID) syntax of H.263+), a redundant copy of the picture header
+   is not required.  However, in less ideal circumstances a redundant
+   picture header should be attached for enhanced error resilience, and
+   its presence is indicated by PLEN>0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 13]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   Assuming a PLEN of 9 and P=1, below is an example of a packet that
+   begins with a byte-aligned GBSC or a Slice Start Code (SSC):
+
+        0                   1                   2                   3
+        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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   RR    |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header    :
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       : starting with TR, PTYPE ...                                   |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | ...                                           | bitstream     :
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       : data starting with GBSC/SSC without its first two 0 bytes
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Notice that only the last six bits of the picture start code,
+   '100000', are included in the payload header.  A complete H.263+
+   picture header with byte aligned picture start code can be
+   conveniently assembled, if needed, on the receiving end by prepending
+   the sixteen leading '0' bits.
+
+6.1.3.  Packets that begin with an EOS or EOSBS Code
+
+   For a packet that begins with an EOS or EOSBS code, PLEN shall be
+   zero, and no Picture, GOB, or Slice start codes shall be included
+   within the same packet.  As with other packets beginning with start
+   codes, the two all-zero bytes that begin the EOS or EOSBS code at the
+   beginning of the packet shall be omitted, and their presence shall be
+   indicated by setting the P bit to 1 in the payload header.
+
+   System designers should be aware that some decoders may interpret the
+   loss of a packet containing only EOS or EOSBS information as the loss
+   of essential video data and may thus respond by not displaying some
+   subsequent video information.  Since EOS and EOSBS codes do not
+   actually affect the decoding of video pictures, they are somewhat
+   unnecessary to send at all.  Because of the danger of
+   misinterpretation of the loss of such a packet (which can be detected
+   by the sequence number), encoders are generally to be discouraged
+   from sending EOS and EOSBS.
+
+   Below is an example of a packet containing an EOS code:
+
+         0                   1                   2
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        |   RR    |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 14]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+6.2.  Encapsulating Follow-on Packet (P=0)
+
+   A Follow-on Packet contains a number of bytes of coded H.263+ data
+   that do not start at a synchronization point.  That is, a Follow-on
+   Packet does not start with a Picture, GOB, Slice, EOS, or EOSBS
+   header, and it may or may not start at a macroblock boundary.  Since
+   Follow-on Packets do not start at synchronization points, the data at
+   the beginning of a Follow-on Packet is not independently decodable.
+   For such packets, P=0 always.  If the preceding packet of a Follow-on
+   Packet got lost, the receiver may discard that Follow-on Packet, as
+   well as all other following Follow-on Packets.  Better behavior, of
+   course, would be for the receiver to scan the interior of the packet
+   payload content to determine whether any start codes are found in the
+   interior of the packet that can be used as resync points.  The use of
+   an attached copy of a picture header for a Follow-on Packet is useful
+   only if the interior of the packet or some subsequent Follow-on
+   Packet contains a resync code, such as a GOB or slice start code.
+   PLEN>0 is allowed, since it may allow resync in the interior of the
+   packet.  The decoder may also be resynchronized at the next segment
+   or picture packet.
+
+   Here is an example of a Follow-on Packet (with PLEN=0):
+
+      0                   1                   2                   3
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+     |   RR    |0|V|0|0|0|0|0|0|0|0|0| bitstream data
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+7.  Use of this Payload Specification
+
+   There is no syntactical difference between a picture segment packet
+   and a Follow-on Packet, other than the indication P=1 for picture
+   segment or sequence ending packets and P=0 for Follow-on Packets.
+   See the following for a summary of the entire packet types and ways
+   to distinguish between them.
+
+   It is possible to distinguish between the different packet types by
+   checking the P bit and the first 6 bits of the payload along with the
+   header information.  The following table shows the packet type for
+   permutations of this information (see also the picture/GOB/Slice
+   header descriptions in H.263+ for details):
+
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 15]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   -------------+--------------+----------------------+----------------
+   First 6 bits | P-Bit | PLEN |  Packet              |  Remarks
+   of Payload   |(payload hdr.)|                      |
+   -------------+--------------+----------------------+----------------
+   100000       |   1   |  0   |  Picture             | Typical Picture
+   100000       |   1   | > 0  |  Picture             | Note UFEP
+   1xxxxx       |   1   |  0   |  GOB/Slice/EOS/EOSBS | See possible GNs
+   1xxxxx       |   1   | > 0  |  GOB/Slice           | See possible GNs
+   Xxxxxx       |   0   |  0   |  Follow-on           |
+   Xxxxxx       |   0   | > 0  |  Follow-on           | Interior Resync
+   -------------+--------------+----------------------+----------------
+
+   The details regarding the possible values of the five bit Group
+   Number (GN) field that follows the initial "1" bit when the P-bit is
+   "1" for a GOB, Slice, EOS, or EOSBS packet are found in Section 5.2.3
+   of H.263 [H263].
+
+   As defined in this specification, every start of a coded frame (as
+   indicated by the presence of a PSC) has to be encapsulated as a
+   picture segment packet.  If the whole coded picture fits into one
+   packet of reasonable size (which is dependent on the connection
+   characteristics), this is the only type of packet that may need to be
+   used.  Due to the high compression ratio achieved by H.263+, it is
+   often possible to use this mechanism, especially for small spatial
+   picture formats such as Quarter Common Intermediate Format (QCIF) and
+   typical Internet packet sizes around 1500 bytes.
+
+   If the complete coded frame does not fit into a single packet, two
+   different ways for the packetization may be chosen.  In case of very
+   low or zero packet loss probability, one or more Follow-on Packets
+   may be used for coding the rest of the picture.  Doing so leads to
+   minimal coding and packetization overhead, as well as to an optimal
+   use of the maximal packet size, but does not provide any added error
+   resilience.
+
+   The alternative is to break the picture into reasonably small
+   partitions, called Segments (by using the Slice or GOB mechanism),
+   that do offer synchronization points.  By doing so and using the
+   Picture Segment payload with PLEN>0, decoding of the transmitted
+   packets is possible even in cases in which the Picture packet
+   containing the picture header was lost (provided any necessary
+   reference picture is available).  Picture Segment packets can also be
+   used in conjunction with Follow-on Packets for large segment sizes.
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 16]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+8.  Media Type Definition
+
+   This section specifies optional parameters that MAY be used to select
+   optional features of the H.263 codec.  The parameters are specified
+   here as part of the Media Type registration for the ITU-T H.263
+   codec.  A mapping of the parameters into the Session Description
+   Protocol (SDP) [RFC4566] is also provided for applications that use
+   SDP.  Multiple parameters SHOULD be expressed as a media type string,
+   in the form of a semicolon-separated list of parameter=value pairs.
+
+8.1.  Media Type Registrations
+
+   This section describes the media types and names associated with this
+   payload format.  The section updates the previous registered version
+   in RFC 3555 [RFC3555].
+
+8.1.1.  Registration of Media Type video/H263-1998
+
+   Type name: video
+
+   Subtype name: H263-1998
+
+   Required parameters: None
+
+   Optional parameters:
+
+      SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF
+      resolution.  Permissible values are integer values from 1 to 32,
+      which correspond to a maximum frame rate of 30/(1.001 * the
+      specified value) frames per second.
+
+      QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF
+      resolution.  Permissible values are integer values from 1 to 32,
+      which correspond to a maximum frame rate of 30/(1.001 * the
+      specified value) frames per second.
+
+      CIF: Specifies the MPI (Minimum Picture Interval) for CIF
+      resolution.  Permissible values are integer values from 1 to 32,
+      which correspond to a maximum frame rate of 30/(1.001 * the
+      specified value) frames per second.
+
+      CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF
+      resolution.  Permissible values are integer values from 1 to 32,
+      which correspond to a maximum frame rate of 30/(1.001 * the
+      specified value) frames per second.
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 17]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+      CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF
+      resolution.  Permissible values are integer values from 1 to 32,
+      which correspond to a maximum frame rate of 30/(1.001 * the
+      specified value) frames per second.
+
+      CUSTOM: Specifies the MPI (Minimum Picture Interval) for a
+      custom-defined resolution.  The custom parameter receives three
+      comma-separated values, Xmax, Ymax, and MPI.  The Xmax and Ymax
+      parameters describe the number of pixels in the X and Y axis and
+      must be evenly divisible by 4.  The permissible values for MPI are
+      integer values from 1 to 32, which correspond to a maximum frame
+      rate of 30/(1.001 *the specified value).
+
+      A system that declares support of a specific MPI for one of the
+      resolutions SHALL also implicitly support a lower resolution with
+      the same MPI.
+
+      A list of optional annexes specifies which annexes of H.263 are
+      supported.  The optional annexes are defined as part of H263-1998,
+      H263-2000.  H.263 annex X [H263] defines profiles that group
+      annexes for specific applications.  A system that supports a
+      specific annex SHALL specify its support using the optional
+      parameters.  If no annex is specified, then the stream is Baseline
+      H.263.
+
+      The allowed optional parameters for the annexes are "F", "I", "J",
+      "T", "K", "N", and "P".
+
+      "F", "I", "J", and "T" if supported, SHALL have the value "1".  If
+      not supported, they should not be listed or SHALL have the value
+      "0".
+
+      "K" can receive one of four values 1 - 4:
+
+      1: Slices In Order, Non-Rectangular
+
+      2: Slices In Order, Rectangular
+
+      3: Slices Not Ordered, Non-Rectangular
+
+      4: Slices Not Ordered, Rectangular
+
+      "N": Reference Picture Selection mode -  Four numeric choices
+      (1 - 4) are available, representing the following modes:
+
+      1: NEITHER:  No back-channel data is returned from the decoder to
+         the encoder.
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 18]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+      2: ACK:  The decoder returns only acknowledgment messages.
+
+      3: NACK:  The decoder returns only non-acknowledgment messages.
+
+      4: ACK+NACK:  The decoder returns both acknowledgment and non-
+         acknowledgment messages.
+
+      No special provision is made herein for carrying back channel
+      information.  The Extended RTP Profile for RTCP-based Feedback
+      [RFC4585] MAY be used as a back channel mechanism.
+
+      "P": Reference Picture Resampling, in which the following submodes
+      are represented as a number from 1 to 4:
+
+      1: dynamicPictureResizingByFour
+
+      2: dynamicPictureResizingBySixteenthPel
+
+      3: dynamicWarpingHalfPel
+
+      4: dynamicWarpingSixteenthPel
+
+      Example: P=1,3
+
+      PAR: Arbitrary Pixel Aspect Ratio.  Defines the width:height ratio
+      by two colon-separated integers between 0 and 255.  Default ratio
+      is 12:11, if not otherwise specified.
+
+      CPCF: Arbitrary (Custom) Picture Clock Frequency: CPCF is a
+      comma-separated list of eight parameters specifying a custom
+      picture clock frequency and the MPI (minimum picture interval) for
+      the supported picture sizes when using that picture clock
+      frequency.  The first two parameters are cd, which is an integer
+      from 1 to 127, and cf, which is either 1000 or 1001.  The custom
+      picture clock frequency is given by the formula 1800000/(cd*cf)
+      provided in the RTP Timestamp semantics in Section 3.1 above (as
+      specified in H.263 section 5.1.7).  Following the values of cd and
+      cf, the remaining six parameters are SQCIFMPI, QCIFMPI, CIFMPI,
+      CIF4MPI, CIF16MPI, and CUSTOMMPI, which each specify an integer
+      MPI (minimum picture interval) for the standard picture sizes
+      SQCIF, QCIF, CIF, 4CIF, 16CIF, and CUSTOM, respectively, as
+      described above.  The MPI value indicates a maximum frame rate of
+      1800000/(cd*cf*MPI) frames per second for MPI parameters having a
+      value in the range from 1 to 2048, inclusive.  An MPI value of 0
+      specifies that the associated picture size is not supported for
+      the custom picture clock frequency.  If the CUSTOMMPI parameter is
+      not equal to 0, the CUSTOM parameter SHALL also be present (so
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 19]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+      that the Xmax and Ymax dimensions of the custom picture size are
+      defined).
+
+      BPP: BitsPerPictureMaxKb.  Maximum number of bits in units of 1024
+      bits allowed to represent a single picture.  If this parameter is
+      not present, then the default value, based on the maximum
+      supported resolution, is used.  BPP is integer value between 0 and
+      65536.
+
+      HRD: Hypothetical Reference Decoder.  See annex B of H.263
+      specification [H263].  This parameter, if supported, SHALL have
+      the value "1".  If not supported, it should not be listed or SHALL
+      have the value "0".
+
+   Encoding considerations:
+
+      This media type is framed and binary; see Section 4.8 in [RFC4288]
+
+   Security considerations: See Section 11 of RFC 4629
+
+   Interoperability considerations:
+
+      These are receiver options; current implementations will not send
+      any optional parameters in their SDP.  They will ignore the
+      optional parameters and will encode the H.263 stream without any
+      of the annexes.  Most decoders support at least QCIF and CIF fixed
+      resolutions, and they are expected to be available almost in every
+      H.263-based video application.
+
+   Published specification: RFC 4629
+
+   Applications that use this media type:
+
+      Audio and video streaming and conferencing tools.
+
+      Additional information: None
+
+      Person and email address to contact for further information:
+
+   Roni Even: roni.even@polycom.co.il
+
+      Intended usage: COMMON
+
+      Restrictions on usage:
+
+      This media type depends on RTP framing and thus is only defined
+      for transfer via RTP [RFC3550].  Transport within other framing
+      protocols is not defined at this time.
+
+
+
+Ott, et al.                 Standards Track                    [Page 20]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   Author: Roni Even
+
+   Change controller:
+
+      IETF Audio/Video Transport working group, delegated from the IESG.
+
+8.1.2.  Registration of Media Type video/H263-2000
+
+   Type name: video
+
+   Subtype name: H263-2000
+
+   Required parameters: None
+
+   Optional parameters:
+
+      The optional parameters of the H263-1998 type MAY be used with
+      this media subtype.  Specific optional parameters that may be used
+      with the H263-2000 type are as follows:
+
+      PROFILE:  H.263 profile number, in the range 0 through 10,
+      specifying the supported H.263 annexes/subparts based on H.263
+      annex X [H263].  The annexes supported in each profile are listed
+      in table X.1 of H.263 annex X.  If no profile or H.263 annex is
+      specified, then the stream is Baseline H.263 (profile 0 of H.263
+      annex X).
+
+      LEVEL:  Level of bitstream operation, in the range 0 through 100,
+      specifying the level of computational complexity of the decoding
+      process.  The level are described in table X.2 of H.263 annex X.
+
+      According to H.263 annex X, support of any level other than level
+      45 implies support of all lower levels.  Support of level 45
+      implies support of level 10.
+
+      A system that specifies support of a PROFILE MUST specify the
+      supported LEVEL.
+
+      INTERLACE:  Interlaced or 60 fields indicates the support for
+      interlace display mode, as specified in H.263 annex W.6.3.11.
+      This parameter, if supported SHALL have the value "1".  If not
+      supported, it should not be listed or SHALL have the value "0".
+
+   Encoding considerations:
+
+      This media type is framed and binary; see Section 4.8 in [RFC4288]
+
+   Security considerations: See Section 11 of RFC 4629
+
+
+
+Ott, et al.                 Standards Track                    [Page 21]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   Interoperability considerations:
+
+      The optional parameters PROFILE and LEVEL SHALL NOT be used with
+      any of the other optional parameters.
+
+   Published specification: RFC 4629
+
+   Applications that use this media type:
+
+      Audio and video streaming and conferencing tools.
+
+   Additional information: None
+
+   Person and email address to contact for further information :
+
+      Roni Even: roni.even@polycom.co.il
+
+   Intended usage: COMMON
+
+   Restrictions on usage:
+
+      This media type depends on RTP framing and thus is only defined
+      for transfer via RTP [RFC3550].  Transport within other framing
+      protocols is not defined at this time.
+
+   Author: Roni Even
+
+   Change controller:
+
+      IETF Audio/Video Transport working group delegated from the IESG.
+
+8.2.  SDP Usage
+
+   The media types video/H263-1998 and video/H263-2000 are mapped to
+   fields in the Session Description Protocol (SDP) as follows:
+
+   o The media name in the "m=" line of SDP MUST be video.
+
+   o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998
+     or H263-2000 (the media subtype).
+
+   o The clock rate in the "a=rtpmap" line MUST be 90000.
+
+   o The optional parameters, if any, MUST be included in the "a=fmtp"
+     line of SDP.  These parameters are expressed as a media type
+     string, in the form of a semicolon-separated list of
+     parameter=value pairs.  The optional parameters PROFILE and LEVEL
+     SHALL NOT be used with any of the other optional parameters.
+
+
+
+Ott, et al.                 Standards Track                    [Page 22]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+8.2.1.  Usage with the SDP Offer Answer Model
+
+   For offering H.263 over RTP using SDP in an Offer/Answer model
+   [RFC3264], the following considerations are necessary.
+
+   Codec options (F,I,J,K,N,P,T): These options MUST NOT appear unless
+   the sender of these SDP parameters is able to decode those options.
+   These options designate receiver capabilities even when sent in a
+   "sendonly" offer.
+
+   Profile: The offer of a SDP profile parameter signals that the
+   offerer can decode a stream that uses the specified profile.  Each
+   profile uses different H.263 annexes, so there is no implied
+   relationship between them.  An answerer SHALL NOT change the profile
+   parameter and MUST reject the payload type containing an unsupported
+   profile.  A decoder that supports a profile SHALL also support H.263
+   baseline profile (profile 0).  An offerer is RECOMMENDED to offer all
+   the different profiles it is interested to use as individual payload
+   types.  In addition an offerer, sending an offer using the PROFILE
+   optional parameter, is RECOMMENDED to offer profile 0, as this will
+   enable communication, and in addition allows an answerer to add those
+   profiles it does support in an answer.
+
+   LEVEL: The LEVEL parameter in an offer indicates the maximum
+   computational complexity supported by the offerer in performing
+   decoding for the given PROFILE.  An answerer MAY change the value
+   (both up and down) of the LEVEL parameter in its answer to indicate
+   the highest value it supports.
+
+   INTERLACE: The parameter MAY be included in either offer or answer to
+   indicate that the offerer or answerer respectively supports reception
+   of interlaced content.  The inclusion in either offer or answer is
+   independent of each other.
+
+   Picture sizes and MPI: Supported picture sizes and their
+   corresponding minimum picture interval (MPI) information for H.263
+   can be combined.  All picture sizes can be advertised to the other
+   party, or only a subset.  The terminal announces only those picture
+   sizes (with their MPIs) which it is willing to receive.  For example,
+   MPI=2 means that the maximum (decodable) picture rate per second is
+   15/1.001 (approximately 14.985).
+
+   If the receiver does not specify the picture size/MPI optional
+   parameter, then it SHOULD be ready to receive QCIF resolution with
+   MPI=1.
+
+   Parameters offered first are the most preferred picture mode to be
+   received.
+
+
+
+Ott, et al.                 Standards Track                    [Page 23]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   Here is an example of the usage of these parameters:
+
+      CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2
+
+   This means that the encoder SHOULD send CIF picture size, which it
+   can decode at MPI=4.  If that is not possible, then QCIF with MPI
+   value 3 should be sent; if neither are possible, then SQCIF with MPI
+   value=2.  The receiver is capable of (but least preferred) decoding
+   custom picture sizes (max 360x240) with MPI=2.  Note that most
+   decoders support at least QCIF and CIF fixed resolutions, and that
+   they are expected to be available almost in every H.263-based video
+   application.
+
+   Below is an example of H.263 SDP in an offer:
+
+      a=fmtp:xx CIF=4;QCIF=2;F=1;K=1
+
+   This means that the sender of this message can decode an H.263 bit
+   stream with the following options and parameters: preferred
+   resolution is CIF (at up to 30/4.004 frames per second), but if that
+   is not possible then QCIF size is also supported (at up to 30/2.002
+   frames per second).  Advanced Prediction mode (AP) and
+   slicesInOrder-NonRect options MAY be used.
+
+   Below is an example of H.263 SDP in an offer that includes the CPCF
+   parameter.
+
+      a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1
+
+   This means that the sender of this message can decode an H.263 bit
+   stream with a preferred custom picture size of 640x480 at a maximum
+   frame rate of 25 frames per second using a custom picture clock
+   frequency of 50 Hz.  If that is not possible, then the 640x480
+   picture size is also supported at up to 30/2.002 frames per second
+   using the ordinary picture clock frequency of 30/1.001 Hz.  If
+   neither of those is possible, then the CIF and QCIF picture sizes are
+   also supported at up to 50 frames per second using the custom picture
+   clock frequency of 50 Hz or up to 30/1.001 frames per second using
+   the ordinary picture clock frequency of 30/1.001 Hz, and CIF is
+   preferred over QCIF.
+
+   The following limitation applies for usage of these media types when
+   performing offer/answer for sessions using multicast transport.  An
+   answerer SHALL NOT change any of the parameters in an answer, instead
+   if the indicated values are not supported the payload type MUST be
+   rejected.
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 24]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+9.  Backward Compatibility to RFC 2429
+
+   The current document is a revision of RFC 2429 and obsoletes it.
+   This section will address the backward compatibility issues.
+
+9.1.  New Optional Parameters for SDP
+
+   The document adds new optional parameters to the H263-1998 and H263-
+   2000 payload type, defined in RFC 3555 [RFC3555].  Since these are
+   optional parameters we expect that old implementations will ignore
+   these parameters, and that new implementations that will receive the
+   H263-1998 and H263-2000 payload types with no parameters will behave
+   as if the other side can accept H.263 at QCIF resolution at a frame
+   rate not exceeding 15/1.001 (approximately 14.985) frames per second.
+
+10.  IANA Considerations
+
+   This document updates the H.263 (1998) and H.263 (2000) media types,
+   described in RFC 3555 [RFC3555].  The updated media type
+   registrations are in Section 8.1.
+
+11.  Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [RFC3550] and any appropriate RTP profile (for example,
+   [RFC3551]).  This implies that confidentiality of the media streams
+   is achieved by encryption.  Because the data compression used with
+   this payload format is applied end-to-end, encryption may be
+   performed after compression, so there is no conflict between the two
+   operations.
+
+   A potential denial-of-service threat exists for data encoding using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the stream that are complex to decode and cause the receiver to
+   be overloaded.  The usage of authentication of at least the RTP
+   packet is RECOMMENDED.
+
+   As with any IP-based protocol, in some circumstances a receiver may
+   be overloaded simply by the receipt of too many packets, either
+   desired or undesired.  Network-layer authentication may be used to
+   discard packets from undesired sources, but the processing cost of
+   the authentication itself may be too high.  In a multicast
+   environment, pruning of specific sources may be implemented in future
+   versions of IGMP [RFC2032] and in multicast routing protocols to
+   allow a receiver to select which sources are allowed to reach it.
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 25]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   A security review of this payload format found no additional
+   considerations beyond those in the RTP specification.
+
+12.  Acknowledgements
+
+   This is to acknowledge the work done by Chad Zhu, Linda Cline, Gim
+   Deisher, Tom Gardos, Christian Maciocco, and Donald Newell from Intel
+   Corp., who co-authored RFC 2429.
+
+   We would also like to acknowledge the work of Petri Koskelainen from
+   Nokia and Nermeen Ismail from Cisco, who helped with composing the
+   text for the new media types.
+
+13.  Changes from Previous Versions of the Documents
+
+13.1.  Changes from RFC 2429
+
+   The changes from the RFC 2429 are:
+
+   1.  The H.263 1998 and 2000 media type are now in the payload
+       specification.
+
+   2.  Added optional parameters to the H.263 1998 and 2000 media types.
+
+   3.  Mandate the usage of RFC 2429 for all H.263.  RFC 2190 payload
+       format should be used only to interact with legacy systems.
+
+13.2.  Changes from RFC 3555
+
+   This document adds new optional parameters to the H263-1998 and
+   H263-2000 payload types.
+
+14.  References
+
+14.1.  Normative References
+
+   [H263]     International Telecommunications Union - Telecommunication
+              Standardization Sector, "Video coding for low bit rate
+              communication", ITU-T Recommendation H.263, January 2005.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 26]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+              Video Conferences with Minimal Control", STD 65, RFC 3551,
+              July 2003.
+
+   [RFC3555]  Casner, S. and P. Hoschka, "MIME Type Registration of RTP
+              Payload Formats", RFC 3555, July 2003.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+14.2.  Informative References
+
+   [RFC2032]  Turletti, T., "RTP Payload Format for H.261 Video
+              Streams", RFC 2032, October 1996.
+
+   [RFC2190]  Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC
+              2190, September 1997.
+
+   [RFC2429]  Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco,
+              C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C.
+              Zhu, "RTP Payload Format for the 1998 Version of ITU-T
+              Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264, June
+              2002.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
+              "Extended RTP Profile for Real-time Transport Control
+              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
+              2006.
+
+   [RFC4628]  Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to
+              Historic Status", RFC 4628, January 2007.
+
+   [Vredun]   Wenger, S., "Video Redundancy Coding in H.263+", Proc.
+              Audio-Visual Services over Packet Networks, Aberdeen, U.K.
+              9/1997, September 1997.
+
+
+
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 27]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+Authors' Addresses
+
+   Joerg Ott
+   Helsinki University of Technology
+   Networking Laboratory
+   PO Box 3000
+   02015 TKK, Finland
+
+   EMail: jo@netlab.tkk.fi
+
+
+   Carsten Bormann
+   Universitaet Bremen TZI
+   Postfach 330440
+   D-28334 Bremen, GERMANY
+
+   Phone: +49.421.218-7024
+   Fax: +49.421.218-7000
+   EMail: cabo@tzi.org
+
+
+   Gary Sullivan
+   Microsoft Corp.
+   One Microsoft Way
+   Redmond, WA 98052
+   USA
+
+   EMail: garysull@microsoft.com
+
+
+   Stephan Wenger
+   Nokia Research Center
+   P.O. Box 100
+   33721 Tampere
+   Finland
+
+   EMail: stewe@stewe.org
+
+
+   Roni Even (editor)
+   Polycom
+   94 Derech Em Hamoshavot
+   Petach Tikva  49130
+   Israel
+
+   EMail: roni.even@polycom.co.il
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 28]
+
+RFC 4629                H.263 RTP Payload Format            January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Ott, et al.                 Standards Track                    [Page 29]
+