Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1889

RTP: A Transport Protocol for Real-Time Applications

Pages: 75
Obsoleted by:  3550
Part 1 of 3 – Pages 1 to 15
None   None   Next

ToP   noToC   RFC1889 - Page 1
Network Working Group                Audio-Video Transport Working Group
Request for Comments: 1889                                H. Schulzrinne
Category: Standards Track                                      GMD Fokus
                                                               S. Casner
                                                  Precept Software, Inc.
                                                            R. Frederick
                                         Xerox Palo Alto Research Center
                                                             V. Jacobson
                                   Lawrence Berkeley National Laboratory
                                                            January 1996


          RTP: A Transport Protocol for Real-Time Applications

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.

Abstract

   This memorandum describes RTP, the real-time transport protocol. RTP
   provides end-to-end network transport functions suitable for
   applications transmitting real-time data, such as audio, video or
   simulation data, over multicast or unicast network services. RTP does
   not address resource reservation and does not guarantee quality-of-
   service for real-time services. The data transport is augmented by a
   control protocol (RTCP) to allow monitoring of the data delivery in a
   manner scalable to large multicast networks, and to provide minimal
   control and identification functionality. RTP and RTCP are designed
   to be independent of the underlying transport and network layers. The
   protocol supports the use of RTP-level translators and mixers.

Table of Contents

   1.         Introduction ........................................    3
   2.         RTP Use Scenarios ...................................    5
   2.1        Simple Multicast Audio Conference ...................    5
   2.2        Audio and Video Conference ..........................    6
   2.3        Mixers and Translators ..............................    6
   3.         Definitions .........................................    7
   4.         Byte Order, Alignment, and Time Format ..............    9
   5.         RTP Data Transfer Protocol ..........................   10
   5.1        RTP Fixed Header Fields .............................   10
   5.2        Multiplexing RTP Sessions ...........................   13
ToP   noToC   RFC1889 - Page 2
   5.3        Profile-Specific Modifications to the RTP Header.....   14
   5.3.1      RTP Header Extension ................................   14
   6.         RTP Control Protocol -- RTCP ........................   15
   6.1        RTCP Packet Format ..................................   17
   6.2        RTCP Transmission Interval ..........................   19
   6.2.1      Maintaining the number of session members ...........   21
   6.2.2      Allocation of source description bandwidth ..........   21
   6.3        Sender and Receiver Reports .........................   22
   6.3.1      SR: Sender report RTCP packet .......................   23
   6.3.2      RR: Receiver report RTCP packet .....................   28
   6.3.3      Extending the sender and receiver reports ...........   29
   6.3.4      Analyzing sender and receiver reports ...............   29
   6.4        SDES: Source description RTCP packet ................   31
   6.4.1      CNAME: Canonical end-point identifier SDES item .....   32
   6.4.2      NAME: User name SDES item ...........................   34
   6.4.3      EMAIL: Electronic mail address SDES item ............   34
   6.4.4      PHONE: Phone number SDES item .......................   34
   6.4.5      LOC: Geographic user location SDES item .............   35
   6.4.6      TOOL: Application or tool name SDES item ............   35
   6.4.7      NOTE: Notice/status SDES item .......................   35
   6.4.8      PRIV: Private extensions SDES item ..................   36
   6.5        BYE: Goodbye RTCP packet ............................   37
   6.6        APP: Application-defined RTCP packet ................   38
   7.         RTP Translators and Mixers ..........................   39
   7.1        General Description .................................   39
   7.2        RTCP Processing in Translators ......................   41
   7.3        RTCP Processing in Mixers ...........................   43
   7.4        Cascaded Mixers .....................................   44
   8.         SSRC Identifier Allocation and Use ..................   44
   8.1        Probability of Collision ............................   44
   8.2        Collision Resolution and Loop Detection .............   45
   9.         Security ............................................   49
   9.1        Confidentiality .....................................   49
   9.2        Authentication and Message Integrity ................   50
   10.        RTP over Network and Transport Protocols ............   51
   11.        Summary of Protocol Constants .......................   51
   11.1       RTCP packet types ...................................   52
   11.2       SDES types ..........................................   52
   12.        RTP Profiles and Payload Format Specifications ......   53
   A.         Algorithms ..........................................   56
   A.1        RTP Data Header Validity Checks .....................   59
   A.2        RTCP Header Validity Checks .........................   63
   A.3        Determining the Number of RTP Packets Expected and
              Lost ................................................   63
   A.4        Generating SDES RTCP Packets ........................   64
   A.5        Parsing RTCP SDES Packets ...........................   65
   A.6        Generating a Random 32-bit Identifier ...............   66
   A.7        Computing the RTCP Transmission Interval ............   68
