RFC1889(2) RTP

Schulzrinne, et al          Standards Track                    [Page 29]

RFC 1889                          RTP                       January 1996


   included so that rates may be calculated from these differences over
   the interval between two reports. Since that timestamp is independent
   of the clock rate for the data encoding, it is possible to implement
   encoding- and profile-independent quality monitors.

   An example calculation is the packet loss rate over the interval
   between two reception reports. The difference in the cumulative
   number of packets lost gives the number lost during that interval.
   The difference in the extended last sequence numbers received gives
   the number of packets expected during the interval. The ratio of
   these two is the packet loss fraction over the interval. This ratio
   should equal the fraction lost field if the two reports are
   consecutive, but otherwise not. The loss rate per second can be
   obtained by dividing the loss fraction by the difference in NTP
   timestamps, expressed in seconds. The number of packets received is
   the number of packets expected minus the number lost. The number of
   packets expected may also be used to judge the statistical validity
   of any loss estimates.  For example, 1 out of 5 packets lost has a
   lower significance than 200 out of 1000.

   From the sender information, a third-party monitor can calculate the
   average payload data rate and the average packet rate over an
   interval without receiving the data. Taking the ratio of the two
   gives the average payload size. If it can be assumed that packet loss
   is independent of packet size, then the number of packets received by
   a particular receiver times the average payload size (or the
   corresponding packet size) gives the apparent throughput available to
   that receiver.

   In addition to the cumulative counts which allow long-term packet
   loss measurements using differences between reports, the fraction
   lost field provides a short-term measurement from a single report.
   This becomes more important as the size of a session scales up enough
   that reception state information might not be kept for all receivers
   or the interval between reports becomes long enough that only one
   report might have been received from a particular receiver.

   The interarrival jitter field provides a second short-term measure of
   network congestion. Packet loss tracks persistent congestion while
   the jitter measure tracks transient congestion. The jitter measure
   may indicate congestion before it leads to packet loss. Since the
   interarrival jitter field is only a snapshot of the jitter at the
   time of a report, it may be necessary to analyze a number of reports
   from one receiver over time or from multiple receivers, e.g., within
   a single network.






Schulzrinne, et al          Standards Track                    [Page 30]

RFC 1889                          RTP                       January 1996


6.4 SDES: Source description RTCP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |  PT=SDES=202  |             length            | header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                          ***C/CSRC_1                          | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   1
|                           SDES items                          |
|                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                          ***C/CSRC_2                          | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   2
|                           SDES items                          |
|                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   The SDES packet is a three-level structure composed of a header and
   zero or more chunks, each of of which is composed of items describing
   the source identified in that chunk. The items are described
   individually in subsequent sections.

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   packet type (PT): 8 bits
        Contains the constant 202 to identify this as an RTCP SDES
        packet.

   source count (SC): 5 bits
        The number of ***C/CSRC chunks contained in this SDES packet. A
        value of zero is valid but useless.

   Each chunk consists of an ***C/CSRC identifier followed by a list of
   zero or more items, which carry information about the ***C/CSRC. Each
   chunk starts on a 32-bit boundary. Each item consists of an 8-bit
   type field, an 8-bit octet count describing the length of the text
   (thus, not including this two-octet header), and the text itself.
   Note that the text can be no longer than 255 octets, but this is
   consistent with the need to limit RTCP bandwidth consumption.

   The text is encoded according to the UTF-2 encoding specified in
   Annex F of ISO standard 10646 [12,13]. This encoding is also known as
   UTF-8 or UTF-FSS. It is described in "File System Safe UCS
   Transformation Format (FSS_UTF)", X/Open Preliminary Specification,
   Document Number P316 and Unicode Technical Report #4. US-ASCII is a
   subset of this encoding and requires no additional encoding. The



Schulzrinne, et al          Standards Track                    [Page 31]

RFC 1889                          RTP                       January 1996


   presence of multi-octet encodings is indicated by setting the most
   significant bit of a character to a value of one.

   Items are contiguous, i.e., items are not individually padded to a
   32-bit boundary. Text is not null terminated because some multi-octet
   encodings include null octets. The list of items in each chunk is
   terminated by one or more null octets, the first of which is
   interpreted as an item type of zero to denote the end of the list,
   and the remainder as needed to pad until the next 32-bit boundary. A
   chunk with zero items (four null octets) is valid but useless.

   End systems send one SDES packet containing their own source
   identifier (the same as the ***C in the fixed RTP header). A mixer
   sends one SDES packet containing a chunk for each contributing source
   from which it is receiving SDES information, or multiple complete
   SDES packets in the format above if there are more than 31 such
   sources (see Section 7).

   The SDES items currently defined are described in the next sections.
   Only the CNAME item is mandatory. Some items shown here may be useful
   only for particular profiles, but the item types are all assigned
   from one common space to promote shared use and to simplify profile-
   independent applications. Additional items may be defined in a
   profile by registering the type numbers with IANA.

6.4.1 CNAME: Canonical end-point identifier SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    CNAME=1    |     length    | user and domain name         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The CNAME identifier has the following properties:

        o Because the randomly allocated ***C identifier may change if a
         conflict is discovered or if a program is restarted, the CNAME
         item is required to provide the binding from the ***C
         identifier to an identifier for the source that remains
         constant.

        o Like the ***C identifier, the CNAME identifier should also be
         unique among all participants within one RTP session.

        o To provide a binding across multiple media tools used by one
         participant in a set of related RTP sessions, the CNAME should
         be fixed for that participant.




Schulzrinne, et al          Standards Track                    [Page 32]

RFC 1889                          RTP                       January 1996


        o To facilitate third-party monitoring, the CNAME should be
         suitable for either a program or a person to locate the source.

   Therefore, the CNAME should be derived algorithmically and not
   entered manually, when possible. To meet these requirements, the
   following format should be used unless a profile specifies an
   alternate syntax or semantics. The CNAME item should have the format
   "user@host", or "host" if a user name is not available as on single-
   user systems.  For both formats, "host" is either the fully qualified
   domain name of the host from which the real-time data originates,
   formatted according to the rules specified in RFC 1034 [14], RFC 1035
   [15] and Section 2.1 of RFC 1123 [16]; or the standard ASCII
   representation of the host's numeric address on the interface used
   for the RTP communication. For example, the standard ASCII
   representation of an IP Version 4 address is "dotted decimal", also
   known as dotted quad. Other address types are expected to have ASCII
   representations that are mutually unique.  The fully qualified domain
   name is more convenient for a human observer and may avoid the need
   to send a NAME item in addition, but it may be difficult or
   impossible to obtain reliably in some operating environments.
   Applications that may be run in such environments should use the
   ASCII representation of the address instead.

   Examples are "[email protected]" or "[email protected]" for a
   multi-user system. On a system with no user name, examples would be
   "sleepy.megacorp.com" or "192.0.2.89".

   The user name should be in a form that a program such as "finger" or
   "talk" could use, i.e., it typically is the login name rather than
   the personal name. The host name is not necessarily identical to the
   one in the participant's electronic mail address.

   This syntax will not provide unique identifiers for each source if an
   application permits a user to generate multiple sources from one
   host.  Such an application would have to rely on the ***C to further
   identify the source, or the profile for that application would have
   to specify additional syntax for the CNAME identifier.

   If each application creates its CNAME independently, the resulting
   CNAMEs may not be identical as would be required to provide a binding
   across multiple media tools belonging to one participant in a set of
   related RTP sessions. If cross-media binding is required, it may be
   necessary for the CNAME of each tool to be externally configured with
   the same value by a coordination tool.

   Application writers should be aware that private network address
   assignments such as the Net-10 assignment proposed in RFC 1597 [17]
   may create network addresses that are not globally unique. This would



Schulzrinne, et al          Standards Track                    [Page 33]

RFC 1889                          RTP                       January 1996


   lead to non-unique CNAMEs if hosts with private addresses and no
   direct IP connectivity to the public Internet have their RTP packets
   forwarded to the public Internet through an RTP-level translator.
   (See also RFC 1627 [18].) To handle this case, applications may
   provide a means to configure a unique CNAME, but the burden is on the
   translator to translate CNAMEs from private addresses to public
   addresses if necessary to keep private addresses from being exposed.

6.4.2 NAME: User name SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NAME=2    |     length    | common name of source        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is the real name used to describe the source, e.g., "John Doe,
   Bit Recycler, Megacorp". It may be in any form desired by the user.
   For applications such as conferencing, this form of name may be the
   most desirable for display in participant lists, and therefore might
   be sent most frequently of those items other than CNAME. Profiles may
   establish such priorities.  The NAME value is expected to remain
   constant at least for the duration of a session. It should not be
   relied upon to be unique among all participants in the session.

6.4.3 EMAIL: Electronic mail address SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    EMAIL=3    |     length    | email address of source      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The email address is formatted according to RFC 822 [19], for
   example, "[email protected]". The EMAIL value is expected to
   remain constant for the duration of a session.

6.4.4 PHONE: Phone number SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PHONE=4    |     length    | phone number of source       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The phone number should be formatted with the plus sign replacing the
   international access code.  For example, "[phone]" for a
   number in the United States.



Schulzrinne, et al          Standards Track                    [Page 34]

RFC 1889                          RTP                       January 1996


6.4.5 LOC: Geographic user location SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     LOC=5     |     length    | geographic location of site  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Depending on the application, different degrees of detail are
   appropriate for this item. For conference applications, a string like
   "Murray Hill, New Jersey" may be sufficient, while, for an active
   badge system, strings like "Room 2A244, AT&T BL MH" might be
   appropriate. The degree of detail is left to the implementation
   and/or user, but format and content may be prescribed by a profile.
   The LOC value is expected to remain constant for the duration of a
   session, except for mobile hosts.

6.4.6 TOOL: Application or tool name SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TOOL=6    |     length    | name/version of source appl. ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A string giving the name and possibly version of the application
   generating the stream, e.g., "videotool 1.2". This information may be
   useful for debugging purposes and is similar to the Mailer or Mail-
   System-Version SMTP headers. The TOOL value is expected to remain
   constant for the duration of the session.

6.4.7 NOTE: Notice/status SDES item

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     NOTE=7    |     length    | note about the source        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following semantics are suggested for this item, but these or
   other semantics may be explicitly defined by a profile. The NOTE item
   is intended for transient messages describing the current state of
   the source, e.g., "on the phone, can't talk". Or, during a seminar,
   this item might be used to convey the title of the talk. It should be
   used only to carry exceptional information and should not be included
   routinely by all participants because this would slow down the rate
   at which reception reports and CNAME are sent, thus impairing the
   performance of the protocol. In particular, it should not be included



Schulzrinne, et al          Standards Track                    [Page 35]

RFC 1889                          RTP                       January 1996


   as an item in a user's configuration file nor automatically generated
   as in a quote-of-the-day.

   Since the NOTE item may be important to display while it is active,
   the rate at which other non-CNAME items such as NAME are transmitted
   might be reduced so that the NOTE item can take that part of the RTCP
   bandwidth. When the transient message becomes inactive, the NOTE item
   should continue to be transmitted a few times at the same repetition
   rate but with a string of length zero to signal the receivers.
   However, receivers should also consider the NOTE item inactive if it
   is not received for a small multiple of the repetition rate, or
   perhaps 20-30 RTCP intervals.

6.4.8 PRIV: Private extensions SDES item

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     PRIV=8    |     length    | prefix length | prefix string...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ...              |                  value string                ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This item is used to define experimental or application-specific SDES
   extensions. The item contains a prefix consisting of a length-string
   pair, followed by the value string filling the remainder of the item
   and carrying the desired information. The prefix length field is 8
   bits long. The prefix string is a name chosen by the person defining
   the PRIV item to be unique with respect to other PRIV items this
   application might receive. The application creator might choose to
   use the application name plus an additional subtype identification if
   needed.  Alternatively, it is recommended that others choose a name
   based on the entity they represent, then coordinate the use of the
   name within that entity.

   Note that the prefix consumes some space within the item's total
   length of 255 octets, so the prefix should be kept as short as
   possible. This facility and the constrained RTCP bandwidth should not
   be overloaded; it is not intended to satisfy all the control
   communication requirements of all applications.

   SDES PRIV prefixes will not be registered by IANA. If some form of
   the PRIV item proves to be of general utility, it should instead be
   assigned a regular SDES item type registered with IANA so that no
   prefix is required. This simplifies use and increases transmission
   efficiency.





Schulzrinne, et al          Standards Track                    [Page 36]

RFC 1889                          RTP                       January 1996


6.5 BYE: Goodbye RTCP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|    SC   |   PT=BYE=203  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ***C/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |     length    |               reason for leaving             ... (opt)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The BYE packet indicates that one or more sources are no longer
   active.

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   packet type (PT): 8 bits
        Contains the constant 203 to identify this as an RTCP BYE
        packet.

   source count (SC): 5 bits
        The number of ***C/CSRC identifiers included in this BYE packet.
        A count value of zero is valid, but useless.

   If a BYE packet is received by a mixer, the mixer forwards the BYE
   packet with the ***C/CSRC identifier(s) unchanged. If a mixer shuts
   down, it should send a BYE packet listing all contributing sources it
   handles, as well as its own ***C identifier. Optionally, the BYE
   packet may include an 8-bit octet count followed by that many octets
   of text indicating the reason for leaving, e.g., "camera malfunction"
   or "RTP loop detected". The string has the same encoding as that
   described for SDES. If the string fills the packet to the next 32-bit
   boundary, the string is not null terminated. If not, the BYE packet
   is padded with null octets.













Schulzrinne, et al          Standards Track                    [Page 37]

RFC 1889                          RTP                       January 1996


6.6 APP: Application-defined RTCP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P| subtype |   PT=APP=204  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ***C/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          name (ASCII)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   application-dependent data                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The APP packet is intended for experimental use as new applications
   and new features are developed, without requiring packet type value
   registration. APP packets with unrecognized names should be ignored.
   After testing and if wider use is justified, it is recommended that
   each APP packet be redefined without the subtype and name fields and
   registered with the Internet Assigned Numbers Authority using an RTCP
   packet type.

   version (V), padding (P), length:
        As described for the SR packet (see Section 6.3.1).

   subtype: 5 bits
        May be used as a subtype to allow a set of APP packets to be
        defined under one unique name, or for any application-dependent
        data.

   packet type (PT): 8 bits
        Contains the constant 204 to identify this as an RTCP APP
        packet.

   name: 4 octets
        A name chosen by the person defining the set of APP packets to
        be unique with respect to other APP packets this application
        might receive. The application creator might choose to use the
        application name, and then coordinate the allocation of subtype
        values to others who want to define new packet types for the
        application.  Alternatively, it is recommended that others
        choose a name based on the entity they represent, then
        coordinate the use of the name within that entity. The name is
        interpreted as a sequence of four ASCII characters, with
        uppercase and lowercase characters treated as distinct.






Schulzrinne, et al          Standards Track                    [Page 38]

RFC 1889                          RTP                       January 1996


   application-dependent data: variable length
        Application-dependent data may or may not appear in an APP
        packet. It is interpreted by the application and not RTP itself.
        It must be a multiple of 32 bits long.

7.  RTP Translators and Mixers

   In addition to end systems, RTP supports the notion of "translators"
   and "mixers", which could be considered as "intermediate systems" at
   the RTP level. Although this support adds some complexity to the
   protocol, the need for these functions has been clearly established
   by experiments with multicast audio and video applications in the
   Internet. Example uses of translators and mixers given in Section 2.3
   stem from the presence of firewalls and low bandwidth connections,
   both of which are likely to remain.

7.1 General Description

   An RTP translator/mixer connects two or more transport-level
   "clouds".  Typically, each cloud is defined by a common network and
   transport protocol (e.g., IP/UDP), multicast address or pair of
   unicast addresses, and transport level destination port.  (Network-
   level protocol translators, such as IP version 4 to IP version 6, may
   be present within a cloud invisibly to RTP.) One system may serve as
   a translator or mixer for a number of RTP sessions, but each is
   considered a logically separate entity.

   In order to avoid creating a loop when a translator or mixer is
   installed, the following rules must be observed:

        o Each of the clouds connected by translators and mixers
         participating in one RTP session either must be distinct from
         all the others in at least one of these parameters (protocol,
         address, port), or must be isolated at the network level from
         the others.

        o A derivative of the first rule is that there must not be
         multiple translators or mixers connected in parallel unless by
         some arrangement they partition the set of sources to be
         forwarded.

   Similarly, all RTP end systems that can communicate through one or
   more RTP translators or mixers share the same ***C space, that is,
   the ***C identifiers must be unique among all these end systems.
   Section 8.2 describes the collision resolution algorithm by which
   ***C identifiers are kept unique and loops are detected.





Schulzrinne, et al          Standards Track                    [Page 39]

