GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1889

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

Schulzrinne, et al Standards Track [Page 1] RFC 1889 RTP January 1996

 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

Schulzrinne, et al Standards Track [Page 2] RFC 1889 RTP January 1996

 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,

Schulzrinne, et al Standards Track [Page 3] RFC 1889 RTP January 1996

       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-

Schulzrinne, et al Standards Track [Page 4] RFC 1889 RTP January 1996

 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,

Schulzrinne, et al Standards Track [Page 5] RFC 1889 RTP January 1996

 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

Schulzrinne, et al Standards Track [Page 6] RFC 1889 RTP January 1996

 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.

Schulzrinne, et al Standards Track [Page 7] RFC 1889 RTP January 1996

 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).

Schulzrinne, et al Standards Track [Page 8] RFC 1889 RTP January 1996

 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).

Schulzrinne, et al Standards Track [Page 9] RFC 1889 RTP January 1996

 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

Schulzrinne, et al Standards Track [Page 10] RFC 1889 RTP January 1996

      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

Schulzrinne, et al Standards Track [Page 11] RFC 1889 RTP January 1996

      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

Schulzrinne, et al Standards Track [Page 12] RFC 1889 RTP January 1996

      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.

Schulzrinne, et al Standards Track [Page 13] RFC 1889 RTP January 1996

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.

Schulzrinne, et al Standards Track [Page 14] RFC 1889 RTP January 1996

 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.

6. RTP Control Protocol – RTCP

 The RTP control protocol (RTCP) is based on the periodic transmission
 of control packets to all participants in the session, using the same
 distribution mechanism as the data packets. The underlying protocol
 must provide multiplexing of the data and control packets, for
 example using separate port numbers with UDP. RTCP performs four
 functions:
      1.   The primary function is to provide feedback on the quality
           of the data distribution. This is an integral part of the
           RTP's role as a transport protocol and is related to the
           flow and congestion control functions of other transport
           protocols. The feedback may be directly useful for control
           of adaptive encodings [8,9], but experiments with IP

Schulzrinne, et al Standards Track [Page 15] RFC 1889 RTP January 1996

           multicasting have shown that it is also critical to get
           feedback from the receivers to diagnose faults in the
           distribution. Sending reception feedback reports to all
           participants allows one who is observing problems to
           evaluate whether those problems are local or global. With a
           distribution mechanism like IP multicast, it is also
           possible for an entity such as a network service provider
           who is not otherwise involved in the session to receive the
           feedback information and act as a third-party monitor to
           diagnose network problems. This feedback function is
           performed by the RTCP sender and receiver reports,
           described below in Section 6.3.
      2.   RTCP carries a persistent transport-level identifier for an
           RTP source called the canonical name or CNAME, Section
           6.4.1. Since the SSRC identifier may change if a conflict
           is discovered or a program is restarted, receivers require
           the CNAME to keep track of each participant. Receivers also
           require the CNAME to associate multiple data streams from a
           given participant in a set of related RTP sessions, for
           example to synchronize audio and video.
      3.   The first two functions require that all participants send
           RTCP packets, therefore the rate must be controlled in
           order for RTP to scale up to a large number of
           participants. By having each participant send its control
           packets to all the others, each can independently observe
           the number of participants. This number is used to
           calculate the rate at which the packets are sent, as
           explained in Section 6.2.
      4.   A fourth, optional function is to convey minimal session
           control information, for example participant identification
           to be displayed in the user interface. This is most likely
           to be useful in "loosely controlled" sessions where
           participants enter and leave without membership control or
           parameter negotiation. RTCP serves as a convenient channel
           to reach all the participants, but it is not necessarily
           expected to support all the control communication
           requirements of an application. A higher-level session
           control protocol, which is beyond the scope of this
           document, may be needed.
 Functions 1-3 are mandatory when RTP is used in the IP multicast
 environment, and are recommended for all environments. RTP
 application designers are advised to avoid mechanisms that can only
 work in unicast mode and will not scale to larger numbers.

Schulzrinne, et al Standards Track [Page 16] RFC 1889 RTP January 1996

6.1 RTCP Packet Format

 This specification defines several RTCP packet types to carry a
 variety of control information:
 SR: Sender report, for transmission and reception statistics from
      participants that are active senders
 RR: Receiver report, for reception statistics from participants that
      are not active senders
 SDES: Source description items, including CNAME
 BYE: Indicates end of participation
 APP: Application specific functions
 Each RTCP packet begins with a fixed part similar to that of RTP data
 packets, followed by structured elements that may be of variable
 length according to the packet type but always end on a 32-bit
 boundary. The alignment requirement and a length field in the fixed
 part are included to make RTCP packets "stackable". Multiple RTCP
 packets may be concatenated without any intervening separators to
 form a compound RTCP packet that is sent in a single packet of the
 lower layer protocol, for example UDP. There is no explicit count of
 individual RTCP packets in the compound packet since the lower layer
 protocols are expected to provide an overall length to determine the
 end of the compound packet.
 Each individual RTCP packet in the compound packet may be processed
 independently with no requirements upon the order or combination of
 packets. However, in order to perform the functions of the protocol,
 the following constraints are imposed:
      o Reception statistics (in SR or RR) should be sent as often as
       bandwidth constraints will allow to maximize the resolution of
       the statistics, therefore each periodically transmitted
       compound RTCP packet should include a report packet.
      o New receivers need to receive the CNAME for a source as soon
       as possible to identify the source and to begin associating
       media for purposes such as lip-sync, so each compound RTCP
       packet should also include the SDES CNAME.
      o The number of packet types that may appear first in the
       compound packet should be limited to increase the number of
       constant bits in the first word and the probability of
       successfully validating RTCP packets against misaddressed RTP

Schulzrinne, et al Standards Track [Page 17] RFC 1889 RTP January 1996

       data packets or other unrelated packets.
 Thus, all RTCP packets must be sent in a compound packet of at least
 two individual packets, with the following format recommended:
 Encryption prefix:  If and only if the compound packet is to be
      encrypted, it is prefixed by a random 32-bit quantity redrawn
      for every compound packet transmitted.
 SR or RR:  The first RTCP packet in the compound packet must always
      be a report packet to facilitate header validation as described
      in Appendix A.2. This is true even if no data has been sent nor
      received, in which case an empty RR is sent, and even if the
      only other RTCP packet in the compound packet is a BYE.
 Additional RRs:  If the number of sources for which reception
      statistics are being reported exceeds 31, the number that will
      fit into one SR or RR packet, then additional RR packets should
      follow the initial report packet.
 SDES:  An SDES packet containing a CNAME item must be included in
      each compound RTCP packet. Other source description items may
      optionally be included if required by a particular application,
      subject to bandwidth constraints (see Section 6.2.2).
 BYE or APP:  Other RTCP packet types, including those yet to be
      defined, may follow in any order, except that BYE should be the
      last packet sent with a given SSRC/CSRC. Packet types may appear
      more than once.
 It is advisable for translators and mixers to combine individual RTCP
 packets from the multiple sources they are forwarding into one
 compound packet whenever feasible in order to amortize the packet
 overhead (see Section 7). An example RTCP compound packet as might be
 produced by a mixer is shown in Fig. 1.  If the overall length of a
 compound packet would exceed the maximum transmission unit (MTU) of
 the network path, it may be segmented into multiple shorter compound
 packets to be transmitted in separate packets of the underlying
 protocol. Note that each of the compound packets must begin with an
 SR or RR packet.
 An implementation may ignore incoming RTCP packets with types unknown
 to it. Additional RTCP packet types may be registered with the
 Internet Assigned Numbers Authority (IANA).

Schulzrinne, et al Standards Track [Page 18] RFC 1889 RTP January 1996