ToP   noToC   RFC1889 - Page 3
   A.8        Estimating the Interarrival Jitter ..................   71
   B.         Security Considerations .............................   72
   C.         Addresses of Authors ................................   72
   D.         Bibliography ........................................   73

1.  Introduction

   This memorandum specifies the real-time transport protocol (RTP),
   which provides end-to-end delivery services for data with real-time
   characteristics, such as interactive audio and video. Those services
   include payload type identification, sequence numbering, timestamping
   and delivery monitoring. Applications typically run RTP on top of UDP
   to make use of its multiplexing and checksum services; both protocols
   contribute parts of the transport protocol functionality. However,
   RTP may be used with other suitable underlying network or transport
   protocols (see Section 10). RTP supports data transfer to multiple
   destinations using multicast distribution if provided by the
   underlying network.

   Note that RTP itself does not provide any mechanism to ensure timely
   delivery or provide other quality-of-service guarantees, but relies
   on lower-layer services to do so. It does not guarantee delivery or
   prevent out-of-order delivery, nor does it assume that the underlying
   network is reliable and delivers packets in sequence. The sequence
   numbers included in RTP allow the receiver to reconstruct the
   sender's packet sequence, but sequence numbers might also be used to
   determine the proper location of a packet, for example in video
   decoding, without necessarily decoding packets in sequence.

   While RTP is primarily designed to satisfy the needs of multi-
   participant multimedia conferences, it is not limited to that
   particular application. Storage of continuous data, interactive
   distributed simulation, active badge, and control and measurement
   applications may also find RTP applicable.

   This document defines RTP, consisting of two closely-linked parts:

        o the real-time transport protocol (RTP), to carry data that has
         real-time properties.

        o the RTP control protocol (RTCP), to monitor the quality of
         service and to convey information about the participants in an
         on-going session. The latter aspect of RTCP may be sufficient
         for "loosely controlled" sessions, i.e., where there is no
         explicit membership control and set-up, but it is not
         necessarily intended to support all of an application's control
         communication requirements.  This functionality may be fully or
         partially subsumed by a separate session control protocol,
ToP   noToC   RFC1889 - Page 4
         which is beyond the scope of this document.

   RTP represents a new style of protocol following the principles of
   application level framing and integrated layer processing proposed by
   Clark and Tennenhouse [1]. That is, RTP is intended to be malleable
   to provide the information required by a particular application and
   will often be integrated into the application processing rather than
   being implemented as a separate layer. RTP is a protocol framework
   that is deliberately not complete.  This document specifies those
   functions expected to be common across all the applications for which
   RTP would be appropriate. Unlike conventional protocols in which
   additional functions might be accommodated by making the protocol
   more general or by adding an option mechanism that would require
   parsing, RTP is intended to be tailored through modifications and/or
   additions to the headers as needed. Examples are given in Sections
   5.3 and 6.3.3.

   Therefore, in addition to this document, a complete specification of
   RTP for a particular application will require one or more companion
   documents (see Section 12):

        o a profile specification document, which defines a set of
         payload type codes and their mapping to payload formats (e.g.,
         media encodings). A profile may also define extensions or
         modifications to RTP that are specific to a particular class of
         applications.  Typically an application will operate under only
         one profile. A profile for audio and video data may be found in
         the companion RFC TBD.

        o payload format specification documents, which define how a
         particular payload, such as an audio or video encoding, is to
         be carried in RTP.

   A discussion of real-time services and algorithms for their
   implementation as well as background discussion on some of the RTP
   design decisions can be found in [2].

   Several RTP applications, both experimental and commercial, have
   already been implemented from draft specifications. These
   applications include audio and video tools along with diagnostic
   tools such as traffic monitors. Users of these tools number in the
   thousands.  However, the current Internet cannot yet support the full
   potential demand for real-time services. High-bandwidth services
   using RTP, such as video, can potentially seriously degrade the
   quality of service of other network services. Thus, implementors
   should take appropriate precautions to limit accidental bandwidth
   usage. Application documentation should clearly outline the
   limitations and possible operational impact of high-bandwidth real-