RFC 1889                          RTP                       January 1996


   There may be many varieties of translators and mixers designed for
   different purposes and applications. Some examples are to add or
   remove encryption, change the encoding of the data or the underlying
   protocols, or replicate between a multicast address and one or more
   unicast addresses. The distinction between translators and mixers is
   that a translator passes through the data streams from different
   sources separately, whereas a mixer combines them to form one new
   stream:

   Translator: Forwards RTP packets with their ***C identifier intact;
        this makes it possible for receivers to identify individual
        sources even though packets from all the sources pass through
        the same translator and carry the translator's network source
        address. Some kinds of translators will pass through the data
        untouched, but others may change the encoding of the data and
        thus the RTP data payload type and timestamp. If multiple data
        packets are re-encoded into one, or vice versa, a translator
        must assign new sequence numbers to the outgoing packets. Losses
        in the incoming packet stream may induce corresponding gaps in
        the outgoing sequence numbers. Receivers cannot detect the
        presence of a translator unless they know by some other means
        what payload type or transport address was used by the original
        source.

   Mixer: Receives streams of RTP data packets from one or more sources,
        possibly changes the data format, combines the streams in some
        manner and then forwards the combined stream. 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, so it is the
        synchronization source. Thus, all data packets forwarded by a
        mixer will be marked with the mixer's own ***C identifier. In
        order to preserve the identity of the original sources
        contributing to the mixed packet, the mixer should insert their
        ***C identifiers into the CSRC identifier list following the
        fixed RTP header of the packet. A mixer that is also itself a
        contributing source for some packet should explicitly include
        its own ***C identifier in the CSRC list for that packet.

   For some applications, it may be acceptable for a mixer not to
   identify sources in the CSRC list. However, this introduces the
   danger that loops involving those sources could not be detected.

   The advantage of a mixer over a translator for applications like
   audio is that the output bandwidth is limited to that of one source
   even when multiple sources are active on the input side. This may be
   important for low-bandwidth links. The disadvantage is that receivers
   on the output side don't have any control over which sources are



Schulzrinne, et al          Standards Track                    [Page 40]

RFC 1889                          RTP                       January 1996


   passed through or muted, unless some mechanism is implemented for
   remote control of the mixer. The regeneration of synchronization
   information by mixers also means that receivers can't do inter-media
   synchronization of the original streams. A multi-media mixer could do
   it.


         [E1]                                    [E6]
          |                                       |
    E1:17 |                                 E6:15 |
          |                                       |   E6:15
          V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
         (M1)-------------><T1>-----------------><T2>-------------->[E7]
          ^                 ^     E4:47           ^   E4:47
     E2:1 |           E4:47 |                     |   M3:89 (64,45)
          |                 |                     |
         [E2]              [E4]     M3:89 (64,45) |
                                                  |        legend:
   [E3] --------->(M2)----------->(M3)------------|        [End system]
          E3:64        M2:12 (64)  ^                       (Mixer)
                                   | E5:45                 <Translator>
                                   |
                                  [E5]          source: ***C (CSRCs)
                                                ------------------->

 Figure 3: Sample RTP network with end systems, mixers and translators

   A collection of mixers and translators is shown in Figure 3 to
   illustrate their effect on ***C and CSRC identifiers. In the figure,
   end systems are shown as rectangles (named E), translators as
   triangles (named T) and mixers as ovals (named M). The notation "M1:
   48(1,17)" designates a packet originating a mixer M1, identified with
   M1's (random) ***C value of 48 and two CSRC identifiers, 1 and 17,
   copied from the ***C identifiers of packets from E1 and E2.

7.2 RTCP Processing in Translators

   In addition to forwarding data packets, perhaps modified, translators
   and mixers must also process RTCP packets. In many cases, they will
   take apart the compound RTCP packets received from end systems to
   aggregate SDES information and to modify the SR or RR packets.
   Retransmission of this information may be triggered by the packet
   arrival or by the RTCP interval timer of the translator or mixer
   itself.

   A translator that does not modify the data packets, for example one
   that just replicates between a multicast address and a unicast
   address, may simply forward RTCP packets unmodified as well. A



Schulzrinne, et al          Standards Track                    [Page 41]

RFC 1889                          RTP                       January 1996


   translator that transforms the payload in some way must make
   corresponding transformations in the SR and RR information so that it
   still reflects the characteristics of the data and the reception
   quality. These translators must not simply forward RTCP packets. In
   general, a translator should not aggregate SR and RR packets from
   different sources into one packet since that would reduce the
   accuracy of the propagation delay measurements based on the LSR and
   DLSR fields.

   SR sender information:  A translator does not generate its own sender
        information, but forwards the SR packets received from one cloud
        to the others. The ***C is left intact but the sender
        information must be modified if required by the translation. If
        a translator changes the data encoding, it must change the
        "sender's byte count" field. If it also combines several data
        packets into one output packet, it must change the "sender's
        packet count" field. If it changes the timestamp frequency, it
        must change the "RTP timestamp" field in the SR packet.

   SR/RR reception report blocks:  A translator forwards reception
        reports received from one cloud to the others. Note that these
        flow in the direction opposite to the data.  The ***C is left
        intact. If a translator combines several data packets into one
        output packet, and therefore changes the sequence numbers, it
        must make the inverse manipulation for the packet loss fields
        and the "extended last sequence number" field. This may be
        complex. In the extreme case, there may be no meaningful way to
        translate the reception reports, so the translator may pass on
        no reception report at all or a synthetic report based on its
        own reception. The general rule is to do what makes sense for a
        particular translation.

   A translator does not require an ***C identifier of its own, but may
   choose to allocate one for the purpose of sending reports about what
   it has received. These would be sent to all the connected clouds,
   each corresponding to the translation of the data stream as sent to
   that cloud, since reception reports are normally multicast to all
   participants.

   SDES:  Translators typically forward without change the SDES
        information they receive from one cloud to the others, but may,
        for example, decide to filter non-CNAME SDES information if
        bandwidth is limited. The CNAMEs must be forwarded to allow ***C
        identifier collision detection to work. A translator that
        generates its own RR packets must send SDES CNAME information
        about itself to the same clouds that it sends those RR packets.





Schulzrinne, et al          Standards Track                    [Page 42]

RFC 1889                          RTP                       January 1996


   BYE:  Translators forward BYE packets unchanged. Translators with
        their own ***C should generate BYE packets with that ***C
        identifier if they are about to cease forwarding packets.

   APP:  Translators forward APP packets unchanged.

