rfc3551.txt

完整的RTP RTSP代码库

      unicast and multicast UDP as well as TCP.  (This does not preclude
      the use of these definitions when RTP is carried by other lower-
      layer protocols.)

   Transport mapping: The standard mapping of RTP and RTCP to
      transport-level addresses is used.

   Encapsulation: This profile leaves to applications the
      specification of RTP encapsulation in protocols other than UDP.

3.  Registering Additional Encodings

   This profile lists a set of encodings, each of which is comprised of
   a particular media data compression or representation plus a payload
   format for encapsulation within RTP.  Some of those payload formats
   are specified here, while others are specified in separate RFCs.  It
   is expected that additional encodings beyond the set listed here will
   be created in the future and specified in additional payload format
   RFCs.

   This profile also assigns to each encoding a short name which MAY be
   used by higher-level control protocols, such as the Session
   Description Protocol (SDP), RFC 2327 [6], to identify encodings
   selected for a particular RTP session.

   In some contexts it may be useful to refer to these encodings in the
   form of a MIME content-type.  To facilitate this, RFC 3555 [7]
   provides registrations for all of the encodings names listed here as
   MIME subtype names under the "audio" and "video" MIME types through
   the MIME registration procedure as specified in RFC 2048 [8].

   Any additional encodings specified for use under this profile (or
   others) may also be assigned names registered as MIME subtypes with
   the Internet Assigned Numbers Authority (IANA).  This registry
   provides a means to insure that the names assigned to the additional
   encodings are kept unique.  RFC 3555 specifies the information that
   is required for the registration of RTP encodings.

   In addition to assigning names to encodings, this profile also
   assigns static RTP payload type numbers to some of them.  However,
   the payload type number space is relatively small and cannot
   accommodate assignments for all existing and future encodings.
   During the early stages of RTP development, it was necessary to use
   statically assigned payload types because no other mechanism had been
   specified to bind encodings to payload types.  It was anticipated
   that non-RTP means beyond the scope of this memo (such as directory
   services or invitation protocols) would be specified to establish a



Schulzrinne & Casner        Standards Track                     [Page 6]

RFC 3551                    RTP A/V Profile                    July 2003


   dynamic mapping between a payload type and an encoding.  Now,
   mechanisms for defining dynamic payload type bindings have been
   specified in the Session Description Protocol (SDP) and in other
   protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
   associate the registered name of the encoding/payload format, along
   with any additional required parameters, such as the RTP timestamp
   clock rate and number of channels, with a payload type number.  This
   association is effective only for the duration of the RTP session in
   which the dynamic payload type binding is made.  This association
   applies only to the RTP session for which it is made, thus the
   numbers can be re-used for different encodings in different sessions
   so the number space limitation is avoided.

   This profile reserves payload type numbers in the range 96-127
   exclusively for dynamic assignment.  Applications SHOULD first use
   values in this range for dynamic payload types.  Those applications
   which need to define more than 32 dynamic payload types MAY bind
   codes below 96, in which case it is RECOMMENDED that unassigned
   payload type numbers be used first.  However, the statically assigned
   payload types are default bindings and MAY be dynamically bound to
   new encodings if needed.  Redefining payload types below 96 may cause
   incorrect operation if an attempt is made to join a session without
   obtaining session description information that defines the dynamic
   payload types.

   Dynamic payload types SHOULD NOT be used without a well-defined
   mechanism to indicate the mapping.  Systems that expect to
   interoperate with others operating under this profile SHOULD NOT make
   their own assignments of proprietary encodings to particular, fixed
   payload types.

   This specification establishes the policy that no additional static
   payload types will be assigned beyond the ones defined in this
   document.  Establishing this policy avoids the problem of trying to
   create a set of criteria for accepting static assignments and
   encourages the implementation and deployment of the dynamic payload
   type mechanisms.

   The final set of static payload type assignments is provided in
   Tables 4 and 5.











Schulzrinne & Casner        Standards Track                     [Page 7]

RFC 3551                    RTP A/V Profile                    July 2003


4.  Audio

4.1  Encoding-Independent Rules

   Since the ability to suppress silence is one of the primary
   motivations for using packets to transmit voice, the RTP header
   carries both a sequence number and a timestamp to allow a receiver to
   distinguish between lost packets and periods of time when no data was
   transmitted.  Discontiguous transmission (silence suppression) MAY be
   used with any audio payload format.  Receivers MUST assume that
   senders may suppress silence unless this is restricted by signaling
   specified elsewhere.  (Even if the transmitter does not suppress
   silence, the receiver should be prepared to handle periods when no
   data is present since packets may be lost.)

   Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence
   insertion descriptor" or "comfort noise" frame to specify parameters
   for artificial noise that may be generated during a period of silence
   to approximate the background noise at the source.  For other payload
   formats, a generic Comfort Noise (CN) payload format is specified in
   RFC 3389 [9].  When the CN payload format is used with another
   payload format, different values in the RTP payload type field
   distinguish comfort-noise packets from those of the selected payload
   format.

   For applications which send either no packets or occasional comfort-
   noise packets during silence, the first packet of a talkspurt, that
   is, the first packet after a silence period during which packets have
   not been transmitted contiguously, SHOULD be distinguished by setting
   the marker bit in the RTP data header to one.  The marker bit in all
   other packets is zero.  The beginning of a talkspurt MAY be used to
   adjust the playout delay to reflect changing network delays.
   Applications without silence suppression MUST set the marker bit to
   zero.

   The RTP clock rate used for generating the RTP timestamp is
   independent of the number of channels and the encoding; it usually
   equals the number of sampling periods per second.  For N-channel
   encodings, each sampling period (say, 1/8,000 of a second) generates
   N samples.  (This terminology is standard, but somewhat confusing, as
   the total number of samples generated per second is then the sampling
   rate times the channel count.)

   If multiple audio channels are used, channels are numbered left-to-
   right, starting at one.  In RTP audio packets, information from
   lower-numbered channels precedes that from higher-numbered channels.





