Audio/Video Transport Working Group                         Tmima Koren
Internet Draft                                            Cisco Systems
July 16, 2001                                            Stephen Casner
Expires March 2002                                        Packet Design
draft-ietf-avt-crtp-enhance-02.txt                     John Geevarghese
                                                         Bruce Thompson
                                                          Patrick Ruddy
                                                          Cisco Systems

       Compressing IP/UDP/RTP headers on links with high delay,
                      packet loss and reordering

Status of this memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   Areas, and its Working Groups. Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsolete by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as "work in

   The list of current Internet-Drafts can be accessed at:

   The list of Internet-Draft Shadow Directories can be accessed at:

   This draft is a work item of the IETF Audio/Video Transport working
   group. The working group mailing list is Subscribe via
   the web at

   Copyright (C) The Internet Society (1999-2001). All Rights Reserved.


   This document describes a header compression scheme for point to
   point links with packet loss and long delays. It is based on CRTP,
   the IP/UDP/RTP header compression described in [RFC2508]. CRTP does
   not perform well on such links: packet loss results in context
   corruption and due to the long delay, many more packets are
   discarded before the context is repaired. To correct the behavior of
   CRTP over such links, a few extensions to the protocol are specified
   here. The extensions aim to reduce context corruption by changing
   the way the compressor updates the context at the decompressor:
   updates are repeated and include updates to full and differential
   context parameters. With these extensions, CRTP performs well over
   links with packet loss, packet reordering and long delays.

   The IPCP option 'IP header compression' (described in RFC 2509) is
   also extended to negotiate using the extended CRTP.

1.0 Introduction

   RTP header compression (CRTP) as described in RFC 2508 was designed
   to reduce the header overhead of IP/UDP/RTP datagrams by compressing
   the three headers. The IP/UDP/RTP headers are compressed to 2-4
   bytes most of the time.

   CRTP was designed for reliable point to point links with short
   delays. It does not perform well over links with high rate of packet
   loss, packet reordering and long delays.

   An example of such a link is a PPP session that is tunneled using an
   IP level tunneling protocol such as L2TP. Packets within the tunnel
   are carried by an IP network and hence may get lost and reordered.
   The longer the tunnel, the longer the round trip time.

   Another example is an IP network that uses layer 2 technologies such
   as ATM and Frame Relay for the access portion of the network. Layer
   2 transport networks such as ATM and Frame Relay behave like point
   to point serial links in that they do not reorder packets. In
   addition, Frame Relay and ATM virtual circuits used as IP access
   technologies often have a low bit rate associated with them. These
   virtual circuits differ from low speed serial links in that they may
   span a larger physical distance than a point to point serial link.
   Speed of light delays within the layer 2 transport network will
   result in higher round trip delays between the endpoints of the
   circuit. In addition, congestion within the layer 2 transport
   network may result in an effective drop rate for the virtual circuit
   which is significantly higher than error rates typically experienced
   on point to point serial links.

   CRTP is widely deployed and has relatively low computational
   complexity. It is desirable to extend its usage over such links.
   This can be achieved with a few simple extensions to the protocol.

1.1 CRTP Operation

   During compression of an RTP stream, a session context is defined.
   For each context, the session state is established and shared
   between the compressor and the decompressor. Once the context state
   is established, compressed packets may be sent.

   The context state consists of the full IP/UDP/RTP headers, a few
   first order differential values, a link sequence number, a
   generation number and a delta encoding table.

   The headers part of the context is set by the FULL_HEADER packet
   that always starts a compression session. The first order
   differential values (delta values) are set by sending COMPRESSED_RTP
   packets that include updates to the delta values.

   The context state must be synchronized between compressor and
   decompressor for successful decompression to take place. If the
   context gets out of sync, the decompressor is not able to restore
   the compressed headers accurately. The decompressor invalidates the

   context and sends a CONTEXT_STATE packet to the compressor
   indicating that the context has been corrupted. To resume
   compression, the compressor must reestablish the context.

   During the time the context is corrupted, the decompressor discards
   all the packets received for that context. Since the context repair
   mechanism in CRTP involves feedback from the decompressor, context
   repair takes at least as much time as the round trip time of the
   link. If the round trip time of the link is long, and especially if
   the link bandwidth is high, many packets will be discarded before
   the context is repaired. On such links it is desirable to minimize
   context invalidation.