7.3 RTCP Processing in Mixers

   Since a mixer generates a new data stream of its own, it does not
   pass through SR or RR packets at all and instead generates new
   information for both sides.

   SR sender information:  A mixer does not pass through sender
        information from the sources it mixes because the
        characteristics of the source streams are lost in the mix. As a
        synchronization source, the mixer generates its own SR packets
        with sender information about the mixed data stream and sends
        them in the same direction as the mixed stream.

   SR/RR reception report blocks:  A mixer generates its own reception
        reports for sources in each cloud and sends them out only to the
        same cloud. It does not send these reception reports to the
        other clouds and does not forward reception reports from one
        cloud to the others because the sources would not be ***Cs there
        (only CSRCs).

   SDES:  Mixers typically forward without change the SDES information
        they receive from one cloud to the others, but may, for example,
        decide to filter non-CNAME SDES information if bandwidth is
        limited. The CNAMEs must be forwarded to allow ***C identifier
        collision detection to work. (An identifier in a CSRC list
        generated by a mixer might collide with an ***C identifier
        generated by an end system.) A mixer must send SDES CNAME
        information about itself to the same clouds that it sends SR or
        RR packets.

   Since mixers do not forward SR or RR packets, they will typically be
   extracting SDES packets from a compound RTCP packet. To minimize
   overhead, chunks from the SDES packets may be aggregated into a
   single SDES packet which is then stacked on an SR or RR packet
   originating from the mixer. The RTCP packet rate may be different on
   each side of the mixer.

   A mixer that does not insert CSRC identifiers may also refrain from
   forwarding SDES CNAMEs. In this case, the ***C identifier spaces in
   the two clouds are independent. As mentioned earlier, this mode of
   operation creates a danger that loops can't be detected.




Schulzrinne, et al          Standards Track                    [Page 43]

RFC 1889                          RTP                       January 1996


   BYE:  Mixers need to forward BYE packets. They should generate BYE
        packets with their own ***C identifiers if they are about to
        cease forwarding packets.

   APP:  The treatment of APP packets by mixers is application-specific.

7.4 Cascaded Mixers

   An RTP session may involve a collection of mixers and translators as
   shown in Figure 3. If two mixers are cascaded, such as M2 and M3 in
   the figure, packets received by a mixer may already have been mixed
   and may include a CSRC list with multiple identifiers. The second
   mixer should build the CSRC list for the outgoing packet using the
   CSRC identifiers from already-mixed input packets and the ***C
   identifiers from unmixed input packets. This is shown in the output
   arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case
   of mixers that are not cascaded, if the resulting CSRC list has more
   than 15 identifiers, the remainder cannot be included.

8.  ***C Identifier Allocation and Use

   The ***C identifier carried in the RTP header and in various fields
   of RTCP packets is a random 32-bit number that is required to be
   globally unique within an RTP session. It is crucial that the number
   be chosen with care in order that participants on the same network or
   starting at the same time are not likely to choose the same number.

   It is not sufficient to use the local network address (such as an
   IPv4 address) for the identifier because the address may not be
   unique. Since RTP translators and mixers enable interoperation among
   multiple networks with different address spaces, the allocation
   patterns for addresses within two spaces might result in a much
   higher rate of collision than would occur with random allocation.

   Multiple sources running on one host would also conflict.

   It is also not sufficient to obtain an ***C identifier simply by
   calling random() without carefully initializing the state. An example
   of how to generate a random identifier is presented in Appendix A.6.

8.1 Probability of Collision

   Since the identifiers are chosen randomly, it is possible that two or
   more sources will choose the same number. Collision occurs with the
   highest probability when all sources are started simultaneously, for
   example when triggered automatically by some session management
   event. If N is the number of sources and L the length of the
   identifier (here, 32 bits), the probability that two sources



Schulzrinne, et al          Standards Track                    [Page 44]

RFC 1889                          RTP                       January 1996


   independently pick the same value can be approximated for large N
   [20] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is
   roughly 10**-4.

   The typical collision probability is much lower than the worst-case
   above. When one new source joins an RTP session in which all the
   other sources already have unique identifiers, the probability of
   collision is just the fraction of numbers used out of the space.
   Again, if N is the number of sources and L the length of the
   identifier, the probability of collision is N / 2**L. For N=1000, the
   probability is roughly 2*10**-7.

   The probability of collision is further reduced by the opportunity
   for a new source to receive packets from other participants before
   sending its first packet (either data or control). If the new source
   keeps track of the other participants (by ***C identifier), then
   before transmitting its first packet the new source can verify that
   its identifier does not conflict with any that have been received, or
   else choose again.

8.2 Collision Resolution and Loop Detection

   Although the probability of ***C identifier collision is low, all RTP
   implementations must be prepared to detect collisions and take the
   appropriate actions to resolve them. If a source discovers at any
   time that another source is using the same ***C identifier as its
   own, it must send an RTCP BYE packet for the old identifier and
   choose another random one. If a receiver discovers that two other
   sources are colliding, it may keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs. The two sources are expected to
   resolve the collision so that the situation doesn't last.

   Because the random identifiers are kept globally unique for each RTP
   session, they can also be used to detect loops that may be introduced
   by mixers or translators. A loop causes duplication of data and
   control information, either unmodified or possibly mixed, as in the
   following examples:

        o A translator may incorrectly forward a packet to the same
         multicast group from which it has received the packet, either
         directly or through a chain of translators. In that case, the
         same packet appears several times, originating from different
         network sources.

        o Two translators incorrectly set up in parallel, i.e., with the
         same multicast groups on both sides, would both forward packets
         from one multicast group to the other. Unidirectional



Schulzrinne, et al          Standards Track                    [Page 45]

