rfc3550.txt

完整的RTP RTSP代码库

   Synchronization source (SSRC): The source of a stream of RTP
      packets, identified by a 32-bit numeric SSRC identifier carried in
      the RTP header so as not to be dependent upon the network address.
      All packets from a synchronization source form part of the same
      timing and sequence number space, so a receiver groups packets by
      synchronization source for playback.  Examples of synchronization
      sources include the sender of a stream of packets derived from a
      signal source such as a microphone or a camera, or an RTP mixer
      (see below).  A synchronization source may change its data format,
      e.g., audio encoding, over time.  The SSRC identifier is a
      randomly chosen value meant to be globally unique within a
      particular RTP session (see Section 8).  A participant need not
      use the same SSRC identifier for all the RTP sessions in a
      multimedia session; the binding of the SSRC identifiers is
      provided through RTCP (see Section 6.5.1).  If a participant
      generates multiple streams in one RTP session, for example from
      separate video cameras, each MUST be identified as a different
      SSRC.

   Contributing source (CSRC): A source of a stream of RTP packets
      that has contributed to the combined stream produced by an RTP
      mixer (see below).  The mixer inserts a list of the SSRC
      identifiers of the sources that contributed to the generation of a
      particular packet into the RTP header of that packet.  This list
      is called the CSRC list.  An example application is audio
      conferencing where a mixer indicates all the talkers whose speech



Schulzrinne, et al.         Standards Track                    [Page 10]

RFC 3550                          RTP                          July 2003


      was combined to produce the outgoing packet, allowing the receiver
      to indicate the current talker, even though all the audio packets
      contain the same SSRC identifier (that of the mixer).

   End system: An application that generates the content to be sent
      in RTP packets and/or consumes the content of received RTP
      packets.  An end system can act as one or more synchronization
      sources in a particular RTP session, but typically only one.

   Mixer: An intermediate system that receives RTP packets from one
      or more sources, possibly changes the data format, combines the
      packets in some manner and then forwards a new RTP packet.  Since
      the timing among multiple input sources will not generally be
      synchronized, the mixer will make timing adjustments among the
      streams and generate its own timing for the combined stream.
      Thus, all data packets originating from a mixer will be identified
      as having the mixer as their synchronization source.

   Translator: An intermediate system that forwards RTP packets
      with their synchronization source identifier intact.  Examples of
      translators include devices that convert encodings without mixing,
      replicators from multicast to unicast, and application-level
      filters in firewalls.

   Monitor: An application that receives RTCP packets sent by
      participants in an RTP session, in particular the reception
      reports, and estimates the current quality of service for
      distribution monitoring, fault diagnosis and long-term statistics.
      The monitor function is likely to be built into the application(s)
      participating in the session, but may also be a separate
      application that does not otherwise participate and does not send
      or receive the RTP data packets (since they are on a separate
      port).  These are called third-party monitors.  It is also
      acceptable for a third-party monitor to receive the RTP data
      packets but not send RTCP packets or otherwise be counted in the
      session.

   Non-RTP means: Protocols and mechanisms that may be needed in
      addition to RTP to provide a usable service.  In particular, for
      multimedia conferences, a control protocol may distribute
      multicast addresses and keys for encryption, negotiate the
      encryption algorithm to be used, and define dynamic mappings
      between RTP payload type values and the payload formats they
      represent for formats that do not have a predefined payload type
      value.  Examples of such protocols include the Session Initiation
      Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and
      applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326
      [16]).  For simple



Schulzrinne, et al.         Standards Track                    [Page 11]

RFC 3550                          RTP                          July 2003


      applications, electronic mail or a conference database may also be
      used.  The specification of such protocols and mechanisms is
      outside the scope of this document.