1.2 How do contexts get corrupted?

   As long as the fields in the combined IP/UDP/RTP headers change as
   expected for the sequence of packets in a session, those headers can
   be compressed, and the decompressor can fully restore the compressed
   headers using the context state. When the headers don't change as
   expected it's necessary to update some of the full or the delta
   values of the context. For example, the RTP timestamp is expected to
   increment by delta RTP timestamp (dT). If silence suppression is
   used, packets are not sent during silence periods. Then when voice
   activity resumes, packets are sent again, but the RTP timestamp is
   incremented by a large value and not by dT. In this case an update
   must be sent.

   If a packet that includes an update to some context state values is
   lost, the state at the decompressor is not updated. The shared state
   is now different at the compressor and decompressor. When the next
   packet arrives at the decompressor, the decompressor will fail to
   restore the compressed headers accurately since the context state at
   the decompressor is different than the state at the compressor.

1.3 Preventing context corruption

   Note that the decompressor fails not when a packet is lost, but when
   the next compressed packet arrives. If the next packet happens to
   include the same context update as in the lost packet, the context
   at the decompressor may be updated successfully and decompression
   may continue uninterrupted. If the lost packet included an update to
   a delta field such as the delta RTP timestamp (dT), the next packet
   can't compensate for the loss since the update of a delta value is
   relative to the previous packet which was lost. But if the update is
   for an absolute value such as the full RTP timestamp or the RTP
   payload type, this update can be repeated in the next packet
   independently of the lost packet. Hence it is useful to be able to
   update the absolute values of the context.

   The next chapter describes several extensions to CRTP that add the
   capability to selectively update absolute values of the context,
   rather than sending a FULL_HEADER packet, in addition to the
   existing updates of the delta values. This enhanced version of CRTP

   is intended to minimize context invalidation and thus improve the
   performance over lossy links with a long round trip time.

1.4 Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. Enhanced CRTP

   This chapter specifies the changes in this enhanced version of CRTP.
   They are:

    - Extensions to the COMPRESSED_UDP packet to allow updating the
      differential RTP values in the decompressor context and to
      selectively update the absolute IP ID and RTP values. This
      allows context sync to be maintained even with some packet

    - A 'headers checksum' to be inserted by the compressor and
      removed by the decompressor when the UDP checksum is not
      present so that validation of the decompressed headers is
      still possible. This allows the decompressor to verify that
      context sync has not been lost after a packet loss.

   An algorithm is then described to use these changes with repeated
   updates to achieve robust operation over links with packet loss and
   long delay.