RFC 1889                          RTP                       January 1996


         translators would produce two copies; bidirectional translators
         would form a loop.

        o A mixer can close a loop by sending to the same transport
         destination upon which it receives packets, either directly or
         through another mixer or translator. In this case a source
         might show up both as an ***C on a data packet and a CSRC in a
         mixed data packet.

   A source may discover that its own packets are being looped, or that
   packets from another source are being looped (a third-party loop).

   Both loops and collisions in the random selection of a source
   identifier result in packets arriving with the same ***C identifier
   but a different source transport address, which may be that of the
   end system originating the packet or an intermediate system.
   Consequently, if a source changes its source transport address, it
   must also choose a new ***C identifier to avoid being interpreted as
   a looped source. Loops or collisions occurring on the far side of a
   translator or mixer cannot be detected using the source transport
   address if all copies of the packets go through the translator or
   mixer, however collisions may still be detected when chunks from two
   RTCP SDES packets contain the same ***C identifier but different
   CNAMEs.

   To detect and resolve these conflicts, an RTP implementation must
   include an algorithm similar to the one described below. It ignores
   packets from a new source or loop that collide with an established
   source. It resolves collisions with the participant's own ***C
   identifier by sending an RTCP BYE for the old identifier and choosing
   a new one. However, when the collision was induced by a loop of the
   participant's own packets, the algorithm will choose a new identifier
   only once and thereafter ignore packets from the looping source
   transport address. This is required to avoid a flood of BYE packets.

   This algorithm depends upon the source transport address being the
   same for both RTP and RTCP packets from a source. The algorithm would
   require modifications to support applications that don't meet this
   constraint.

   This algorithm requires keeping a table indexed by source identifiers
   and containing the source transport address from which the identifier
   was (first) received, along with other state for that source. Each
   ***C or CSRC identifier received in a data or control packet is
   looked up in this table in order to process that data or control
   information.  For control packets, each element with its own ***C,
   for example an SDES chunk, requires a separate lookup. (The ***C in a
   reception report block is an exception.) If the ***C or CSRC is not



Schulzrinne, et al          Standards Track                    [Page 46]