ToP   noToC   RFC1889 - Page 5
   time services on the Internet and other network services.

2.  RTP Use Scenarios

   The following sections describe some aspects of the use of RTP. The
   examples were chosen to illustrate the basic operation of
   applications using RTP, not to limit what RTP may be used for. In
   these examples, RTP is carried on top of IP and UDP, and follows the
   conventions established by the profile for audio and video specified
   in the companion Internet-Draft draft-ietf-avt-profile

2.1 Simple Multicast Audio Conference

   A working group of the IETF meets to discuss the latest protocol
   draft, using the IP multicast services of the Internet for voice
   communications. Through some allocation mechanism the working group
   chair obtains a multicast group address and pair of ports. One port
   is used for audio data, and the other is used for control (RTCP)
   packets.  This address and port information is distributed to the
   intended participants. If privacy is desired, the data and control
   packets may be encrypted as specified in Section 9.1, in which case
   an encryption key must also be generated and distributed.  The exact
   details of these allocation and distribution mechanisms are beyond
   the scope of RTP.

   The audio conferencing application used by each conference
   participant sends audio data in small chunks of, say, 20 ms duration.
   Each chunk of audio data is preceded by an RTP header; RTP header and
   data are in turn contained in a UDP packet. The RTP header indicates
   what type of audio encoding (such as PCM, ADPCM or LPC) is contained
   in each packet so that senders can change the encoding during a
   conference, for example, to accommodate a new participant that is
   connected through a low-bandwidth link or react to indications of
   network congestion.

   The Internet, like other packet networks, occasionally loses and
   reorders packets and delays them by variable amounts of time. To cope
   with these impairments, the RTP header contains timing information
   and a sequence number that allow the receivers to reconstruct the
   timing produced by the source, so that in this example, chunks of
   audio are contiguously played out the speaker every 20 ms. This
   timing reconstruction is performed separately for each source of RTP
   packets in the conference. The sequence number can also be used by
   the receiver to estimate how many packets are being lost.

   Since members of the working group join and leave during the
   conference, it is useful to know who is participating at any moment
   and how well they are receiving the audio data. For that purpose,
ToP   noToC   RFC1889 - Page 6
   each instance of the audio application in the conference periodically
   multicasts a reception report plus the name of its user on the RTCP
   (control) port. The reception report indicates how well the current
   speaker is being received and may be used to control adaptive
   encodings. In addition to the user name, other identifying
   information may also be included subject to control bandwidth limits.
   A site sends the RTCP BYE packet (Section 6.5) when it leaves the
   conference.

2.2 Audio and Video Conference

   If both audio and video media are used in a conference, they are
   transmitted as separate RTP sessions RTCP packets are transmitted for
   each medium using two different UDP port pairs and/or multicast
   addresses. There is no direct coupling at the RTP level between the
   audio and video sessions, except that a user participating in both
   sessions should use the same distinguished (canonical) name in the
   RTCP packets for both so that the sessions can be associated.

   One motivation for this separation is to allow some participants in
   the conference to receive only one medium if they choose. Further
   explanation is given in Section 5.2. Despite the separation,
   synchronized playback of a source's audio and video can be achieved
   using timing information carried in the RTCP packets for both
   sessions.