2.1 Extended COMPRESSED_UDP packet

   It is possible to accommodate some packet loss between the
   compressor and decompressor using the "twice" algorithm in RFC 2508
   so long as the context remains in sync. This requires reliably
   communicating both the absolute value and the delta value whenever
   the delta value changes. For many environments, sufficient
   reliability can be achieved by repeating the update with each of
   several successive packets.

   The COMPRESSED_UDP packet satisfies the need to communicate the
   absolute values of the differential RTP fields, but it is specified
   in RFC 2508 to reset the delta RTP timestamp. That limitation can be
   removed with the following simple change: RFC 2508 describes the
   format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except
   that the M, S and T bits are always 0 and the corresponding delta
   fields are never included.  This enhanced version of CRTP changes
   that specification to say that the T bit may be nonzero to indicate
   that the delta RTP timestamp is included explicitly rather than
   being reset to zero.

   A second change adds another byte of flag bits to the COMPRESSED_UDP
   packet to allow only selected individual uncompressed fields of the

   RTP header to be included in the packet rather than carrying the
   full RTP header as part of the UDP data. The additional flags do
   increase computational complexity somewhat, but the corresponding
   increase in bit efficiency is important when the differential field
   updates are communicated multiple times in successive COMPRESSED_UDP
   packets.  With this change, there are flag bits to indicate
   inclusion of both delta values and absolute values, so the flag
   nomenclature is changed. The original S, T, I bits which indicate
   the inclusion of deltas are renamed dS, dT, dI, and the inclusion of
   absolute values is indicated by S, T, I. The M bit is absolute as
   before. A new flag P indicates inclusion of the absolute RTP payload
   type value and, as in the COMPRESSED_RTP packet, a four-bit CC field
   copies the absolute value of the CC field in the RTP header.

   The last of the three changes to the COMPRESSED_UDP packet deals
   with updating the IP ID field.  For this field, the COMPRESSED_UDP
   packet as specified in RFC 2508 can already convey a new value for
   the delta IP ID, but not the absolute value which is only conveyed
   by the FULL_HEADER packet. Therefore, a new flag I is added to the
   COMPRESSED_UDP packet to indicate inclusion of the absolute IP ID
   value.  The I flag replaces the dS flag which is not needed in the
   COMPRESSED_UDP packet since the delta RTP sequence number always
   remains 1 in the decompressor context and hence does not need to be

   The format of the flags/sequence byte for the original
   COMPRESSED_UDP packet is shown here for reference:

               | 0 | 0 | 0 |dI | link sequence |

   The new definition of the flags/sequence byte plus an extension
   flags byte for the COMPRESSED_UDP packet is as follows, where the
   new F flag indicates the inclusion of the extension flags byte:

               | F | I |dT |dI | link sequence |
               : M : S : T : P :      CC       :  (if F = 1)

               dI = delta IP ID
               dT = delta RTP timestamp
               I  = absolute IP ID
               F  = additional flags byte
               M  = marker bit
               S  = absolute RTP sequence number
               T  = absolute RTP timestamp
               P  = RTP payload type
               CC = number of CSRC identifiers

   When F=0, there is only one flags byte, and the only available flags
   are: dI, dT and I. In this case the packet includes the full RTP
   header. As in RFC 2508, if dI=0, the decompressor does not change
   deltaI. If dT=0, the decompressor sets deltaT to 0.

   Some example packet formats will illustrate the use of the new
   flags.  First, when F=0, the 'traditional' COMPRESSED_UDP packet
   which carries the full RTP header as part of the UDP data:

                0   1   2   3   4   5   6   7
              :   msb of session context ID   :  (if 16-bit CID)
              |   lsb of session context ID   |
              |F=0| I |dT |dI | link sequence |
              :                               :
              +         UDP checksum          +  (if nonzero in context)
              :                               :
              :                               :
              +        "RANDOM" fields        +  (if encapsulated)
              :                               :
              :         delta IPv4 ID         :  (if dI = 1)
              :      delta RTP timestamp      :  (if dT = 1)
              :                               :
              +           IPv4 ID             +  (if I = 1)
              :                               :
              |           UDP data            |
              :   (uncompressed RTP header)   :

   When F=1, there is an additional flags byte and the available flags
   are: dI, dT, I, M, S, T, P, CC. In this case the packet does not
   include the full RTP header, but includes selected fields from the
   RTP header as specified by the flags. As in RFC 2508, if dI=0 the
   decompressor does not change deltaI. However, in contrast to RFC
   2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the
   context (DOES NOT set deltaT to 0).

   An enhanced COMPRESSED_UDP packet is similar in contents and
   behavior to a COMPRESSED_RTP packet, but it has more flag bits, some
   of which correspond to absolute values for RTP header fields.

   COMPRESSED_UDP with individual RTP fields, when F=1:

                0   1   2   3   4   5   6   7
              :   msb of session context ID   :  (if 16-bit CID)
              |   lsb of session context ID   |
              |F=1| I |dT |dI | link sequence |
              | M | S | T | P |      CC       |
              :                               :
              +         UDP checksum          +  (if nonzero in context)
              :                               :
              :                               :
              :        "RANDOM" fields        :  (if encapsulated)
              :                               :
              :         delta IPv4 ID         :  (if dI = 1)
              :      delta RTP timestamp      :  (if dT = 1)
              :                               :
              +           IPv4 ID             +  (if I = 1)
              :                               :
              :                               :
              +     RTP sequence number       +  (if S = 1)
              :                               :
              :                               :
              +                               +
              :                               :
              +         RTP timestamp         +  (if T = 1)
              :                               :
              +                               +
              :                               :
              :       RTP payload type        :  (if P = 1)
              :                               :
              :           CSRC list           :  (if CC > 0)
              :                               :
              :                               :
              :      RTP header extension     :  (if X set in context)
              :                               :
              |                               |
              /           RTP data            /
              /                               /
              |                               |
              :            padding            :  (if P set in context)

   Usage for the enhanced COMPRESSED_UDP packet:

   It is useful for the compressor to periodically refresh the state of
   the decompressor to avoid having the decompressor send CONTEXT_STATE
   messages in the case of unrecoverable packet loss. Using the flags
   F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the
   context parameters.

   When compression is done over a lossy link with a long round trip
   delay, we want to minimize context invalidation. If the delta values
   are changing frequently, the context might get invalidated often. In
   such cases the compressor may choose to always send absolute values
   and never delta values, using COMPRESSED_UDP packets with the flags
   F=1, and any of S, T, I as necessary.