RFC 1889                          RTP                       January 1996


   found, a new entry is created. These table entries are removed when
   an RTCP BYE packet is received with the corresponding ***C, or after
   no packets have arrived for a relatively long time (see Section
   6.2.1).

   In order to track loops of the participant's own data packets, it is
   also necessary to keep a separate list of source transport addresses
   (not identifiers) that have been found to be conflicting. Note that
   this should be a short list, usually empty. Each element in this list
   stores the source address plus the time when the most recent
   conflicting packet was received. An element may be removed from the
   list when no conflicting packet has arrived from that source for a
   time on the order of 10 RTCP report intervals (see Section 6.2).

   For the algorithm as shown, it is assumed that the participant's own
   source identifier and state are included in the source identifier
   table. The algorithm could be restructured to first make a separate
   comparison against the participant's own source identifier.

       IF the ***C or CSRC identifier is not found in the source
          identifier table:
       THEN create a new entry storing the source transport address
            and the ***C or CSRC along with other state.
            CONTINUE with normal processing.

       (identifier is found in the table)

       IF the source transport address from the packet matches
          the one saved in the table entry for this identifier:
       THEN CONTINUE with normal processing.

       (an identifier collision or a loop is indicated)

       IF the source identifier is not the participant's own:
       THEN IF the source identifier is from an RTCP SDES chunk
               containing a CNAME item that differs from the CNAME
               in the table entry:
            THEN (optionally) count a third-party collision.
            ELSE (optionally) count a third-party loop.
            ABORT processing of data packet or control element.

       (a collision or loop of the participant's own data)

       IF the source transport address is found in the list of
         conflicting addresses:
       THEN IF the source identifier is not from an RTCP SDES chunk
               containing a CNAME item OR if that CNAME is the
               participant's own:



Schulzrinne, et al          Standards Track                    [Page 47]

RFC 1889                          RTP                       January 1996


            THEN (optionally) count occurrence of own traffic looped.
                 mark current time in conflicting address list entry.
                 ABORT processing of data packet or control element.
       log occurrence of a collision.
       create a new entry in the conflicting address list and
       mark current time.
       send an RTCP BYE packet with the old ***C identifier.
       choose a new identifier.
       create a new entry in the source identifier table with the
         old ***C plus the source transport address from the packet
         being processed.
       CONTINUE with normal processing.

   In this algorithm, packets from a newly conflicting source address
   will be ignored and packets from the original source will be kept.
   (If the original source was through a mixer and later the same source
   is received directly, the receiver may be well advised to switch
   unless other sources in the mix would be lost.) If no packets arrive
   from the original source for an extended period, the table entry will
   be timed out and the new source will be able to take over. This might
   occur if the original source detects the collision and moves to a new
   source identifier, but in the usual case an RTCP BYE packet will be
   received from the original source to delete the state without having
   to wait for a timeout.

   When a new ***C identifier is chosen due to a collision, the
   candidate identifier should first be looked up in the source
   identifier table to see if it was already in use by some other
   source. If so, another candidate should be generated and the process
   repeated.

   A loop of data packets to a multicast destination can cause severe
   network flooding. All mixers and translators are required to
   implement a loop detection algorithm like the one here so that they
   can break loops. This should limit the excess traffic to no more than
   one duplicate copy of the original traffic, which may allow the
   session to continue so that the cause of the loop can be found and
   fixed. However, in extreme cases where a mixer or translator does not
   properly break the loop and high traffic levels result, it may be
   necessary for end systems to cease transmitting data or control
   packets entirely. This decision may depend upon the application. An
   error condition should be indicated as appropriate. Transmission
   might be attempted again periodically after a long, random time (on
   the order of minutes).







Schulzrinne, et al          Standards Track                    [Page 48]

RFC 1889                          RTP                       January 1996


9.  Security

   Lower layer protocols may eventually provide all the security
   services that may be desired for applications of RTP, including
   authentication, integrity, and confidentiality. These services  have
   recently been specified for IP. Since the need for a confidentiality
   service is well established in the initial audio and video
   applications that are expected to use RTP, a confidentiality service
   is defined in the next section for use with RTP and RTCP until lower
   layer services are available. The overhead on the protocol for this
   service is low, so the penalty will be minimal if this service is
   obsoleted by lower layer services in the future.

   Alternatively, other services, other implementations of services and
   other algorithms may be defined for RTP in the future if warranted.
   The selection presented here is meant to simplify implementation of
   interoperable, secure applications and provide guidance to
   implementors. No claim is made that the methods presented here are
   appropriate for a particular security need. A profile may specify
   which services and algorithms should be offered by applications, and
   may provide guidance as to their appropriate use.

   Key distribution and certificates are outside the scope of this
   document.

9.1 Confidentiality

   Confidentiality means that only the intended receiver(s) can decode
   the received packets; for others, the packet contains no useful
   information. Confidentiality of the content is achieved by
   encryption.

   When encryption of RTP or RTCP is desired, all the octets that will
   be encapsulated for transmission in a single lower-layer packet are
   encrypted as a unit. For RTCP, a 32-bit random number is prepended to
   the unit before encryption to deter known plaintext attacks. For RTP,
   no prefix is required because the sequence number and timestamp
   fields are initialized with random offsets.

   For RTCP, it is allowed to split a compound RTCP packet into two
   lower-layer packets, one to be encrypted and one to be sent in the
   clear. For example, SDES information might be encrypted while
   reception reports were sent in the clear to accommodate third-party
   monitors that are not privy to the encryption key. In this example,
   depicted in Fig. 4, the SDES information must be appended to an RR
   packet with no reports (and the encrypted) to satisfy the requirement
   that all compound RTCP packets begin with an SR or RR packet.




Schulzrinne, et al          Standards Track                    [Page 49]

RFC 1889                          RTP                       January 1996


                 UDP packet                        UDP packet
   -------------------------------------  -------------------------
   [32-bit ][       ][     #           ]  [    # sender # receiver]
   [random ][  RR   ][SDES # CNAME, ...]  [ SR # report # report  ]
   [integer][(empty)][     #           ]  [    #        #         ]
   -------------------------------------  -------------------------
                 encrypted                       not encrypted

   #: ***C

           Figure 4: Encrypted and non-encrypted RTCP packets

   The presence of encryption and the use of the correct key are
   confirmed by the receiver through header or payload validity checks.
   Examples of such validity checks for RTP and RTCP headers are given
   in Appendices A.1 and A.2.

   The default encryption algorithm is the Data Encryption Standard
   (DES) algorithm in cipher block chaining (CBC) mode, as described in
   Section 1.1 of RFC 1423 [21], except that padding to a multiple of 8
   octets is indicated as described for the P bit in Section 5.1. The
   initialization vector is zero because random values are supplied in
   the RTP header or by the random prefix for compound RTCP packets. For
   details on the use of CBC initialization vectors, see [22].
   Implementations that support encryption should always support the DES
   algorithm in CBC mode as the default to maximize interoperability.
   This method is chosen because it has been demonstrated to be easy and
   practical to use in experimental audio and video tools in operation
   on the Internet. Other encryption algorithms may be specified
   dynamically for a session by non-RTP means.

   As an alternative to encryption at the RTP level as described above,
   profiles may define additional payload types for encrypted encodings.
   Those encodings must specify how padding and other aspects of the
   encryption should be handled. This method allows encrypting only the
   data while leaving the headers in the clear for applications where
   that is desired. It may be particularly useful for hardware devices
   that will handle both decryption and decoding.

9.2 Authentication and Message Integrity

   Authentication and message integrity are not defined in the current
   specification of RTP since these services would not be directly
   feasible without a key management infrastructure. It is expected that
   authentication and integrity services will be provided by lower layer
   protocols in the future.





Schulzrinne, et al          Standards Track                    [Page 50]

RFC 1889                          RTP                       January 1996


10.  RTP over Network and Transport Protocols

   This section describes issues specific to carrying RTP packets within
   particular network and transport protocols. The following rules apply
   unless superseded by protocol-specific definitions outside this
   specification.

   RTP relies on the underlying protocol(s) to provide demultiplexing of
   RTP data and RTCP control streams. For UDP and similar protocols, RTP
   uses an even port number and the corresponding RTCP stream uses the
   next higher (odd) port number. If an application is supplied with an
   odd number for use as the RTP port, it should replace this number
   with the next lower (even) number.

   RTP data packets contain no length field or other delineation,
   therefore RTP relies on the underlying protocol(s) to provide a
   length indication. The maximum length of RTP packets is limited only
   by the underlying protocols.

   If RTP packets are to be carried in an underlying protocol that
   provides the abstraction of a continuous octet stream rather than
   messages (packets), an encapsulation of the RTP packets must be
   defined to provide a framing mechanism. Framing is also needed if the
   underlying protocol may contain padding so that the extent of the RTP
   payload cannot be determined. The framing mechanism is not defined
   here.

   A profile may specify a framing method to be used even when RTP is
   carried in protocols that do provide framing in order to allow
   carrying several RTP packets in one lower-layer protocol data unit,
   such as a UDP packet. Carrying several RTP packets in one network or
   transport packet reduces header overhead and may simplify
   synchronization between different streams.

11.  Summary of Protocol Constants

   This section contains a summary listing of the constants defined in
   this specification.

   The RTP payload type (PT) constants are defined in profiles rather
   than this document. However, the octet of the RTP header which
   contains the marker bit(s) and payload type must avoid the reserved
   values 200 and 201 (decimal) to distinguish RTP packets from the RTCP
   SR and RR packet types for the header validation procedure described
   in Appendix A.1. For the standard definition of one marker bit and a
   7-bit payload type field as shown in this specification, this
   restriction means that payload types 72 and 73 are reserved.




Schulzrinne, et al          Standards Track                    [Page 51]

RFC 1889                          RTP                       January 1996


11.1 RTCP packet types

   abbrev.    name                   value
   SR         sender report            200
   RR         receiver report          201
   SDES       source description       202
   BYE        goodbye                  203
   APP        application-defined      204

   These type values were chosen in the range 200-204 for improved
   header validity checking of RTCP packets compared to RTP packets or
   other unrelated packets. When the RTCP packet type field is compared
   to the corresponding octet of the RTP header, this range corresponds
   to the marker bit being 1 (which it usually is not in data packets)
   and to the high bit of the standard payload type field being 1 (since
   the static payload types are typically defined in the low half). This
   range was also chosen to be some distance numerically from 0 and 255
   since all-zeros and all-ones are common data patterns.

   Since all compound RTCP packets must begin with SR or RR, these codes
   were chosen as an even/odd pair to allow the RTCP validity check to
   test the maximum number of bits with mask and value.

   Other constants are assigned by IANA. Experimenters are encouraged to
   register the numbers they need for experiments, and then unregister
   those which prove to be unneeded.

11.2 SDES types

   abbrev.    name                              value
   END        end of SDES list                      0
   CNAME      canonical name                        1
   NAME       user name                             2
   EMAIL      user's electronic mail address        3
   PHONE      user's phone number                   4
   LOC        geographic user location              5
   TOOL       name of application or tool           6
   NOTE       notice about the source               7
   PRIV       private extensions                    8

   Other constants are assigned by IANA. Experimenters are encouraged to
   register the numbers they need for experiments, and then unregister
   those which prove to be unneeded.








Schulzrinne, et al          Standards Track                    [Page 52]

RFC 1889                          RTP                       January 1996


12.  RTP Profiles and Payload Format Specifications

   A complete specification of RTP for a particular application will
   require one or more companion documents of two types described here:
   profiles, and payload format specifications.

   RTP may be used for a variety of applications with somewhat differing
   requirements. The flexibility to adapt to those requirements is
   provided by allowing multiple choices in the main protocol
   specification, then selecting the appropriate choices or defining
   extensions for a particular environment and class of applications in
   a separate profile document. Typically an application will operate
   under only one profile so there is no explicit indication of which
   profile is in use. A profile for audio and video applications may be
   found in the companion Internet-Draft draft-ietf-avt-profile for

   The second type of companion document is a payload format
   specification, which defines how a particular kind of payload data,
   such as H.261 encoded video, should be carried in RTP. These
   documents are typically titled "RTP Payload Format for XYZ
   Audio/Video Encoding". Payload formats may be useful under multiple
   profiles and may therefore be defined independently of any particular
   profile. The profile documents are then responsible for assigning a
   default mapping of that format to a payload type value if needed.

   Within this specification, the following items have been identified
   for possible definition within a profile, but this list is not meant
   to be exhaustive:

   RTP data header: The octet in the RTP data header that contains the
        marker bit and payload type field may be redefined by a profile
        to suit different requirements, for example with more or fewer
        marker bits (Section 5.3).

   Payload types: Assuming that a payload type field is included, the
        profile will usually define a set of payload formats (e.g.,
        media encodings) and a default static mapping of those formats
        to payload type values. Some of the payload formats may be
        defined by reference to separate payload format specifications.
        For each payload type defined, the profile must specify the RTP
        timestamp clock rate to be used (Section 5.1).

   RTP data header additions: Additional fields may be appended to the
        fixed RTP data header if some additional functionality is
        required across the profile's class of applications independent
        of payload type (Section 5.3).





Schulzrinne, et al          Standards Track                    [Page 53]

RFC 1889                          RTP                       January 1996


   RTP data header extensions: The contents of the first 16 bits of the
        RTP data header extension structure must be defined if use of
        that mechanism is to be allowed under the profile for
        implementation-specific extensions (Section 5.3.1).

   RTCP packet types: New application-class-specific RTCP packet types
        may be defined and registered with IANA.

   RTCP report interval: A profile should specify that the values
        suggested in Section 6.2 for the constants employed in the
        calculation of the RTCP report interval will be used.  Those are
        the RTCP fraction of session bandwidth, the minimum report
        interval, and the bandwidth split between senders and receivers.
        A profile may specify alternate values if they have been
        demonstrated to work in a scalable manner.

   SR/RR extension: An extension section may be defined for the RTCP SR
        and RR packets if there is additional information that should be
        reported regularly about the sender or receivers (Section 6.3.3).

   SDES use: The profile may specify the relative priorities for RTCP
        SDES items to be transmitted or excluded entirely (Section
        6.2.2); an alternate syntax or semantics for the CNAME item
        (Section 6.4.1); the format of the LOC item (Section 6.4.5); the
        semantics and use of the NOTE item (Section 6.4.7); or new SDES
        item types to be registered with IANA.

   Security: A profile may specify which security services and
        algorithms should be offered by applications, and may provide
        guidance as to their appropriate use (Section 9).

   String-to-key mapping: A profile may specify how a user-provided
        password or pass phrase is mapped into an encryption key.

   Underlying protocol: Use of a particular underlying network or
        transport layer protocol to carry RTP packets may be required.

   Transport mapping: A mapping of RTP and RTCP to transport-level
        addresses, e.g., UDP ports, other than the standard mapping
        defined in Section 10 may be specified.

   Encapsulation: An encapsulation of RTP packets may be defined to
        allow multiple RTP data packets to be carried in one lower-layer
        packet or to provide framing over underlying protocols that do
        not already do so (Section 10).






Schulzrinne, et al          Standards Track                    [Page 54]

RFC 1889                          RTP                       January 1996


   It is not expected that a new profile will be required for every
   application. Within one application class, it would be better to
   extend an existing profile rather than make a new one in order to
   facilitate interoperation among the applications since each will
   typically run under only one profile. Simple extensions such as the
   definition of additional payload type values or RTCP packet types may
   be accomplished by registering them through the Internet Assigned
   Numbers Authority and publishing their descriptions in an addendum to
   the profile or in a payload format specification.










































Schulzrinne, et al          Standards Track                    [Page 55]

RFC 1889                          RTP                       January 1996