2.3 Mixers and Translators

   So far, we have assumed that all sites want to receive  media data in
   the same format. However, this may not always be appropriate.
   Consider the case where participants in one area are connected
   through a low-speed link to the majority of the conference
   participants who enjoy high-speed network access. Instead of forcing
   everyone to use a lower-bandwidth, reduced-quality audio encoding, an
   RTP-level relay called a mixer may be placed near the low-bandwidth
   area. This mixer resynchronizes incoming audio packets to reconstruct
   the constant 20 ms spacing generated by the sender, mixes these
   reconstructed audio streams into a single stream, translates the
   audio encoding to a lower-bandwidth one and forwards the lower-
   bandwidth packet stream across the low-speed link. These packets
   might be unicast to a single recipient or multicast on a different
   address to multiple recipients. The RTP header includes a means for
   mixers to identify the sources that contributed to a mixed packet so
   that correct talker indication can be provided at the receivers.

   Some of the intended participants in the audio conference may be
   connected with high bandwidth links but might not be directly
   reachable via IP multicast. For example, they might be behind an
ToP   noToC   RFC1889 - Page 7
   application-level firewall that will not let any IP packets pass. For
   these sites, mixing may not be necessary, in which case another type
   of RTP-level relay called a translator may be used. Two translators
   are installed, one on either side of the firewall, with the outside
   one funneling all multicast packets received through a secure
   connection to the translator inside the firewall. The translator
   inside the firewall sends them again as multicast packets to a
   multicast group restricted to the site's internal network.

   Mixers and translators may be designed for a variety of purposes. An
   example is a video mixer that scales the images of individual people
   in separate video streams and composites them into one video stream
   to simulate a group scene. Other examples of translation include the
   connection of a group of hosts speaking only IP/UDP to a group of
   hosts that understand only ST-II, or the packet-by-packet encoding
   translation of video streams from individual sources without
   resynchronization or mixing. Details of the operation of mixers and
   translators are given in Section 7.

3.  Definitions

   RTP payload: The data transported by RTP in a packet, for example
        audio samples or compressed video data. The payload format and
        interpretation are beyond the scope of this document.

   RTP packet: A data packet consisting of the fixed RTP header, a
        possibly empty list of contributing sources (see below), and the
        payload data. Some underlying protocols may require an
        encapsulation of the RTP packet to be defined. Typically one
        packet of the underlying protocol contains a single RTP packet,
        but several RTP packets may be contained if permitted by the
        encapsulation method (see Section 10).

   RTCP packet: A control packet consisting of a fixed header part
        similar to that of RTP data packets, followed by structured
        elements that vary depending upon the RTCP packet type. The
        formats are defined in Section 6. Typically, multiple RTCP
        packets are sent together as a compound RTCP packet in a single
        packet of the underlying protocol; this is enabled by the length
        field in the fixed header of each RTCP packet.

   Port: The "abstraction that transport protocols use to distinguish
        among multiple destinations within a given host computer. TCP/IP
        protocols identify ports using small positive integers." [3] The
        transport selectors (TSEL) used by the OSI transport layer are
        equivalent to ports.  RTP depends upon the lower-layer protocol
        to provide some mechanism such as ports to multiplex the RTP and
        RTCP packets of a session.
ToP   noToC   RFC1889 - Page 8
   Transport address: The combination of a network address and port that
        identifies a transport-level endpoint, for example an IP address
        and a UDP port. Packets are transmitted from a source transport
        address to a destination transport address.

   RTP session: The association among a set of participants
        communicating with RTP. For each participant, the session is
        defined by a particular pair of destination transport addresses
        (one network address plus a port pair for RTP and RTCP). The
        destination transport address pair may be common for all
        participants, as in the case of IP multicast, or may be
        different for each, as in the case of individual unicast network
        addresses plus a common port pair.  In a multimedia session,
        each medium is carried in a separate RTP session with its own
        RTCP packets. The multiple RTP sessions are distinguished by
        different port number pairs and/or different multicast
        addresses.

   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.4.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 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).