2.2 CRTP Headers Checksum

   RFC 2508, in Section 3.3.5, describes how the UDP checksum may be
   used to validate header reconstruction periodically or when the
   'twice' algorithm is used. When a UDP checksum is not present (has
   value zero) in a stream, such validation would not be possible. To
   cover that case, this enhanced CRTP provides an option whereby the
   compressor MAY replace the null UDP checksum with a 16-bit headers
   checksum (HDRCKSUM) which is subsequently removed by the
   decompressor after validation.

   A new flag C in the FULL_HEADER packet, as specified below,
   indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP
   packets sent in that context will have HDRCKSUM inserted. The
   compressor MAY set the C flag when UDP packet carried in the
   FULL_HEADER packet originally contained a checksum value of zero.
   If the C flag is set, the FULL_HEADER packet itself MUST also have
   the HDRCKSUM inserted. If a packet in the same stream subsequently
   arrives at the compressor with a UDP checksum present, then a new
   FULL_HEADER packet MUST be sent with the flag cleared to re-
   establish the context.

   The HDRCKSUM is calculated in the same way as a UDP checksum except
   that it does not cover all of the UDP data. That is, the HDRCKSUM is
   the 16-bit one's complement of the one's complement sum of the
   pseudo-IP header (as defined for UDP), the UDP header, and the first
   12 bytes of the UDP data which are assumed to hold the fixed part of
   an RTP header. The extended part of the RTP header and the RTP data
   will not be included in the HDRCKSUM. The HDRCKSUM is placed in the
   COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would
   have been. The decompressor MUST zero out the UDP checksum field in
   the reconstructed packets.

   For a non-RTP context, there may fewer than 12 UDP data bytes
   present. The IP and UDP headers may still be compressed into a
   COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated
   over the pseudo-IP header, the UDP header, and the UDP data bytes
   that are present. If the number of data bytes is odd, then a zero
   padding byte is appended for the purpose of calculating the
   checksum, but not transmitted.

   The HDRCKSUM does not validate the RTP data. If the link layer is
   configured to deliver packets without checking for errors, then
   errors in the RTP data will not be detected. Over such links, the
   compressor SHOULD add the HDRCKSUM if a UDP checksum is not present,
   and the decompressor SHOULD validate each reconstructed packet to
   make sure that at least the headers are correct. This ensures that
   the packet will be delivered to the right destination. If only
   HDRCKSUM is available, the RTP data will be delivered even if it
   includes errors. This might be a desirable feature for applications
   that can tolerate errors in the RTP data. The same holds for the
   extended part of the RTP header.

   Here is the format of the FULL_HEADER length fields with the new
   flag C to indicate that a header checksum will be added in

   For 8-bit context ID:

   |0|1| Generation|      CID      |  First length field

   |            0        |C|  seq  |  Second length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

   For 16-bit context ID:

   |1|1| Generation| 0   |C|  seq  |  First length field
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C=1: HDRCKSUM will be added

   |              CID              |  Second length field