4. Byte Order, Alignment, and Time Format

   All integer fields are carried in network byte order, that is, most
   significant byte (octet) first.  This byte order is commonly known as
   big-endian.  The transmission order is described in detail in [3].
   Unless otherwise noted, numeric constants are in decimal (base 10).

   All header data is aligned to its natural length, i.e., 16-bit fields
   are aligned on even offsets, 32-bit fields are aligned at offsets
   divisible by four, etc.  Octets designated as padding have the value
   zero.

   Wallclock time (absolute date and time) is represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds relative to 0h UTC on 1 January 1900 [4].  The full
   resolution NTP timestamp is a 64-bit unsigned fixed-point number with
   the integer part in the first 32 bits and the fractional part in the
   last 32 bits.  In some fields where a more compact representation is
   appropriate, only the middle 32 bits are used; that is, the low 16
   bits of the integer part and the high 16 bits of the fractional part.
   The high 16 bits of the integer part must be determined
   independently.

   An implementation is not required to run the Network Time Protocol in
   order to use RTP.  Other time sources, or none at all, may be used
   (see the description of the NTP timestamp field in Section 6.4.1).
   However, running NTP may be useful for synchronizing streams
   transmitted from separate hosts.

   The NTP timestamp will wrap around to zero some time in the year
   2036, but for RTP purposes, only differences between pairs of NTP
   timestamps are used.  So long as the pairs of timestamps can be
   assumed to be within 68 years of each other, using modular arithmetic
   for subtractions and comparisons makes the wraparound irrelevant.













Schulzrinne, et al.         Standards Track                    [Page 12]

RFC 3550                          RTP                          July 2003


5. RTP Data Transfer Protocol

5.1 RTP Fixed Header Fields

   The RTP header has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first twelve octets are present in every RTP packet, while the
   list of CSRC identifiers is present only when inserted by a mixer.
   The fields have the following meaning:

   version (V): 2 bits
      This field identifies the version of RTP.  The version defined by
      this specification is two (2).  (The value 1 is used by the first
      draft version of RTP and the value 0 is used by the protocol
      initially implemented in the "vat" audio tool.)

   padding (P): 1 bit
      If the padding bit is set, the packet contains one or more
      additional padding octets at the end which are not part of the
      payload.  The last octet of the padding contains a count of how
      many padding octets should be ignored, including itself.  Padding
      may be needed by some encryption algorithms with fixed block sizes
      or for carrying several RTP packets in a lower-layer protocol data
      unit.

   extension (X): 1 bit
      If the extension bit is set, the fixed header MUST be followed by
      exactly one header extension, with a format defined in Section
      5.3.1.

   CSRC count (CC): 4 bits
      The CSRC count contains the number of CSRC identifiers that follow
      the fixed header.





Schulzrinne, et al.         Standards Track                    [Page 13]

RFC 3550                          RTP                          July 2003


   marker (M): 1 bit
      The interpretation of the marker is defined by a profile.  It is
      intended to allow significant events such as frame boundaries to
      be marked in the packet stream.  A profile MAY define additional
      marker bits or specify that there is no marker bit by changing the
      number of bits in the payload type field (see Section 5.3).

   payload type (PT): 7 bits
      This field identifies the format of the RTP payload and determines
      its interpretation by the application.  A profile MAY specify a
      default static mapping of payload type codes to payload formats.
      Additional payload type codes MAY be defined dynamically through
      non-RTP means (see Section 3).  A set of default mappings for
      audio and video is specified in the companion RFC 3551 [1].  An
      RTP source MAY change the payload type during a session, but this
      field SHOULD NOT be used for multiplexing separate media streams
      (see Section 5.2).

      A receiver MUST ignore packets with payload types that it does not
      understand.

   sequence number: 16 bits
      The sequence number increments by one for each RTP data packet
      sent, and may be used by the receiver to detect packet loss and to
      restore packet sequence.  The initial value of the sequence number
      SHOULD be random (unpredictable) to make known-plaintext attacks
      on encryption more difficult, even if the source itself does not
      encrypt according to the method in Section 9.1, because the
      packets may flow through a translator that does.  Techniques for
      choosing unpredictable numbers are discussed in [17].

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering



Schulzrinne, et al.         Standards Track                    [Page 14]

RFC 3550                          RTP                          July 2003


      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

      The initial value of the timestamp SHOULD be random, as for the
      sequence number.  Several consecutive RTP packets will have equal
      timestamps if they are (logically) generated at once, e.g., belong
      to the same video frame.  Consecutive RTP packets MAY contain