ToP   noToC   RFC1889 - Page 9
   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. These are called
        third party monitors.

   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 conference control application 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. For simple 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 [4].
   Unless otherwise noted, numeric constants are in decimal (base 10).
ToP   noToC   RFC1889 - Page 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 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 [5]. 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.

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
ToP   noToC   RFC1889 - Page 11
        payload. The last octet of the padding contains a count of how
        many padding octets should be ignored. 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 is 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.

   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
        specifies 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). An initial
        set of default mappings for audio and video is specified in the
        companion profile Internet-Draft draft-ietf-avt-profile, and
        may be extended in future editions of the Assigned Numbers RFC
        [6].  An RTP sender emits a single RTP payload type at any given
        time; this field is not intended for multiplexing separate media
        streams (see Section 5.2).

   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 is random (unpredictable) to make known-plaintext attacks
        on encryption more difficult, even if the source itself does not
        encrypt, because the packets may flow through a translator that
        does. Techniques for choosing unpredictable numbers are
        discussed in [7].

   timestamp: 32 bits
        The timestamp reflects the sampling instant of the first octet
        in the RTP data packet. The sampling instant must be derived
ToP   noToC   RFC1889 - Page 12
        from a clock that increments monotonically and linearly in time
        to allow synchronization and jitter calculations (see Section
        6.3.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 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 is random, as for the sequence
   number. Several consecutive RTP packets may have equal timestamps if
   they are (logically) generated at once, e.g., belong to the same
   video frame. Consecutive RTP packets may contain timestamps that are
   not monotonic if the data is not transmitted in the order it was
   sampled, as in the case of MPEG interpolated video frames. (The
   sequence numbers of the packets as transmitted will still be
   monotonic.)

   SSRC: 32 bits
        The SSRC field identifies the synchronization source. This
        identifier is chosen randomly, with the intent that no two
        synchronization sources within the same RTP session will have
        the same SSRC identifier. An example algorithm for generating a
        random identifier is presented in Appendix A.6. Although the
        probability of multiple sources choosing the same identifier is
        low, all RTP implementations must be prepared to detect and
        resolve collisions.  Section 8 describes the probability of
        collision along with a mechanism for resolving collisions and
        detecting RTP-level forwarding loops based on the uniqueness of
        the SSRC identifier. If a source changes its source transport
        address, it must also choose a new SSRC identifier to avoid
        being interpreted as a looped source.

   CSRC list: 0 to 15 items, 32 bits each
        The CSRC list identifies the contributing sources for the
        payload contained in this packet. The number of identifiers is
        given by the CC field. If there are more than 15 contributing
        sources, only 15 may be identified. CSRC identifiers are
ToP   noToC   RFC1889 - Page 13
        inserted by mixers, using the SSRC identifiers of contributing
        sources. For example, for audio packets the SSRC identifiers of
        all sources that were mixed together to create a packet are
        listed, allowing correct talker indication at the receiver.

5.2 Multiplexing RTP Sessions

   For efficient protocol processing, the number of multiplexing points
   should be minimized, as described in the integrated layer processing
   design principle [1]. In RTP, multiplexing is provided by the
   destination transport address (network address and port number) which
   define an RTP session. For example, in a teleconference composed of
   audio and video media encoded separately, each medium should be
   carried in a separate RTP session with its own destination transport
   address. It is not intended that the audio and video be carried in a
   single RTP session and demultiplexed based on the payload type or
   SSRC fields. Interleaving packets with different payload types but
   using the same SSRC would introduce several problems:

        1.   If one payload type were switched during a session, there
             would be no general means to identify which of the old
             values the new one replaced.

        2.   An SSRC is defined to identify a single timing and sequence
             number space. Interleaving multiple payload types would
             require different timing spaces if the media clock rates
             differ and would require different sequence number spaces
             to tell which payload type suffered packet loss.

        3.   The RTCP sender and receiver reports (see Section 6.3) can
             only describe one timing and sequence number space per SSRC
             and do not carry a payload type field.

        4.   An RTP mixer would not be able to combine interleaved
             streams of incompatible media into one stream.

        5.   Carrying multiple media in one RTP session precludes: the
             use of different network paths or network resource
             allocations if appropriate; reception of a subset of the
             media if desired, for example just audio if video would
             exceed the available bandwidth; and receiver
             implementations that use separate processes for the
             different media, whereas using separate RTP sessions
             permits either single- or multiple-process implementations.

   Using a different SSRC for each medium but sending them in the same
   RTP session would avoid the first three problems but not the last
   two.
ToP   noToC   RFC1889 - Page 14
5.3 Profile-Specific Modifications to the RTP Header

   The existing RTP data packet header is believed to be complete for
   the set of functions required in common across all the application
   classes that RTP might support. However, in keeping with the ALF
   design principle, the header may be tailored through modifications or
   additions defined in a profile specification while still allowing
   profile-independent monitoring and recording tools to function.

        o The marker bit and payload type field carry profile-specific
         information, but they are allocated in the fixed header since
         many applications are expected to need them and might otherwise
         have to add another 32-bit word just to hold them. The octet
         containing these fields may be redefined by a profile to suit
         different requirements, for example with a more or fewer marker
         bits. If there are any marker bits, one should be located in
         the most significant bit of the octet since profile-independent
         monitors may be able to observe a correlation between packet
         loss patterns and the marker bit.

        o Additional information that is required for a particular
         payload format, such as a video encoding, should be carried in
         the payload section of the packet. This might be in a header
         that is always present at the start of the payload section, or
         might be indicated by a reserved value in the data pattern.

        o If a particular class of applications needs additional
         functionality independent of payload format, the profile under
         which those applications operate should define additional fixed
         fields to follow immediately after the SSRC field of the
         existing fixed header.  Those applications will be able to
         quickly and directly access the additional fields while
         profile-independent monitors or recorders can still process the
         RTP packets by interpreting only the first twelve octets.

   If it turns out that additional functionality is needed in common
   across all profiles, then a new version of RTP should be defined to
   make a permanent change to the fixed header.

5.3.1 RTP Header Extension

   An extension mechanism is provided to allow individual
   implementations to experiment with new payload-format-independent
   functions that require additional information to be carried in the
   RTP data packet header. This mechanism is designed so that the header
   extension may be ignored by other interoperating implementations that
   have not been extended.
ToP   noToC   RFC1889 - Page 15
   Note that this header extension is intended only for limited use.
   Most potential uses of this mechanism would be better done another
   way, using the methods described in the previous section. For
   example, a profile-specific extension to the fixed header is less
   expensive to process because it is not conditional nor in a variable
   location. Additional information required for a particular payload
   format should not use this header extension, but should be carried in
   the payload section of the packet.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |


   If the X bit in the RTP header is one, a variable-length header
   extension is appended to the RTP header, following the CSRC list if
   present. The header extension contains a 16-bit length field that
   counts the number of 32-bit words in the extension, excluding the
   four-octet extension header (therefore zero is a valid length). Only
   a single extension may be appended to the RTP data header. To allow
   multiple interoperating implementations to each experiment
   independently with different header extensions, or to allow a
   particular implementation to experiment with more than one type of
   header extension, the first 16 bits of the header extension are left
   open for distinguishing identifiers or parameters. The format of
   these 16 bits is to be defined by the profile specification under
   which the implementations are operating. This RTP specification does
   not define any header extensions itself.



(page 15 continued on part 2)

Next Section