2.3 CRTP operation in 'N' mode

   The 'N' mode is a method of operation where the compressor tries to
   keep the decompressor in sync by sending changes multiple times. The
   'N' is a number that represents the quality of the link between the
   hosts, and it means that the probability of more than N adjacent
   packets getting lost on this link is small. For every change in a
   full value or a delta value, if the compressor includes the change
   in N+1 consecutive packets, there is a very good chance that the
   compressor and decompressor can stay in sync using the 'twice'
   algorithm. CONTEXT_STATE packets should also be repeated N+1 times
   (using the same sequence number). It is up to the implementation to
   find a scheme to derive an appropriate N for a link.

   This scheme may be used at any time and does not require

   Some short notations:


   Here is an example to demonstrate the usage of the N scheme.
   In this stream the audio codec sends a sample every 10 milliseconds
   The first talkspurt is 1 second long. Then there are 2 seconds of
   silence, then another talkspurt. We also assume in this example that
   the IP ID field does not increment at a constant rate because the
   host is generating other uncorrelated traffic streams at the same
   time and therefore the delta IP ID changes for each packet.

   When there is no loss on the link, we can use COMPRESSED_RTP packets
   in the following sequence:

   seq Time pkt    updates and comments
    #       type
   1   10   FH
   2   20   CR     dI dT=10
   3   30   CR     dI
   4   40   CR     dI
   100 1000 CR     dI

   101 3010 CR     dI dT=2010
   102 3020 CR     dI dT=10
   103 3030 CR     dI
   104 3040 CR     dI

   In the above sequence, if a packet is lost we cannot recover
   ('twice' will not work due to the unpredictable IP ID) and the
   context must be invalidated.

   Here is the same example in 'N' mode, when N=2. Note that the
   compressor only sends the absolute IP ID (I) and not the delta IP ID

   seq Time pkt  CU flags            updates and comments
    #       type F I dT dI M S T P
   1   10   FH
   2   20   FH                             repeat constant fields
   3   30   FH                             repeat constant fields
   4   40   CU   1 1  1  0 M 0 1 0   I T=40 dT=10
   5   50   CU   1 1  1  0 M 0 1 0   I T=50 dT=10 repeat update T & dT
   6   60   CU   1 1  1  0 M 0 1 0   I T=60 dT=10 repeat update T & dT
   7   70   CU   1 1  0  0 M 0 0 0   I
   8   80   CU   1 1  0  0 M 0 0 0   I
   100 1000 CU   1 1  0  0 M 0 0 0   I

   101 3010 CU   1 1  0  0 M 0 1 0   I T=3010  T changed, keep deltas
   102 3020 CU   1 1  0  0 M 0 1 0   I T=3020  repeat updated T
   103 3030 CU   1 1  0  0 M 0 1 0   I T=3030  repeat updated T

   104 3040 CU   1 1  0  0 M 0 0 0   I
   105 3050 CU   1 1  0  0 M 0 0 0   I

   This second example is the same sequence, but assuming the delta IP
   ID is constant.  First the basic CRTP for a lossless link:

   seq Time pkt    updates and comments
    #       type
   1   10   FH
   2   20   CR     dI dT=10
   3   30   CR
   4   40   CR
   100 1000 CR

   101 3010 CR     dT=2010
   102 3020 CR     dT=10
   103 3030 CR
   104 3040 CR

   For the equivalent sequence in 'N' mode, the more efficient
   COMPRESSED_RTP packet can still be used once the deltas are all

   seq Time pkt  CU flags            updates and comments
    #       type F I dT dI M S T P
   1   10   FH
   2   20   FH                             repeat constant fields
   3   30   FH                             repeat constant fields
   4   40   CU   1 1  1  1 M 0 1 0   I dI T=40 dT=10
   5   50   CU   1 1  1  1 M 0 1 0   I dI T=50 dT=10  repeat updates
   6   60   CU   1 1  1  1 M 0 1 0   I dI T=60 dT=10  repeat updates
   7   70   CR
   8   80   CR
   100 1000 CR

   101 3010 CU   1 0  0  0 M 0 1 0   T=3010  T changed, keep deltas
   102 3020 CU   1 0  0  0 M 0 1 0   T=3020  repeat updated T
   103 3030 CU   1 0  0  0 M 0 1 0   T=3030  repeat updated T
   104 3040 CR
   105 3050 CR

3. Negotiating usage of enhanced-CRTP

   RFC 2509 [IPCPHC] specifies how the use of CRTP is negotiated on PPP
   links using the IP Compression Protocol option of IPCP:

         IPCP option 2: IP compression protocol
         protocol 0x61: indicates RFC 2507 header compression
         sub-option 1:  enables use of COMPRESSED_RTP, COMPRESSED_UDP
                        and CONTEXT_STATE as specified in RFC 2508

   To use the enhanced CRTP defined in this document, a new sub-option
   2 is added.  The new sup-option 2 is negotiated instead of, not in
   addition to, sub-option 1.


      Enable use of Protocol Identifiers COMPRESSED_RTP and
      CONTEXT_STATE as specified in RFC 2508 plus COMPRESSED_UDP with
      additional flags as defined in this document, and enable use of
      the C flag with the FULL_HEADER Protocol Identifier as defined in
      this document to indicate use of HDRCKSUM with COMPRESSED_RTP and
      COMPRESSED_UDP packets.

                0                   1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               |     Type      |    Length     |



4. Security Considerations

   Because encryption eliminates the redundancy that this compression
   scheme tries to exploit, there is some inducement to forego
   encryption in order to achieve operation over a low-bandwidth link.
   However, for those cases where encryption of data and not headers is
   satisfactory, RTP does specify an alternative encryption method in
   which only the RTP payload is encrypted and the headers are left in
   the clear. That would allow compression to still be applied.

   A malfunctioning or malicious compressor could cause the
   decompressor to reconstitute packets that do not match the original
   packets but still have valid IP, UDP and RTP headers and possibly
   even valid UDP check-sums.  Such corruption may be detected with
   end-to-end authentication and integrity mechanisms which will not be
   affected by the compression. Constant portions of authentication
   headers will be compressed as described in [IPHCOMP].

   No authentication is performed on the CONTEXT_STATE control packet
   sent by this protocol.  An attacker with access to the link between

   the decompressor and compressor could inject false CONTEXT_STATE
   packets and cause compression efficiency to be reduced, probably
   resulting in congestion on the link.  However, an attacker with
   access to the link could also disrupt the traffic in many other

   A potential denial-of-service threat exists when using compression
   techniques that have non-uniform receiver-end computational load.
   The attacker can inject pathological datagrams into the stream which
   are complex to decompress and cause the receiver to be overloaded
   and degrading processing of other streams.  However, this
   compression does not exhibit any significant non-uniformity.

5. Acknowledgements

   The authors would like to thank Van Jacobson, co-author of RFC 2508,
   and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and
   Stephen Pink. The authors would also like to thank Dana Blair,
   Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama,
   Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, and
   Dan Wing.

6. References

   [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
   Low-Speed Serial Links", RFC2508, February 1999.

   [IPHCOMP] M. Degermark, B. Nordgren, S. Pink,
   "IP Header Compression", RFC2507, February 1999.

   [IPCPHC] M. Engan, S. Casner, C. Bormann,
   "IP Header Compression over PPP", RFC2509, February 1999.

   [KEYW] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC2119, BCP 14, March 1997.

   [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
   "RTP: A Transport Protocol for Real-Time Applications", RFC1889,
   January 1996.

7. Authors' Addresses

   Tmima Koren
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America

   Stephen L. Casner
   Packet Design
   2465 Latham Street, Third Floor
   Mountain View, CA  94040
   United States of America

   John Geevarghese
   Telseon Inc.
   480 S. California
   Palo Alto, CA  94306
   United States of America

   Bruce Thompson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America

   Patrick Ruddy
   Cisco Systems, Inc.
   3rd Floor, 96 Commercial Street
   EH6 6LX

8. Copyright

   Copyright (C) The Internet Society 1999-2001.  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an