Schulzrinne & Casner        Standards Track                     [Page 8]

RFC 3551                    RTP A/V Profile                    July 2003


   For more than two channels, the convention followed by the AIFF-C
   audio interchange format SHOULD be followed [3], using the following
   notation, unless some other convention is specified for a particular
   encoding or payload format:

      l  left
      r  right
      c  center
      S  surround
      F  front
      R  rear

      channels  description  channel
                                1     2   3   4   5   6
      _________________________________________________
      2         stereo          l     r
      3                         l     r   c
      4                         l     c   r   S
      5                        Fl     Fr  Fc  Sl  Sr
      6                         l     lc  c   r   rc  S

         Note: RFC 1890 defined two conventions for the ordering of four
         audio channels.  Since the ordering is indicated implicitly by
         the number of channels, this was ambiguous.  In this revision,
         the order described as "quadrophonic" has been eliminated to
         remove the ambiguity.  This choice was based on the observation
         that quadrophonic consumer audio format did not become popular
         whereas surround-sound subsequently has.

   Samples for all channels belonging to a single sampling instant MUST
   be within the same packet.  The interleaving of samples from
   different channels depends on the encoding.  General guidelines are
   given in Section 4.3 and 4.4.

   The sampling frequency SHOULD be drawn from the set:  8,000, 11,025,
   16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz.  (Older Apple
   Macintosh computers had a native sample rate of 22,254.54 Hz, which
   can be converted to 22,050 with acceptable quality by dropping 4
   samples in a 20 ms frame.)  However, most audio encodings are defined
   for a more restricted set of sampling frequencies.  Receivers SHOULD
   be prepared to accept multi-channel audio, but MAY choose to only
   play a single channel.

4.2  Operating Recommendations

   The following recommendations are default operating parameters.
   Applications SHOULD be prepared to handle other values.  The ranges
   given are meant to give guidance to application writers, allowing a



Schulzrinne & Casner        Standards Track                     [Page 9]

RFC 3551                    RTP A/V Profile                    July 2003


   set of applications conforming to these guidelines to interoperate
   without additional negotiation.  These guidelines are not intended to
   restrict operating parameters for applications that can negotiate a
   set of interoperable parameters, e.g., through a conference control
   protocol.

   For packetized audio, the default packetization interval SHOULD have
   a duration of 20 ms or one frame, whichever is longer, unless
   otherwise noted in Table 1 (column "ms/packet").  The packetization
   interval determines the minimum end-to-end delay; longer packets
   introduce less header overhead but higher delay and make packet loss
   more noticeable.  For non-interactive applications such as lectures
   or for links with severe bandwidth constraints, a higher
   packetization delay MAY be used.  A receiver SHOULD accept packets
   representing between 0 and 200 ms of audio data.  (For framed audio
   encodings, a receiver SHOULD accept packets with a number of frames
   equal to 200 ms divided by the frame duration, rounded up.)  This
   restriction allows reasonable buffer sizing for the receiver.

4.3  Guidelines for Sample-Based Audio Encodings

   In sample-based encodings, each audio sample is represented by a
   fixed number of bits.  Within the compressed audio data, codes for
   individual samples may span octet boundaries.  An RTP audio packet
   may contain any number of audio samples, subject to the constraint
   that the number of bits per sample times the number of samples per
   packet yields an integral octet count.  Fractional encodings produce
   less than one octet per sample.

   The duration of an audio packet is determined by the number of
   samples in the packet.

   For sample-based encodings producing one or more octets per sample,
   samples from different channels sampled at the same sampling instant
   SHOULD be packed in consecutive octets.  For example, for a two-
   channel encoding, the octet sequence is (left channel, first sample),
   (right channel, first sample), (left channel, second sample), (right
   channel, second sample), ....  For multi-octet encodings, octets
   SHOULD be transmitted in network byte order (i.e., most significant
   octet first).

   The packing of sample-based encodings producing less than one octet
   per sample is encoding-specific.

   The RTP timestamp reflects the instant at which the first sample in
   the packet was sampled, that is, the oldest information in the
   packet.




Schulzrinne & Casner        Standards Track                    [Page 10]

RFC 3551                    RTP A/V Profile                    July 2003


4.4  Guidelines for Frame-Based Audio Encodings

   Frame-based encodings encode a fixed-length block of audio into
   another block of compressed data, typically also of fixed length.
   For frame-based encodings, the sender MAY choose to combine several
   such frames into a single RTP packet.  The receiver can tell the
   number of frames contained in an RTP packet, if all the frames have
   the same length, by dividing the RTP payload length by the audio