6.2 RTCP Transmission Interval

 if encrypted: random 32-bit integer
  |
  |[------- packet -------][----------- packet -----------][-packet-]
  |
  |             receiver reports          chunk        chunk
  V                                    item  item     item  item
 --------------------------------------------------------------------
 |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why]
 |R[  |# report #  1 #  2 ][    |#             |#         ][   ##   ]
 |R[  |#        #    #    ][    |#             |#         ][   ##   ]
 |R[  |#        #    #    ][    |#             |#         ][   ##   ]
 --------------------------------------------------------------------
 |<------------------  UDP packet (compound packet) --------------->|
 #: SSRC/CSRC
            Figure 1: Example of an RTCP compound packet
 RTP is designed to allow an application to scale automatically over
 session sizes ranging from a few participants to thousands. For
 example, in an audio conference the data traffic is inherently self-
 limiting because only one or two people will speak at a time, so with
 multicast distribution the data rate on any given link remains
 relatively constant independent of the number of participants.
 However, the control traffic is not self-limiting. If the reception
 reports from each participant were sent at a constant rate, the
 control traffic would grow linearly with the number of participants.
 Therefore, the rate must be scaled down.
 For each session, it is assumed that the data traffic is subject to
 an aggregate limit called the "session bandwidth" to be divided among
 the participants. This bandwidth might be reserved and the limit
 enforced by the network, or it might just be a reasonable share. The
 session bandwidth may be chosen based or some cost or a priori
 knowledge of the available network bandwidth for the session. It is
 somewhat independent of the media encoding, but the encoding choice
 may be limited by the session bandwidth. The session bandwidth
 parameter is expected to be supplied by a session management
 application when it invokes a media application, but media
 applications may also set a default based on the single-sender data
 bandwidth for the encoding selected for the session. The application
 may also enforce bandwidth limits based on multicast scope rules or
 other criteria.

Schulzrinne, et al Standards Track [Page 19] RFC 1889 RTP January 1996

 Bandwidth calculations for control and data traffic include lower-
 layer transport and network protocols (e.g., UDP and IP) since that
 is what the resource reservation system would need to know. The
 application can also be expected to know which of these protocols are
 in use. Link level headers are not included in the calculation since
 the packet will be encapsulated with different link level headers as
 it travels.
 The control traffic should be limited to a small and known fraction
 of the session bandwidth: small so that the primary function of the
 transport protocol to carry data is not impaired; known so that the
 control traffic can be included in the bandwidth specification given
 to a resource reservation protocol, and so that each participant can
 independently calculate its share. It is suggested that the fraction
 of the session bandwidth allocated to RTCP be fixed at 5%. While the
 value of this and other constants in the interval calculation is not
 critical, all participants in the session must use the same values so
 the same interval will be calculated. Therefore, these constants
 should be fixed for a particular profile.
 The algorithm described in Appendix A.7 was designed to meet the
 goals outlined above. It calculates the interval between sending
 compound RTCP packets to divide the allowed control traffic bandwidth
 among the participants. This allows an application to provide fast
 response for small sessions where, for example, identification of all
 participants is important, yet automatically adapt to large sessions.
 The algorithm incorporates the following characteristics:
      o Senders are collectively allocated at least 1/4 of the control
       traffic bandwidth so that in sessions with a large number of
       receivers but a small number of senders, newly joining
       participants will more quickly receive the CNAME for the
       sending sites.
      o The calculated interval between RTCP packets is required to be
       greater than a minimum of 5 seconds to avoid having bursts of
       RTCP packets exceed the allowed bandwidth when the number of
       participants is small and the traffic isn't smoothed according
       to the law of large numbers.
      o The interval between RTCP packets is varied randomly over the
       range [0.5,1.5] times the calculated interval to avoid
       unintended synchronization of all participants [10].  The first
       RTCP packet sent after joining a session is also delayed by a
       random variation of half the minimum RTCP interval in case the
       application is started at multiple sites simultaneously, for
       example as initiated by a session announcement.

Schulzrinne, et al Standards Track [Page 20] RFC 1889 RTP January 1996

      o A dynamic estimate of the average compound RTCP packet size is
       calculated, including all those received and sent, to
       automatically adapt to changes in the amount of control
       information carried.
 This algorithm may be used for sessions in which all participants are
 allowed to send. In that case, the session bandwidth parameter is the
 product of the individual sender's bandwidth times the number of
 participants, and the RTCP bandwidth is 5% of that.

6.2.1 Maintaining the number of session members

 Calculation of the RTCP packet interval depends upon an estimate of
 the number of sites participating in the session. New sites are added
 to the count when they are heard, and an entry for each is created in
 a table indexed by the SSRC or CSRC identifier (see Section 8.2) to
 keep track of them. New entries may not be considered valid until
 multiple packets carrying the new SSRC have been received (see
 Appendix A.1). Entries may be deleted from the table when an RTCP BYE
 packet with the corresponding SSRC identifier is received.
 A participant may mark another site inactive, or delete it if not yet
 valid, if no RTP or RTCP packet has been received for a small number
 of RTCP report intervals (5 is suggested). This provides some
 robustness against packet loss. All sites must calculate roughly the
 same value for the RTCP report interval in order for this timeout to
 work properly.
 Once a site has been validated, then if it is later marked inactive
 the state for that site should still be retained and the site should
 continue to be counted in the total number of sites sharing RTCP
 bandwidth for a period long enough to span typical network
 partitions.  This is to avoid excessive traffic, when the partition
 heals, due to an RTCP report interval that is too small. A timeout of
 30 minutes is suggested. Note that this is still larger than 5 times
 the largest value to which the RTCP report interval is expected to
 usefully scale, about 2 to 5 minutes.

6.2.2 Allocation of source description bandwidth

 This specification defines several source description (SDES) items in
 addition to the mandatory CNAME item, such as NAME (personal name)
 and EMAIL (email address). It also provides a means to define new
 application-specific RTCP packet types. Applications should exercise
 caution in allocating control bandwidth to this additional
 information because it will slow down the rate at which reception
 reports and CNAME are sent, thus impairing the performance of the
 protocol. It is recommended that no more than 20% of the RTCP

Schulzrinne, et al Standards Track [Page 21] RFC 1889 RTP January 1996

 bandwidth allocated to a single participant be used to carry the
 additional information.  Furthermore, it is not intended that all
 SDES items should be included in every application. Those that are
 included should be assigned a fraction of the bandwidth according to
 their utility.  Rather than estimate these fractions dynamically, it
 is recommended that the percentages be translated statically into
 report interval counts based on the typical length of an item.
 For example, an application may be designed to send only CNAME, NAME
 and EMAIL and not any others. NAME might be given much higher
 priority than EMAIL because the NAME would be displayed continuously
 in the application's user interface, whereas EMAIL would be displayed
 only when requested. At every RTCP interval, an RR packet and an SDES
 packet with the CNAME item would be sent. For a small session
 operating at the minimum interval, that would be every 5 seconds on
 the average. Every third interval (15 seconds), one extra item would
 be included in the SDES packet. Seven out of eight times this would
 be the NAME item, and every eighth time (2 minutes) it would be the
 EMAIL item.
 When multiple applications operate in concert using cross-application
 binding through a common CNAME for each participant, for example in a
 multimedia conference composed of an RTP session for each medium, the
 additional SDES information might be sent in only one RTP session.
 The other sessions would carry only the CNAME item.

6.3 Sender and Receiver Reports

 RTP receivers provide reception quality feedback using RTCP report
 packets which may take one of two forms depending upon whether or not
 the receiver is also a sender. The only difference between the sender
 report (SR) and receiver report (RR) forms, besides the packet type
 code, is that the sender report includes a 20-byte sender information
 section for use by active senders. The SR is issued if a site has
 sent any data packets during the interval since issuing the last
 report or the previous one, otherwise the RR is issued.
 Both the SR and RR forms include zero or more reception report
 blocks, one for each of the synchronization sources from which this
 receiver has received RTP data packets since the last report. Reports
 are not issued for contributing sources listed in the CSRC list. Each
 reception report block provides statistics about the data received
 from the particular source indicated in that block. Since a maximum
 of 31 reception report blocks will fit in an SR or RR packet,
 additional RR packets may be stacked after the initial SR or RR
 packet as needed to contain the reception reports for all sources
 heard during the interval since the last report.

Schulzrinne, et al Standards Track [Page 22] RFC 1889 RTP January 1996

 The next sections define the formats of the two reports, how they may
 be extended in a profile-specific manner if an application requires
 additional feedback information, and how the reports may be used.
 Details of reception reporting by translators and mixers is given in
 Section 7.

6.3.1 SR: Sender report 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=2P RC PT=SR=200 length

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SSRC of sender

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

NTP timestamp, most significant word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info

NTP timestamp, least significant word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP timestamp

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

sender's packet count

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

sender's octet count

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC_1 (SSRC of first source)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block

fraction lost cumulative number of packets lost

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

extended highest sequence number received

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

interarrival jitter

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

last SR (LSR)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

delay since last SR (DLSR)

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC_2 (SSRC of second source)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : … : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

profile-specific extensions

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The sender report packet consists of three sections, possibly
 followed by a fourth profile-specific extension section if defined.
 The first section, the header, is 8 octets long. The fields have the
 following meaning:

Schulzrinne, et al Standards Track [Page 23] RFC 1889 RTP January 1996

 version (V): 2 bits
      Identifies the version of RTP, which is the same in RTCP packets
      as in RTP data packets. The version defined by this
      specification is two (2).
 padding (P): 1 bit
      If the padding bit is set, this RTCP packet contains some
      additional padding octets at the end which are not part of the
      control information. The last octet of the padding is a count of
      how many padding octets should be ignored. Padding may be needed
      by some encryption algorithms with fixed block sizes. In a
      compound RTCP packet, padding should only be required on the
      last individual packet because the compound packet is encrypted
      as a whole.
 reception report count (RC): 5 bits
      The number of reception report blocks contained in this packet.
      A value of zero is valid.
 packet type (PT): 8 bits
      Contains the constant 200 to identify this as an RTCP SR packet.
 length: 16 bits
      The length of this RTCP packet in 32-bit words minus one,
      including the header and any padding. (The offset of one makes
      zero a valid length and avoids a possible infinite loop in
      scanning a compound RTCP packet, while counting 32-bit words
      avoids a validity check for a multiple of 4.)
 SSRC: 32 bits
      The synchronization source identifier for the originator of this
      SR packet.
 The second section, the sender information, is 20 octets long and is
 present in every sender report packet. It summarizes the data
 transmissions from this sender. The fields have the following
 meaning:
 NTP timestamp: 64 bits
      Indicates the wallclock time when this report was sent so that
      it may be used in combination with timestamps returned in
      reception reports from other receivers to measure round-trip
      propagation to those receivers. Receivers should expect that the
      measurement accuracy of the timestamp may be limited to far less
      than the resolution of the NTP timestamp. The measurement
      uncertainty of the timestamp is not indicated as it may not be
      known. A sender that can keep track of elapsed time but has no
      notion of wallclock time may use the elapsed time since joining

Schulzrinne, et al Standards Track [Page 24] RFC 1889 RTP January 1996

      the session instead. This is assumed to be less than 68 years,
      so the high bit will be zero. It is permissible to use the
      sampling clock to estimate elapsed wallclock time. A sender that
      has no notion of wallclock or elapsed time may set the NTP
      timestamp to zero.
 RTP timestamp: 32 bits
      Corresponds to the same time as the NTP timestamp (above), but
      in the same units and with the same random offset as the RTP
      timestamps in data packets. This correspondence may be used for
      intra- and inter-media synchronization for sources whose NTP
      timestamps are synchronized, and may be used by media-
      independent receivers to estimate the nominal RTP clock
      frequency. Note that in most cases this timestamp will not be
      equal to the RTP timestamp in any adjacent data packet. Rather,
      it is calculated from the corresponding NTP timestamp using the
      relationship between the RTP timestamp counter and real time as
      maintained by periodically checking the wallclock time at a
      sampling instant.
 sender's packet count: 32 bits
      The total number of RTP data packets transmitted by the sender
      since starting transmission up until the time this SR packet was
      generated.  The count is reset if the sender changes its SSRC
      identifier.
 sender's octet count: 32 bits
      The total number of payload octets (i.e., not including header
      or padding) transmitted in RTP data packets by the sender since
      starting transmission up until the time this SR packet was
      generated. The count is reset if the sender changes its SSRC
      identifier. This field can be used to estimate the average
      payload data rate.
 The third section contains zero or more reception report blocks
 depending on the number of other sources heard by this sender since
 the last report. Each reception report block conveys statistics on
 the reception of RTP packets from a single synchronization source.
 Receivers do not carry over statistics when a source changes its SSRC
 identifier due to a collision. These statistics are:
 SSRC_n (source identifier): 32 bits
      The SSRC identifier of the source to which the information in
      this reception report block pertains.
 fraction lost: 8 bits
      The fraction of RTP data packets from source SSRC_n lost since
      the previous SR or RR packet was sent, expressed as a fixed

Schulzrinne, et al Standards Track [Page 25] RFC 1889 RTP January 1996

      point number with the binary point at the left edge of the
      field. (That is equivalent to taking the integer part after
      multiplying the loss fraction by 256.) This fraction is defined
      to be the number of packets lost divided by the number of
      packets expected,  as defined in the next paragraph.  An
      implementation is shown in Appendix A.3. If the loss is negative
      due to duplicates, the fraction lost is set to zero. Note that a
      receiver cannot tell whether any packets were lost after the
      last one received, and that there will be no reception report
      block issued for a source if all packets from that source sent
      during the last reporting interval have been lost.
 cumulative number of packets lost: 24 bits
      The total number of RTP data packets from source SSRC_n that
      have been lost since the beginning of reception. This number is
      defined to be the number of packets expected less the number of
      packets actually received, where the number of packets received
      includes any which are late or duplicates. Thus packets that
      arrive late are not counted as lost, and the loss may be
      negative if there are duplicates.  The number of packets
      expected is defined to be the extended last sequence number
      received, as defined next, less the initial sequence number
      received. This may be calculated as shown in Appendix A.3.
 extended highest sequence number received: 32 bits
      The low 16 bits contain the highest sequence number received in
      an RTP data packet from source SSRC_n, and the most significant
      16 bits extend that sequence number with the corresponding count
      of sequence number cycles, which may be maintained according to
      the algorithm in Appendix A.1. Note that different receivers
      within the same session will generate different extensions to
      the sequence number if their start times differ significantly.
 interarrival jitter: 32 bits
      An estimate of the statistical variance of the RTP data packet
      interarrival time, measured in timestamp units and expressed as
      an unsigned integer. The interarrival jitter J is defined to be
      the mean deviation (smoothed absolute value) of the difference D
      in packet spacing at the receiver compared to the sender for a
      pair of packets. As shown in the equation below, this is
      equivalent to the difference in the "relative transit time" for
      the two packets; the relative transit time is the difference
      between a packet's RTP timestamp and the receiver's clock at the
      time of arrival, measured in the same units.

Schulzrinne, et al Standards Track [Page 26] RFC 1889 RTP January 1996

 If Si is the RTP timestamp from packet i, and Ri is the time of
 arrival in RTP timestamp units for packet i, then for two packets i
 and j, D may be expressed as
               D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
 The interarrival jitter is calculated continuously as each data
 packet i is received from source SSRC_n, using this difference D for
 that packet and the previous packet i-1 in order of arrival (not
 necessarily in sequence), according to the formula
                  J=J+(|D(i-1,i)|-J)/16
 Whenever a reception report is issued, the current value of J is
 sampled.
 The jitter calculation is prescribed here to allow profile-
 independent monitors to make valid interpretations of reports coming
 from different implementations. This algorithm is the optimal first-
 order estimator and the gain parameter 1/16 gives a good noise
 reduction ratio while maintaining a reasonable rate of convergence
 [11].  A sample implementation is shown in Appendix A.8.
 last SR timestamp (LSR): 32 bits
      The middle 32 bits out of 64 in the NTP timestamp (as explained
      in Section 4) received as part of the most recent RTCP sender
      report (SR) packet from source SSRC_n.  If no SR has been
      received yet, the field is set to zero.
 delay since last SR (DLSR): 32 bits
      The delay, expressed in units of 1/65536 seconds, between
      receiving the last SR packet from source SSRC_n and sending this
      reception report block.  If no SR packet has been received yet
      from SSRC_n, the DLSR field is set to zero.
 Let SSRC_r denote the receiver issuing this receiver report. Source
 SSRC_n can compute the round propagation delay to SSRC_r by recording
 the time A when this reception report block is received.  It
 calculates the total round-trip time A-LSR using the last SR
 timestamp (LSR) field, and then subtracting this field to leave the
 round-trip propagation delay as (A- LSR - DLSR).  This is illustrated
 in Fig. 2.
 This may be used as an approximate measure of distance to cluster
 receivers, although some links have very asymmetric delays.

Schulzrinne, et al Standards Track [Page 27] RFC 1889 RTP January 1996

6.3.2 RR: Receiver report RTCP packet

 [10 Nov 1995 11:33:25.125]           [10 Nov 1995 11:33:36.5]
 n                 SR(n)              A=b710:8000 (46864.500 s)
 ---------------------------------------------------------------->
                    v                 ^
 ntp_sec =0xb44db705 v               ^ dlsr=0x0005.4000 (    5.250s)
 ntp_frac=0x20000000  v             ^  lsr =0xb705:2000 (46853.125s)
   (3024992016.125 s)  v           ^
 r                      v         ^ RR(n)
 ---------------------------------------------------------------->
                        |<-DLSR->|
                         (5.250 s)
 A     0xb710:8000 (46864.500 s)
 DLSR -0x0005:4000 (    5.250 s)
 LSR  -0xb705:2000 (46853.125 s)
 -------------------------------
 delay 0x   6:2000 (    6.125 s)
         Figure 2: Example for round-trip time computation

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=2P RC PT=RR=201 length

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SSRC of packet sender

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC_1 (SSRC of first source)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block

fraction lost cumulative number of packets lost

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

extended highest sequence number received

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

interarrival jitter

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

last SR (LSR)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

delay since last SR (DLSR)

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC_2 (SSRC of second source)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : … : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

profile-specific extensions

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Schulzrinne, et al Standards Track [Page 28] RFC 1889 RTP January 1996

 The format of the receiver report (RR) packet is the same as that of
 the SR packet except that the packet type field contains the constant
 201 and the five words of sender information are omitted (these are
 the NTP and RTP timestamps and sender's packet and octet counts). The
 remaining fields have the same meaning as for the SR packet.
 An empty RR packet (RC = 0) is put at the head of a compound RTCP
 packet when there is no data transmission or reception to report.

6.3.3 Extending the sender and receiver reports

 A profile should define profile- or application-specific extensions
 to the sender report and receiver if there is additional information
 that should be reported regularly about the sender or receivers. This
 method should be used in preference to defining another RTCP packet
 type because it requires less overhead:
      o fewer octets in the packet (no RTCP header or SSRC field);
      o simpler and faster parsing because applications running under
       that profile would be programmed to always expect the extension
       fields in the directly accessible location after the reception
       reports.
 If additional sender information is required, it should be included
 first in the extension for sender reports, but would not be present
 in receiver reports. If information about receivers is to be
 included, that data may be structured as an array of blocks parallel
 to the existing array of reception report blocks; that is, the number
 of blocks would be indicated by the RC field.

6.3.4 Analyzing sender and receiver reports

 It is expected that reception quality feedback will be useful not
 only for the sender but also for other receivers and third-party
 monitors.  The sender may modify its transmissions based on the
 feedback; receivers can determine whether problems are local,
 regional or global; network managers may use profile-independent
 monitors that receive only the RTCP packets and not the corresponding
 RTP data packets to evaluate the performance of their networks for
 multicast distribution.
 Cumulative counts are used in both the sender information and
 receiver report blocks so that differences may be calculated between
 any two reports to make measurements over both short and long time
 periods, and to provide resilience against the loss of a report. The
 difference between the last two reports received can be used to
 estimate the recent quality of the distribution. The NTP timestamp is

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=2P SC PT=SDES=202 length

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC/CSRC_1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1

SDES items

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SSRC/CSRC_2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 SSRC/CSRC chunks contained in this SDES packet. A
      value of zero is valid but useless.
 Each chunk consists of an SSRC/CSRC identifier followed by a list of
 zero or more items, which carry information about the SSRC/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 SSRC 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 SSRC 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 SSRC
       identifier to an identifier for the source that remains
       constant.
      o Like the SSRC 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 "doe@sleepy.megacorp.com" or "doe@192.0.2.89" 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 SSRC 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, "John.Doe@megacorp.com". 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, "+1 908 555 1212" 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           SSRC/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 SSRC/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 SSRC/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 SSRC 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           SSRC/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 SSRC space, that is,
 the SSRC identifiers must be unique among all these end systems.
 Section 8.2 describes the collision resolution algorithm by which
 SSRC 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 SSRC 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 SSRC identifier. In
      order to preserve the identity of the original sources
      contributing to the mixed packet, the mixer should insert their
      SSRC 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 SSRC 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: SSRC (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 SSRC 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) SSRC value of 48 and two CSRC identifiers, 1 and 17,
 copied from the SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC
      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 SSRC should generate BYE packets with that SSRC
      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 SSRCs 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 SSRC identifier
      collision detection to work. (An identifier in a CSRC list
      generated by a mixer might collide with an SSRC 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 SSRC 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 SSRC 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 SSRC
 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. SSRC Identifier Allocation and Use

 The SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC 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 SSRC
 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
 SSRC 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 SSRC,
 for example an SDES chunk, requires a separate lookup. (The SSRC in a
 reception report block is an exception.) If the SSRC 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 SSRC, 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 SSRC or CSRC identifier is not found in the source
        identifier table:
     THEN create a new entry storing the source transport address
          and the SSRC 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 SSRC identifier.
     choose a new identifier.
     create a new entry in the source identifier table with the
       old SSRC 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 SSRC 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
 #: SSRC
         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

A. Algorithms

 We provide examples of C code for aspects of RTP sender and receiver
 algorithms. There may be other implementation methods that are faster
 in particular operating environments or have other advantages. These
 implementation notes are for informational purposes only and are
 meant to clarify the RTP specification.
 The following definitions are used for all examples; for clarity and
 brevity, the structure definitions are only valid for 32-bit big-
 endian (most significant octet first) architectures. Bit fields are
 assumed to be packed tightly in big-endian bit order, with no
 additional padding. Modifications would be required to construct a
 portable implementation.
 /*
  * rtp.h  --  RTP header file (RFC XXXX)
  */
 #include <sys/types.h>
 /*
  * The type definitions below are valid for 32-bit architectures and
  * may have to be adjusted for 16- or 64-bit architectures.
  */
 typedef unsigned char  u_int8;
 typedef unsigned short u_int16;
 typedef unsigned int   u_int32;
 typedef          short int16;
 /*
  * Current protocol version.
  */
 #define RTP_VERSION    2
 #define RTP_SEQ_MOD (1<<16)
 #define RTP_MAX_SDES 255      /* maximum text length for SDES */
 typedef enum {
     RTCP_SR   = 200,
     RTCP_RR   = 201,
     RTCP_SDES = 202,
     RTCP_BYE  = 203,
     RTCP_APP  = 204
 } rtcp_type_t;
 typedef enum {
     RTCP_SDES_END   = 0,
     RTCP_SDES_CNAME = 1,

Schulzrinne, et al Standards Track [Page 56] RFC 1889 RTP January 1996

     RTCP_SDES_NAME  = 2,
     RTCP_SDES_EMAIL = 3,
     RTCP_SDES_PHONE = 4,
     RTCP_SDES_LOC   = 5,
     RTCP_SDES_TOOL  = 6,
     RTCP_SDES_NOTE  = 7,
     RTCP_SDES_PRIV  = 8
 } rtcp_sdes_type_t;
 /*
  * RTP data header
  */
 typedef struct {
     unsigned int version:2;   /* protocol version */
     unsigned int p:1;         /* padding flag */
     unsigned int x:1;         /* header extension flag */
     unsigned int cc:4;        /* CSRC count */
     unsigned int m:1;         /* marker bit */
     unsigned int pt:7;        /* payload type */
     u_int16 seq;              /* sequence number */
     u_int32 ts;               /* timestamp */
     u_int32 ssrc;             /* synchronization source */
     u_int32 csrc[1];          /* optional CSRC list */
 } rtp_hdr_t;
 /*
  * RTCP common header word
  */
 typedef struct {
     unsigned int version:2;   /* protocol version */
     unsigned int p:1;         /* padding flag */
     unsigned int count:5;     /* varies by packet type */
     unsigned int pt:8;        /* RTCP packet type */
     u_int16 length;           /* pkt len in words, w/o this word */
 } rtcp_common_t;
 /*
  * Big-endian mask for version, padding bit and packet type pair
  */
 #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
 #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
 /*
  * Reception report block
  */
 typedef struct {
     u_int32 ssrc;             /* data source being reported */
     unsigned int fraction:8;  /* fraction lost since last SR/RR */

Schulzrinne, et al Standards Track [Page 57] RFC 1889 RTP January 1996

     int lost:24;              /* cumul. no. pkts lost (signed!) */
     u_int32 last_seq;         /* extended last seq. no. received */
     u_int32 jitter;           /* interarrival jitter */
     u_int32 lsr;              /* last SR packet from this source */
     u_int32 dlsr;             /* delay since last SR packet */
 } rtcp_rr_t;
 /*
  * SDES item
  */
 typedef struct {
     u_int8 type;              /* type of item (rtcp_sdes_type_t) */
     u_int8 length;            /* length of item (in octets) */
     char data[1];             /* text, not null-terminated */
 } rtcp_sdes_item_t;
 /*
  * One RTCP packet
  */
 typedef struct {
     rtcp_common_t common;     /* common header */
     union {
         /* sender report (SR) */
         struct {
             u_int32 ssrc;     /* sender generating this report */
             u_int32 ntp_sec;  /* NTP timestamp */
             u_int32 ntp_frac;
             u_int32 rtp_ts;   /* RTP timestamp */
             u_int32 psent;    /* packets sent */
             u_int32 osent;    /* octets sent */
             rtcp_rr_t rr[1];  /* variable-length list */
         } sr;
         /* reception report (RR) */
         struct {
             u_int32 ssrc;     /* receiver generating this report */
             rtcp_rr_t rr[1];  /* variable-length list */
         } rr;
         /* source description (SDES) */
         struct rtcp_sdes {
             u_int32 src;      /* first SSRC/CSRC */
             rtcp_sdes_item_t item[1]; /* list of SDES items */
         } sdes;
         /* BYE */
         struct {
             u_int32 src[1];   /* list of sources */

Schulzrinne, et al Standards Track [Page 58] RFC 1889 RTP January 1996

             /* can't express trailing text for reason */
         } bye;
     } r;
 } rtcp_t;
 typedef struct rtcp_sdes rtcp_sdes_t;
 /*
  * Per-source state information
  */
 typedef struct {
     u_int16 max_seq;        /* highest seq. number seen */
     u_int32 cycles;         /* shifted count of seq. number cycles */
     u_int32 base_seq;       /* base seq number */
     u_int32 bad_seq;        /* last 'bad' seq number + 1 */
     u_int32 probation;      /* sequ. packets till source is valid */
     u_int32 received;       /* packets received */
     u_int32 expected_prior; /* packet expected at last interval */
     u_int32 received_prior; /* packet received at last interval */
     u_int32 transit;        /* relative trans time for prev pkt */
     u_int32 jitter;         /* estimated jitter */
     /* ... */
 } source;

A.1 RTP Data Header Validity Checks

 An RTP receiver should check the validity of the RTP header on
 incoming packets since they might be encrypted or might be from a
 different application that happens to be misaddressed. Similarly, if
 encryption is enabled, the header validity check is needed to verify
 that incoming packets have been correctly decrypted, although a
 failure of the header validity check (e.g., unknown payload type) may
 not necessarily indicate decryption failure.
 Only weak validity checks are possible on an RTP data packet from a
 source that has not been heard before:
      o RTP version field must equal 2.
      o The payload type must be known, in particular it must not be
       equal to SR or RR.
      o If the P bit is set, then the last octet of the packet must
       contain a valid octet count, in particular, less than the total
       packet length minus the header size.
      o The X bit must be zero if the profile does not specify that
       the header extension mechanism may be used. Otherwise, the

Schulzrinne, et al Standards Track [Page 59] RFC 1889 RTP January 1996

       extension length field must be less than the total packet size
       minus the fixed header length and padding.
      o The length of the packet must be consistent with CC and
       payload type (if payloads have a known length).
 The last three checks are somewhat complex and not always possible,
 leaving only the first two which total just a few bits. If the SSRC
 identifier in the packet is one that has been received before, then
 the packet is probably valid and checking if the sequence number is
 in the expected range provides further validation. If the SSRC
 identifier has not been seen before, then data packets carrying that
 identifier may be considered invalid until a small number of them
 arrive with consecutive sequence numbers.
 The routine update_seq shown below ensures that a source is declared
 valid only after MIN_SEQUENTIAL packets have been received in
 sequence. It also validates the sequence number seq of a newly
 received packet and updates the sequence state for the packet's
 source in the structure to which s points.
 When a new source is heard for the first time, that is, its SSRC
 identifier is not in the table (see Section 8.2), and the per-source
 state is allocated for it, s->probation should be set to the number
 of sequential packets required before declaring a source valid
 (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 s-
 >probation marks the source as not yet valid so the state may be
 discarded after a short timeout rather than a long one, as discussed
 in Section 6.2.1.
 After a source is considered valid, the sequence number is considered
 valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more
 than MAX_MISORDER behind. If the new sequence number is ahead of
 max_seq modulo the RTP sequence number range (16 bits), but is
 smaller than max_seq , it has wrapped around and the (shifted) count
 of sequence number cycles is incremented. A value of one is returned
 to indicate a valid sequence number.
 Otherwise, the value zero is returned to indicate that the validation
 failed, and the bad sequence number is stored. If the next packet
 received carries the next higher sequence number, it is considered
 the valid start of a new packet sequence presumably caused by an
 extended dropout or a source restart. Since multiple complete
 sequence number cycles may have been missed, the packet loss
 statistics are reset.
 Typical values for the parameters are shown, based on a maximum
 misordering time of 2 seconds at 50 packets/second and a maximum

Schulzrinne, et al Standards Track [Page 60] RFC 1889 RTP January 1996

 dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a
 small fraction of the 16-bit sequence number space to give a
 reasonable probability that new sequence numbers after a restart will
 not fall in the acceptable range for sequence numbers from before the
 restart.
 void init_seq(source *s, u_int16 seq)
 {
     s->base_seq = seq - 1;
     s->max_seq = seq;
     s->bad_seq = RTP_SEQ_MOD + 1;
     s->cycles = 0;
     s->received = 0;
     s->received_prior = 0;
     s->expected_prior = 0;
     /* other initialization */
 }
 int update_seq(source *s, u_int16 seq)
 {
     u_int16 udelta = seq - s->max_seq;
     const int MAX_DROPOUT = 3000;
     const int MAX_MISORDER = 100;
     const int MIN_SEQUENTIAL = 2;
     /*
      * Source is not valid until MIN_SEQUENTIAL packets with
      * sequential sequence numbers have been received.
      */
     if (s->probation) {
         /* packet is in sequence */
         if (seq == s->max_seq + 1) {
             s->probation--;
             s->max_seq = seq;
             if (s->probation == 0) {
                 init_seq(s, seq);
                 s->received++;
                 return 1;
             }
         } else {
             s->probation = MIN_SEQUENTIAL - 1;
             s->max_seq = seq;
         }
         return 0;
     } else if (udelta < MAX_DROPOUT) {
         /* in order, with permissible gap */
         if (seq < s->max_seq) {
             /*

Schulzrinne, et al Standards Track [Page 61] RFC 1889 RTP January 1996

  • Sequence number wrapped - count another 64K cycle.
  • /

s→cycles += RTP_SEQ_MOD;

         }
         s->max_seq = seq;
     } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
         /* the sequence number made a very large jump */
         if (seq == s->bad_seq) {
             /*
              * Two sequential packets -- assume that the other side
              * restarted without telling us so just re-sync
              * (i.e., pretend this was the first packet).
              */
             init_seq(s, seq);
         }
         else {
             s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
             return 0;
         }
     } else {
         /* duplicate or reordered packet */
     }
     s->received++;
     return 1;
 }
 The validity check can be made stronger requiring more than two
 packets in sequence.  The disadvantages are that a larger number of
 initial packets will be discarded and that high packet loss rates
 could prevent validation. However, because the RTCP header validation
 is relatively strong, if an RTCP packet is received from a source
 before the data packets, the count could be adjusted so that only two
 packets are required in sequence.  If initial data loss for a few
 seconds can be tolerated, an application could choose to discard all
 data packets from a source until a valid RTCP packet has been
 received from that source.
 Depending on the application and encoding, algorithms may exploit
 additional knowledge about the payload format for further validation.
 For payload types where the timestamp increment is the same for all
 packets, the timestamp values can be predicted from the previous
 packet received from the same source using the sequence number
 difference (assuming no change in payload type).
 A strong "fast-path" check is possible since with high probability
 the first four octets in the header of a newly received RTP data
 packet will be just the same as that of the previous packet from the
 same SSRC except that the sequence number will have increased by one.

Schulzrinne, et al Standards Track [Page 62] RFC 1889 RTP January 1996

 Similarly, a single-entry cache may be used for faster SSRC lookups
 in applications where data is typically received from one source at a
 time.

A.2 RTCP Header Validity Checks

 The following checks can be applied to RTCP packets.
      o RTP version field must equal 2.
      o The payload type field of the first RTCP packet in a compound
       packet must be equal to SR or RR.
      o The padding bit (P) should be zero for the first packet of a
       compound RTCP packet because only the last should possibly need
       padding.
      o The length fields of the individual RTCP packets must total to
       the overall length of the compound RTCP packet as received.
       This is a fairly strong check.
 The code fragment below performs all of these checks. The packet type
 is not checked for subsequent packets since unknown packet types may
 be present and should be ignored.
     u_int32 len;        /* length of compound RTCP packet in words */
     rtcp_t *r;          /* RTCP header */
     rtcp_t *end;        /* end of compound RTCP packet */
     if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
         /* something wrong with packet format */
     }
     end = (rtcp_t *)((u_int32 *)r + len);
     do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
     while (r < end && r->common.version == 2);
     if (r != end) {
         /* something wrong with packet format */
     }

A.3 Determining the Number of RTP Packets Expected and Lost

 In order to compute packet loss rates, the number of packets expected
 and actually received from each source needs to be known, using per-
 source state information defined in struct source referenced via
 pointer s in the code below. The number of packets received is simply
 the count of packets as they arrive, including any late or duplicate

Schulzrinne, et al Standards Track [Page 63] RFC 1889 RTP January 1996

 packets. The number of packets expected can be computed by the
 receiver as the difference between the highest sequence number
 received ( s->max_seq ) and the first sequence number received ( s-
 >base_seq ). Since the sequence number is only 16 bits and will wrap
 around, it is necessary to extend the highest sequence number with
 the (shifted) count of sequence number wraparounds ( s->cycles ).
 Both the received packet count and the count of cycles are maintained
 the RTP header validity check routine in Appendix A.1.
     extended_max = s->cycles + s->max_seq;
     expected = extended_max - s->base_seq + 1;
 The number of packets lost is defined to be the number of packets
 expected less the number of packets actually received:
     lost = expected - s->received;
 Since this number is carried in 24 bits, it should be clamped at
 0xffffff rather than wrap around to zero.
 The fraction of packets lost during the last reporting interval
 (since the previous SR or RR packet was sent) is calculated from
 differences in the expected and received packet counts across the
 interval, where expected_prior and received_prior are the values
 saved when the previous reception report was generated:
     expected_interval = expected - s->expected_prior;
     s->expected_prior = expected;
     received_interval = s->received - s->received_prior;
     s->received_prior = s->received;
     lost_interval = expected_interval - received_interval;
     if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
     else fraction = (lost_interval << 8) / expected_interval;
 The resulting fraction is an 8-bit fixed point number with the binary
 point at the left edge.

A.4 Generating SDES RTCP Packets

 This function builds one SDES chunk into buffer b composed of argc
 items supplied in arrays type , value and length b
 char *rtp_write_sdes(char *b, u_int32 src, int argc,
                      rtcp_sdes_type_t type[], char *value[],
                      int length[])
 {
     rtcp_sdes_t *s = (rtcp_sdes_t *)b;
     rtcp_sdes_item_t *rsp;

Schulzrinne, et al Standards Track [Page 64] RFC 1889 RTP January 1996

     int i;
     int len;
     int pad;
     /* SSRC header */
     s->src = src;
     rsp = &s->item[0];
     /* SDES items */
     for (i = 0; i < argc; i++) {
         rsp->type = type[i];
         len = length[i];
         if (len > RTP_MAX_SDES) {
             /* invalid length, may want to take other action */
             len = RTP_MAX_SDES;
         }
         rsp->length = len;
         memcpy(rsp->data, value[i], len);
         rsp = (rtcp_sdes_item_t *)&rsp->data[len];
     }
     /* terminate with end marker and pad to next 4-octet boundary */
     len = ((char *) rsp) - b;
     pad = 4 - (len & 0x3);
     b = (char *) rsp;
     while (pad--) *b++ = RTCP_SDES_END;
     return b;
 }

A.5 Parsing RTCP SDES Packets

 This function parses an SDES packet, calling functions find_member()
 to find a pointer to the information for a session member given the
 SSRC identifier and member_sdes() to store the new SDES information
 for that member. This function expects a pointer to the header of the
 RTCP packet.
 void rtp_read_sdes(rtcp_t *r)
 {
     int count = r->common.count;
     rtcp_sdes_t *sd = &r->r.sdes;
     rtcp_sdes_item_t *rsp, *rspn;
     rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
                             ((u_int32 *)r + r->common.length + 1);
     source *s;
     while (--count >= 0) {

Schulzrinne, et al Standards Track [Page 65] RFC 1889 RTP January 1996

         rsp = &sd->item[0];
         if (rsp >= end) break;
         s = find_member(sd->src);
         for (; rsp->type; rsp = rspn ) {
             rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
             if (rspn >= end) {
                 rsp = rspn;
                 break;
             }
             member_sdes(s, rsp->type, rsp->data, rsp->length);
         }
         sd = (rtcp_sdes_t *)
              ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
     }
     if (count >= 0) {
         /* invalid packet format */
     }
 }

A.6 Generating a Random 32-bit Identifier

 The following subroutine generates a random 32-bit identifier using
 the MD5 routines published in RFC 1321 [23]. The system routines may
 not be present on all operating systems, but they should serve as
 hints as to what kinds of information may be used. Other system calls
 that may be appropriate include
      o getdomainname() ,
      o getwd() , or
      o getrusage()
 "Live" video or audio samples are also a good source of random
 numbers, but care must be taken to avoid using a turned-off
 microphone or blinded camera as a source [7].
 Use of this or similar routine is suggested to generate the initial
 seed for the random number generator producing the RTCP period (as
 shown in Appendix A.7), to generate the initial values for the
 sequence number and timestamp, and to generate SSRC values.  Since
 this routine is likely to be CPU-intensive, its direct use to
 generate RTCP periods is inappropriate because predictability is not
 an issue. Note that this routine produces the same result on repeated
 calls until the value of the system clock changes unless different
 values are supplied for the type argument.

Schulzrinne, et al Standards Track [Page 66] RFC 1889 RTP January 1996

 /*
  * Generate a random 32-bit quantity.
  */
 #include <sys/types.h>   /* u_long */
 #include <sys/time.h>    /* gettimeofday() */
 #include <unistd.h>      /* get..() */
 #include <stdio.h>       /* printf() */
 #include <time.h>        /* clock() */
 #include <sys/utsname.h> /* uname() */
 #include "global.h"      /* from RFC 1321 */
 #include "md5.h"         /* from RFC 1321 */
 #define MD_CTX MD5_CTX
 #define MDInit MD5Init
 #define MDUpdate MD5Update
 #define MDFinal MD5Final
 static u_long md_32(char *string, int length)
 {
     MD_CTX context;
     union {
         char   c[16];
         u_long x[4];
     } digest;
     u_long r;
     int i;
     MDInit (&context);
     MDUpdate (&context, string, length);
     MDFinal ((unsigned char *)&digest, &context);
     r = 0;
     for (i = 0; i < 3; i++) {
         r ^= digest.x[i];
     }
     return r;
 }                               /* md_32 */
 /*
  * Return random unsigned 32-bit quantity. Use 'type' argument if you
  * need to generate several different values in close succession.
  */
 u_int32 random32(int type)
 {
     struct {
         int     type;
         struct  timeval tv;
         clock_t cpu;

Schulzrinne, et al Standards Track [Page 67] RFC 1889 RTP January 1996

         pid_t   pid;
         u_long  hid;
         uid_t   uid;
         gid_t   gid;
         struct  utsname name;
     } s;
     gettimeofday(&s.tv, 0);
     uname(&s.name);
     s.type = type;
     s.cpu  = clock();
     s.pid  = getpid();
     s.hid  = gethostid();
     s.uid  = getuid();
     s.gid  = getgid();
     return md_32((char *)&s, sizeof(s));
 }                               /* random32 */

A.7 Computing the RTCP Transmission Interval

 The following function returns the time between transmissions of RTCP
 packets, measured in seconds. It should be called after sending one
 compound RTCP packet to calculate the delay until the next should be
 sent. This function should also be called to calculate the delay
 before sending the first RTCP packet upon startup rather than send
 the packet immediately. This avoids any burst of RTCP packets if an
 application is started at many sites simultaneously, for example as a
 result of a session announcement.
 The parameters have the following meaning:
 rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth that
      will be used for RTCP packets by all members of this session, in
      octets per second. This should be 5% of the "session bandwidth"
      parameter supplied to the application at startup.
 senders: Number of active senders since sending last report, known
      from construction of receiver reports for this RTCP packet.
      Includes ourselves, if we also sent during this interval.
 members: The estimated number of session members, including
      ourselves. Incremented as we discover new session members from
      the receipt of RTP or RTCP packets, and decremented as session
      members leave (via RTCP BYE) or their state is timed out (30
      minutes is recommended). On the first call, this parameter
      should have the value 1.

Schulzrinne, et al Standards Track [Page 68] RFC 1889 RTP January 1996

 we_sent: Flag that is true if we have sent data during the last two
      RTCP intervals. If the flag is true, the compound RTCP packet
      just sent contained an SR packet.
 packet_size: The size of the compound RTCP packet just sent, in
      octets, including the network encapsulation (e.g., 28 octets for
      UDP over IP).
 avg_rtcp_size: Pointer to estimator for compound RTCP packet size;
      initialized and updated by this function for the packet just
      sent, and also updated by an identical line of code in the RTCP
      receive routine for every RTCP packet received from other
      participants in the session.
 initial: Flag that is true for the first call upon startup to
      calculate the time until the first report should be sent.
 #include <math.h>
 double rtcp_interval(int members,
                      int senders,
                      double rtcp_bw,
                      int we_sent,
                      int packet_size,
                      int *avg_rtcp_size,
                      int initial)
 {
     /*
      * Minimum time between RTCP packets from this site (in seconds).
      * This time prevents the reports from `clumping' when sessions
      * are small and the law of large numbers isn't helping to smooth
      * out the traffic.  It also keeps the report interval from
      * becoming ridiculously small during transient outages like a
      * network partition.
      */
     double const RTCP_MIN_TIME = 5.;
     /*
      * Fraction of the RTCP bandwidth to be shared among active
      * senders.  (This fraction was chosen so that in a typical
      * session with one or two active senders, the computed report
      * time would be roughly equal to the minimum report time so that
      * we don't unnecessarily slow down receiver reports.) The
      * receiver fraction must be 1 - the sender fraction.
      */
     double const RTCP_SENDER_BW_FRACTION = 0.25;
     double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
     /*
      * Gain (smoothing constant) for the low-pass filter that

Schulzrinne, et al Standards Track [Page 69] RFC 1889 RTP January 1996

  • estimates the average RTCP packet size (see Cadzow reference).
  • /

double const RTCP_SIZE_GAIN = (1./16.);

     double t;                   /* interval */
     double rtcp_min_time = RTCP_MIN_TIME;
     int n;                      /* no. of members for computation */
     /*
      * Very first call at application start-up uses half the min
      * delay for quicker notification while still allowing some time
      * before reporting for randomization and to learn about other
      * sources so the report interval will converge to the correct
      * interval more quickly.  The average RTCP size is initialized
      * to 128 octets which is conservative (it assumes everyone else
      * is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48
      * SDES CNAME).
      */
     if (initial) {
         rtcp_min_time /= 2;
         *avg_rtcp_size = 128;
     }
     /*
      * If there were active senders, give them at least a minimum
      * share of the RTCP bandwidth.  Otherwise all participants share
      * the RTCP bandwidth equally.
      */
     n = members;
     if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {
         if (we_sent) {
             rtcp_bw *= RTCP_SENDER_BW_FRACTION;
             n = senders;
         } else {
             rtcp_bw *= RTCP_RCVR_BW_FRACTION;
             n -= senders;
         }
     }
     /*
      * Update the average size estimate by the size of the report
      * packet we just sent.
      */
     *avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;
     /*
      * The effective number of sites times the average packet size is
      * the total number of octets sent when each site sends a report.

Schulzrinne, et al Standards Track [Page 70] RFC 1889 RTP January 1996

  • Dividing this by the effective bandwidth gives the time
  • interval over which those packets must be sent in order to
  • meet the bandwidth target, with a minimum enforced. In that
  • time interval we send one report so this time is also our
  • average time between reports.
  • /

t = (*avg_rtcp_size) * n / rtcp_bw;

     if (t < rtcp_min_time) t = rtcp_min_time;
     /*
      * To avoid traffic bursts from unintended synchronization with
      * other sites, we then pick our actual next report interval as a
      * random number uniformly distributed between 0.5*t and 1.5*t.
      */
     return t * (drand48() + 0.5);
 }

A.8 Estimating the Interarrival Jitter

 The code fragments below implement the algorithm given in Section
 6.3.1 for calculating an estimate of the statistical variance of the
 RTP data interarrival time to be inserted in the interarrival jitter
 field of reception reports. The inputs are r->ts , the timestamp from
 the incoming packet, and arrival , the current time in the same
 units. Here s points to state for the source; s->transit holds the
 relative transit time for the previous packet, and s->jitter holds
 the estimated jitter. The jitter field of the reception report is
 measured in timestamp units and expressed as an unsigned integer, but
 the jitter estimate is kept in a floating point. As each data packet
 arrives, the jitter estimate is updated:
     int transit = arrival - r->ts;
     int d = transit - s->transit;
     s->transit = transit;
     if (d < 0) d = -d;
     s->jitter += (1./16.) * ((double)d - s->jitter);
 When a reception report block (to which rr points) is generated for
 this member, the current jitter estimate is returned:
     rr->jitter = (u_int32) s->jitter;
 Alternatively, the jitter estimate can be kept as an integer, but
 scaled to reduce round-off error. The calculation is the same except
 for the last line:
     s->jitter += d - ((s->jitter + 8) >> 4);

Schulzrinne, et al Standards Track [Page 71] RFC 1889 RTP January 1996

 In this case, the estimate is sampled for the reception report as:
     rr->jitter = s->jitter >> 4;

B. Security Considerations

 RTP suffers from the same security liabilities as the underlying
 protocols. For example, an impostor can fake source or destination
 network addresses, or change the header or payload. Within RTCP, the
 CNAME and NAME information may be used to impersonate another
 participant. In addition, RTP may be sent via IP multicast, which
 provides no direct means for a sender to know all the receivers of
 the data sent and therefore no measure of privacy. Rightly or not,
 users may be more sensitive to privacy concerns with audio and video
 communication than they have been with more traditional forms of
 network communication [24]. Therefore, the use of security mechanisms
 with RTP is important. These mechanisms are discussed in Section 9.
 RTP-level translators or mixers may be used to allow RTP traffic to
 reach hosts behind firewalls. Appropriate firewall security
 principles and practices, which are beyond the scope of this
 document, should be followed in the design and installation of these
 devices and in the admission of RTP applications for use behind the
 firewall.

C. Authors' Addresses

 Henning Schulzrinne
 GMD Fokus
 Hardenbergplatz 2
 D-10623 Berlin
 Germany
 EMail: schulzrinne@fokus.gmd.de
 Stephen L. Casner
 Precept Software, Inc.
 21580 Stevens Creek Boulevard, Suite 207
 Cupertino, CA 95014
 United States
 EMail: casner@precept.com

Schulzrinne, et al Standards Track [Page 72] RFC 1889 RTP January 1996

 Ron Frederick
 Xerox Palo Alto Research Center
 3333 Coyote Hill Road
 Palo Alto, CA 94304
 United States
 EMail: frederic@parc.xerox.com
 Van Jacobson
 MS 46a-1121
 Lawrence Berkeley National Laboratory
 Berkeley, CA 94720
 United States
 EMail: van@ee.lbl.gov

Acknowledgments

 This memorandum is based on discussions within the IETF Audio/Video
 Transport working group chaired by Stephen Casner. The current
 protocol has its origins in the Network Voice Protocol and the Packet
 Video Protocol (Danny Cohen and Randy Cole) and the protocol
 implemented by the vat application (Van Jacobson and Steve McCanne).
 Christian Huitema provided ideas for the random identifier generator.

D. Bibliography

 [1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations
     for a new generation of protocols," in SIGCOMM Symposium on
     Communications Architectures and Protocols , (Philadelphia,
     Pennsylvania), pp. 200--208, IEEE, Sept. 1990.  Computer
     Communications Review, Vol. 20(4), Sept. 1990.
 [2] H. Schulzrinne, "Issues in designing a transport protocol for
     audio and video conferences and other multiparticipant real-time
     applications", Work in Progress.
 [3] D. E. Comer, Internetworking with TCP/IP , vol. 1.  Englewood
     Cliffs, New Jersey: Prentice Hall, 1991.
 [4] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
     Sciences Institute, September 1981.
 [5] Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL,
     March 1992.

Schulzrinne, et al Standards Track [Page 73] RFC 1889 RTP January 1996

 [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
     USC/Information Sciences Institute, October 1994.
 [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
     Recommendations for Security", RFC 1750, DEC, Cybercash, MIT,
     December 1994.
 [8] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback
     control for multicast video distribution in the internet," in
     SIGCOMM Symposium on Communications Architectures and Protocols ,
     (London, England), pp. 58--67, ACM, Aug. 1994.
 [9] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of
     multimedia applications based on RTP," Computer Communications ,
     Jan.  1996.
[10] S. Floyd and V. Jacobson, "The synchronization of periodic
     routing messages," in SIGCOMM Symposium on Communications
     Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco,
     California), pp. 33--44, ACM, Sept. 1993.  also in [25].
[11] J. A. Cadzow, Foundations of digital signal processing and data
     analysis New York, New York: Macmillan, 1987.
[12] International Standards Organization, "ISO/IEC DIS 10646-1:1993
     information technology -- universal multiple-octet coded
     character set (UCS) -- part I: Architecture and basic
     multilingual plane," 1993.
[13] The Unicode Consortium, The Unicode Standard New York, New York:
     Addison-Wesley, 1991.
[14] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
     13, RFC 1034, USC/Information Sciences Institute, November 1987.
[15] Mockapetris, P., "Domain Names - Implementation and
     Specification", STD 13, RFC 1035, USC/Information Sciences
     Institute, November 1987.
[16] Braden, R., "Requirements for Internet Hosts - Application and
     Support", STD 3, RFC 1123, Internet Engineering Task Force,
     October 1989.
[17] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot,
     "Address Allocation for Private Internets", RFC 1597, T.J. Watson
     Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.

Schulzrinne, et al Standards Track [Page 74] RFC 1889 RTP January 1996

[18] Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10
     Considered Harmful (Some Practices Shouldn't be Codified)", RFC
     1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon
     Graphics, Inc., July 1994.
[19] Crocker, D., "Standard for the Format of ARPA Internet Text
     Messages", STD 11, RFC 822, UDEL, August 1982.
[20] W. Feller, An Introduction to Probability Theory and its
     Applications, Volume 1 , vol. 1.  New York, New York: John Wiley
     and Sons, third ed., 1968.
[21] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
     Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB
     IRTF PSRG, IETF PEM WG, February 1993.
[22] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level
     network protocols," ACM Computing Surveys , vol. 15, pp. 135--
     171, June 1983.
[23] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
     Laboratory for Computer Science and RSA Data Security, Inc.,
     April 1992.
[24] S. Stubblebine, "Security services for multimedia conferencing,"
     in 16th National Computer Security Conference , (Baltimore,
     Maryland), pp. 391--395, Sept. 1993.
[25] S. Floyd and V. Jacobson, "The synchronization of periodic
     routing messages," IEEE/ACM Transactions on Networking , vol. 2,
     pp.  122-136, April 1994.

Schulzrinne, et al Standards Track [Page 75]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1889.txt · Last modified: 1996/01/23 22:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki