home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2198 < prev    next >
Text File  |  1997-09-15  |  25KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        C. Perkins
  8. Request for Comments: 2198                                  I. Kouvelas
  9. Category: Standards Track                                     O. Hodson
  10.                                                              V. Hardman
  11.                                               University College London
  12.                                                              M. Handley
  13.                                                                     ISI
  14.                                                              J.C. Bolot
  15.                                                          A. Vega-Garcia
  16.                                                        S. Fosse-Parisis
  17.                                                  INRIA Sophia Antipolis
  18.                                                          September 1997
  19.  
  20.  
  21.                   RTP Payload for Redundant Audio Data
  22.  
  23. Status of this Memo
  24.  
  25.    This document specifies an Internet standards track protocol for the
  26.    Internet community, and requests discussion and suggestions for
  27.    improvements.  Please refer to the current edition of the "Internet
  28.    Official Protocol Standards" (STD 1) for the standardization state
  29.    and status of this protocol.  Distribution of this memo is unlimited.
  30.  
  31. Abstract
  32.  
  33.    This document describes a payload format for use with the real-time
  34.    transport protocol (RTP), version 2, for encoding redundant audio
  35.    data.  The primary motivation for the scheme described herein is the
  36.    development of audio conferencing tools for use with lossy packet
  37.    networks such as the Internet Mbone, although this scheme is not
  38.    limited to such applications.
  39.  
  40. 1  Introduction
  41.  
  42.    If multimedia conferencing is to become widely used by the Internet
  43.    Mbone community, users must perceive the quality to be sufficiently
  44.    good for most applications.  We have identified a number of problems
  45.    which impair the quality of conferences, the most significant of
  46.    which is packet loss.  This is a persistent problem, particularly
  47.    given the increasing popularity, and therefore increasing load, of
  48.    the Internet.  The disruption of speech intelligibility even at low
  49.    loss rates which is currently experienced may convince a whole
  50.    generation of users that multimedia conferencing over the Internet is
  51.    not viable.  The addition of redundancy to the data stream is offered
  52.    as a solution [1].  If a packet is lost then the missing information
  53.    may be reconstructed at the receiver from the redundant data that
  54.    arrives in the following packet(s), provided that the average number
  55.  
  56.  
  57.  
  58. Perkins, et. al.            Standards Track                     [Page 1]
  59.  
  60. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  61.  
  62.  
  63.    of consecutively lost packets is small.  Recent work [4,5] shows that
  64.    packet loss patterns in the Internet are such that this scheme
  65.    typically functions well.
  66.  
  67.    This document describes an RTP payload format for the transmission of
  68.    audio data encoded in such a redundant fashion.  Section 2 presents
  69.    the requirements and motivation leading to the definition of this
  70.    payload format, and does not form part of the payload format
  71.    definition.  Sections 3 onwards define the RTP payload format for
  72.    redundant audio data.
  73.  
  74. 2  Requirements/Motivation
  75.  
  76.    The requirements for a redundant encoding scheme under RTP are as
  77.    follows:
  78.  
  79.      o Packets have to carry a primary encoding and one or more
  80.        redundant encodings.
  81.  
  82.      o As a multitude of encodings may be used for redundant
  83.        information, each block of redundant encoding has to have an
  84.        encoding type identifier.
  85.  
  86.      o As the use of variable size encodings is desirable, each encoded
  87.        block in the packet has to have a length indicator.
  88.  
  89.      o The RTP header provides a timestamp field that corresponds to
  90.        the time of creation of the encoded data.  When redundant
  91.        encodings are used this timestamp field can refer to the time of
  92.        creation of the primary encoding data.  Redundant blocks of data
  93.        will correspond to different time intervals than the primary
  94.        data, and hence each block of redundant encoding will require its
  95.        own timestamp.  To reduce the number of bytes needed to carry the
  96.        timestamp, it can be encoded as the difference of the timestamp
  97.        for the redundant encoding and the timestamp of the primary.
  98.  
  99.    There are two essential means by which redundant audio may be added
  100.    to the standard RTP specification:  a header extension may hold the
  101.    redundancy, or one, or more, additional payload types may be defined.
  102.  
  103.    Including all the redundancy information for a packet in a header
  104.    extension would make it easy for applications that do not implement
  105.    redundancy to discard it and just process the primary encoding data.
  106.    There are, however, a number of disadvantages with this scheme:
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Perkins, et. al.            Standards Track                     [Page 2]
  115.  
  116. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  117.  
  118.  
  119.      o There is a large overhead from the number of bytes needed for
  120.        the extension header (4) and the possible padding that is needed
  121.        at the end of the extension to round up to a four byte  boundary
  122.        (up to 3 bytes).  For many applications this overhead is
  123.        unacceptable.
  124.  
  125.      o Use of the header extension limits applications to a single
  126.        redundant encoding, unless further structure is introduced into
  127.        the extension.  This would result in further overhead.
  128.  
  129.    For these reasons, the use of RTP header extension to hold redundant
  130.    audio encodings is disregarded.
  131.  
  132.    The RTP profile for audio and video conferences [3] lists a set of
  133.    payload types and provides for a dynamic range of 32 encodings that
  134.    may be defined through a conference control protocol.  This leads to
  135.    two possible schemes for assigning additional RTP payload types for
  136.    redundant audio applications:
  137.  
  138.      1.A dynamic encoding scheme may be defined, for each combination
  139.        of primary/redundant payload types, using the RTP dynamic payload
  140.        type range.
  141.  
  142.      2.A single fixed payload type may be defined to represent a packet
  143.        with redundancy.  This may then be assigned to either a static
  144.        RTP payload type, or the payload type for this may be assigned
  145.        dynamically.
  146.  
  147.    It is possible to define a set of payload types that signify a
  148.    particular combination of primary and secondary encodings for each of
  149.    the 32 dynamic payload types provided.  This would be a slightly
  150.    restrictive yet feasible solution for packets with a single block of
  151.    redundancy as the number of possible combinations is not too large.
  152.    However the need for multiple blocks of redundancy greatly increases
  153.    the number of encoding combinations and makes this solution not
  154.    viable.
  155.  
  156.    A modified version of the above solution could be to decide prior to
  157.    the beginning of a conference on a set a 32 encoding combinations
  158.    that will be used for the duration of the conference.  All tools in
  159.    the conference can be initialized with this working set of encoding
  160.    combinations.  Communication of the working set could be made through
  161.    the use of an external, out of band, mechanism.  Setup is complicated
  162.    as great care needs to be taken in starting tools with identical
  163.    parameters.  This scheme is more efficient as only one byte is used
  164.    to identify combinations of encodings.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Perkins, et. al.            Standards Track                     [Page 3]
  171.  
  172. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  173.  
  174.  
  175.    It is felt that the complication inherent in distributing the mapping
  176.    of payload types onto combinations of redundant data preclude the use
  177.    of this mechanism.
  178.  
  179.    A more flexible solution is to have a single payload type which
  180.    signifies a packet with redundancy. That packet then becomes a
  181.    container, encapsulating multiple payloads into a single RTP packet.
  182.    Such a scheme is flexible, since any amount of redundancy may be
  183.    encapsulated within a single packet.  There is, however, a small
  184.    overhead since each encapsulated payload must be preceded by a header
  185.    indicating the type of data enclosed.  This is the preferred
  186.    solution, since it is both flexible, extensible, and has a relatively
  187.    low overhead.  The remainder of this document describes this
  188.    solution.
  189.  
  190. 3  Payload Format Specification
  191.  
  192.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  193.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  194.    document are to be interpreted as described in RFC2119 [7].
  195.  
  196.    The assignment of an RTP payload type for this new packet format is
  197.    outside the scope of this document, and will not be specified here.
  198.    It is expected that the RTP profile for a particular class of
  199.    applications will assign a payload type for this encoding, or if that
  200.    is not done then a payload type in the dynamic range shall be chosen.
  201.  
  202.    An RTP packet containing redundant data shall have a standard RTP
  203.    header, with payload type indicating redundancy.  The other fields of
  204.    the RTP header relate to the primary data block of the redundant
  205.    data.
  206.  
  207.    Following the RTP header are a number of additional headers, defined
  208.    in the figure below, which specify the contents of each of the
  209.    encodings carried by the packet.  Following these additional headers
  210.    are a number of data blocks, which contain the standard RTP payload
  211.    data for these encodings.  It is noted that all the headers are
  212.    aligned to a 32 bit boundary, but that the payload data will
  213.    typically not be aligned.  If multiple redundant encodings are
  214.    carried in a packet, they should correspond to different time
  215.    intervals:  there is no reason to include multiple copies of data for
  216.    a single time interval within a packet.
  217.  
  218.     0                   1                    2                   3
  219.     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
  220.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  221.    |F|   block PT  |  timestamp offset         |   block length    |
  222.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  223.  
  224.  
  225.  
  226. Perkins, et. al.            Standards Track                     [Page 4]
  227.  
  228. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  229.  
  230.  
  231.    The bits in the header are specified as follows:
  232.  
  233.  
  234.    F: 1 bit First bit in header indicates whether another header block
  235.        follows.  If 1 further header blocks follow, if 0 this is the
  236.        last header block.
  237.  
  238.    block PT: 7 bits RTP payload type for this block.
  239.  
  240.    timestamp offset:  14 bits Unsigned offset of timestamp of this block
  241.        relative to timestamp given in RTP header.  The use of an unsigned
  242.        offset implies that redundant data must be sent after the primary
  243.        data, and is hence a time to be subtracted from the current
  244.        timestamp to determine the timestamp of the data for which this
  245.        block is the redundancy.
  246.  
  247.    block length:  10 bits Length in bytes of the corresponding data
  248.        block excluding header.
  249.  
  250.    It is noted that the use of an unsigned timestamp offset limits the
  251.    use of redundant data slightly:  it is not possible to send
  252.    redundancy before the primary encoding.  This may affect schemes
  253.    where a low bandwidth coding suitable for redundancy is produced
  254.    early in the encoding process, and hence could feasibly be
  255.    transmitted early.  However, the addition of a sign bit would
  256.    unacceptably reduce the range of the timestamp offset, and increasing
  257.    the size of the field above 14 bits limits the block length field.
  258.    It seems that limiting redundancy to be transmitted after the primary
  259.    will cause fewer problems than limiting the size of the other fields.
  260.  
  261.    The timestamp offset for a redundant block is measured in the same
  262.    units as the timestamp of the primary encoding (ie:  audio samples,
  263.    with the same clock rate as the primary).  The implication of this is
  264.    that the redundant encoding MUST be sampled at the same rate as the
  265.    primary.
  266.  
  267.    It is further noted that the block length and timestamp offset are 10
  268.    bits, and 14 bits respectively; rather than the more obvious 8 and 16
  269.    bits.  Whilst such an encoding complicates parsing the header
  270.    information slightly, and adds some additional processing overhead,
  271.    there are a number of problems involved with the more obvious choice:
  272.    An 8 bit block length field is sufficient for most, but not all,
  273.    possible encodings:  for example 80ms PCM and DVI audio packets
  274.    comprise more than 256 bytes, and cannot be encoded with a single
  275.    byte length field.  It is possible to impose additional structure on
  276.    the block length field (for example the high bit set could imply the
  277.    lower 7 bits code a length in words, rather than bytes), however such
  278.    schemes are complex.  The use of a 10 bit block length field retains
  279.  
  280.  
  281.  
  282. Perkins, et. al.            Standards Track                     [Page 5]
  283.  
  284. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  285.  
  286.  
  287.    simplicity and provides an enlarged range, at the expense of a
  288.    reduced range of timestamp values.
  289.  
  290.    The primary encoding block header is placed last in the packet.  It
  291.    is therefore possible to omit the timestamp and block-length fields
  292.    from the header of this block, since they may be determined from the
  293.    RTP header and overall packet length.  The header for the primary
  294.    (final) block comprises only a zero F bit, and the block payload type
  295.    information, a total of 8 bits.  This is illustrated in the figure
  296.    below:
  297.  
  298.                       0 1 2 3 4 5 6 7
  299.                      +-+-+-+-+-+-+-+-+
  300.                      |0|   Block PT  |
  301.                      +-+-+-+-+-+-+-+-+
  302.  
  303.    The final header is followed, immediately, by the data blocks, stored
  304.    in the same order as the headers.  There is no padding or other
  305.    delimiter between the data blocks, and they are typically not 32 bit
  306.    aligned.  Again, this choice was made to reduce bandwidth overheads,
  307.    at the expense of additional decoding time.
  308.  
  309.    The choice of encodings used should reflect the bandwidth
  310.    requirements of those encodings.  It is expected that the redundant
  311.    encoding shall use significantly less bandwidth that the primary
  312.    encoding:  the exception being the case where the primary is very
  313.    low-bandwidth and has high processing requirement, in which case a
  314.    copy of the primary MAY be used as the redundancy.  The redundant
  315.    encoding MUST NOT be higher bandwidth than the primary.
  316.  
  317.    The use of multiple levels of redundancy is rarely necessary.
  318.    However, in those cases which require it, the bandwidth required by
  319.    each level of redundancy is expected to be significantly less than
  320.    that of the previous level.
  321.  
  322. 4  Limitations
  323.  
  324.    The RTP marker bit is not preserved for redundant data blocks.  Hence
  325.    if the primary (containing this marker) is lost, the marker is lost.
  326.    It is believed that this will not cause undue problems:  even if the
  327.    marker bit was transmitted with the redundant information, there
  328.    would still be the possibility of its loss, so applications would
  329.    still have to be written with this in mind.
  330.  
  331.    In addition, CSRC information is not preserved for redundant data.
  332.    The CSRC data in the RTP header of a redundant audio packet relates
  333.    to the primary only.  Since CSRC data in an audio stream is expected
  334.    to change relatively infrequently, it is recommended that
  335.  
  336.  
  337.  
  338. Perkins, et. al.            Standards Track                     [Page 6]
  339.  
  340. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  341.  
  342.  
  343.    applications which require this information assume that the CSRC data
  344.    in the RTP header may be applied to the reconstructed redundant data.
  345.  
  346. 5  Relation to SDP
  347.  
  348.    When a redundant payload is used, it may need to be bound to an RTP
  349.    dynamic payload type.  This may be achieved through any out-of-band
  350.    mechanism, but one common way is to communicate this binding using
  351.    the Session Description Protocol (SDP) [6].  SDP has a mechanism for
  352.    binding a dynamic payload types to particular codec, sample rate, and
  353.    number of channels using the "rtpmap" attribute.  An example of its
  354.    use (using the RTP audio/video profile [3]) is:
  355.  
  356.        m=audio 12345 RTP/AVP 121 0 5
  357.        a=rtpmap:121 red/8000/1
  358.  
  359.    This specifies that an audio stream using RTP is using payload types
  360.    121 (a dynamic payload type), 0 (PCM u-law) and 5 (DVI). The "rtpmap"
  361.    attribute is used to bind payload type 121 to codec "red" indicating
  362.    this codec is actually a redundancy frame, 8KHz, and monaural.  When
  363.    used with SDP, the term "red" is used to indicate the redundancy
  364.    format discussed in this document.
  365.  
  366.    In this case the additional formats of PCM and DVI are specified.
  367.    The receiver must therefore be prepared to use these formats.  Such a
  368.    specification means the sender will send redundancy by default, but
  369.    also may send PCM or DVI. However, with a redundant payload we
  370.    additionally take this to mean that no codec other than PCM or DVI
  371.    will be used in the redundant encodings.  Note that the additional
  372.    payload formats defined in the "m=" field may themselves be dynamic
  373.    payload types, and if so a number of additional "a=" attributes may
  374.    be required to describe these dynamic payload types.
  375.  
  376.    To receive a redundant stream, this is all that is required.  However
  377.    to send a redundant stream, the sender needs to know which codecs are
  378.    recommended for the primary and secondary (and tertiary, etc)
  379.    encodings.  This information is specific to the redundancy format,
  380.    and is specified using an additional attribute "fmtp" which conveys
  381.    format-specific information.  A session directory does not parse the
  382.    values specified in an fmtp attribute but merely hands it to the
  383.    media tool unchanged.  For redundancy, we define the format
  384.    parameters to be a slash "/" separated list of RTP payload types.
  385.  
  386.    Thus a complete example is:
  387.  
  388.        m=audio 12345 RTP/AVP 121 0 5
  389.        a=rtpmap:121 red/8000/1
  390.        a=fmtp:121 0/5
  391.  
  392.  
  393.  
  394. Perkins, et. al.            Standards Track                     [Page 7]
  395.  
  396. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  397.  
  398.  
  399.    This specifies that the default format for senders is redundancy with
  400.    PCM as the primary encoding and DVI as the secondary encoding.
  401.    Encodings cannot be specified in the fmtp attribute unless they are
  402.    also specified as valid encodings on the media ("m=") line.
  403.  
  404. 6  Security Considerations
  405.  
  406.    RTP packets containing redundant information are subject to the
  407.    security considerations discussed in the RTP specification [2], and
  408.    any appropriate RTP profile (for example [3]).  This implies that
  409.    confidentiality of the media streams is achieved by encryption.
  410.    Encryption of a redundant data stream may occur in two ways:
  411.  
  412.      1.The entire stream is to be secured, and all participants are
  413.        expected to have keys to decode the entire stream.  In this case,
  414.        nothing special need be done, and encryption is performed in the
  415.        usual manner.
  416.  
  417.      2.A portion of the stream is to be encrypted with a different
  418.        key to the remainder.  In this case a redundant copy of the last
  419.        packet of that portion cannot be sent, since there is no
  420.        following packet which is encrypted with the correct key in which
  421.        to send it.  Similar limitations may occur when
  422.        enabling/disabling encryption.
  423.  
  424.    The choice between these two is a matter for the encoder only.
  425.    Decoders can decrypt either form without modification.
  426.  
  427.    Whilst the addition of low-bandwidth redundancy to an audio stream is
  428.    an effective means by which that stream may be protected against
  429.    packet loss, application designers should be aware that the addition
  430.    of large amounts of redundancy will increase network congestion, and
  431.    hence packet loss, leading to a worsening of the problem which the
  432.    use of redundancy was intended to solve.  At its worst, this can lead
  433.    to excessive network congestion and may constitute a denial of
  434.    service attack.
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Perkins, et. al.            Standards Track                     [Page 8]
  451.  
  452. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  453.  
  454.  
  455. 7  Example Packet
  456.  
  457.    An RTP audio data packet containing a DVI4 (8KHz) primary, and a
  458.    single block of redundancy encoded using 8KHz LPC (both 20ms
  459.    packets), as defined in the RTP audio/video profile [3] is
  460.    illustrated:
  461.  
  462.     0                   1                    2                   3
  463.     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
  464.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  465.    |V=2|P|X| CC=0  |M|      PT     |   sequence number of primary  |
  466.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  467.    |              timestamp  of primary encoding                   |
  468.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  469.    |           synchronization source (SSRC) identifier            |
  470.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  471.    |1| block PT=7  |  timestamp offset         |   block length    |
  472.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  473.    |0| block PT=5  |                                               |
  474.    +-+-+-+-+-+-+-+-+                                               +
  475.    |                                                               |
  476.    +                LPC encoded redundant data (PT=7)              +
  477.    |                (14 bytes)                                     |
  478.    +                                               +---------------+
  479.    |                                               |               |
  480.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
  481.    |                                                               |
  482.    +                                                               +
  483.    |                                                               |
  484.    +                                                               +
  485.    |                                                               |
  486.    +                                                               +
  487.    |                DVI4 encoded primary data (PT=5)               |
  488.    +                (84 bytes, not to scale)                       +
  489.    /                                                               /
  490.    +                                                               +
  491.    |                                                               |
  492.    +                                                               +
  493.    |                                                               |
  494.    +                                               +---------------+
  495.    |                                               |
  496.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Perkins, et. al.            Standards Track                     [Page 9]
  507.  
  508. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  509.  
  510.  
  511. 8  Authors' Addresses
  512.  
  513.    Colin Perkins/Isidor Kouvelas/Orion Hodson/Vicky Hardman
  514.    Department of Computer Science
  515.    University College London
  516.    London WC1E 6BT
  517.    United Kingdom
  518.  
  519.    EMail:  {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk
  520.  
  521.  
  522.    Mark Handley
  523.    USC Information Sciences Institute
  524.    c/o MIT Laboratory for Computer Science
  525.    545 Technology Square
  526.    Cambridge, MA 02139, USA
  527.  
  528.    EMail:  mjh@isi.edu
  529.  
  530.  
  531.    Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis
  532.    INRIA Sophia Antipolis
  533.    2004 Route des Lucioles, BP 93
  534.    06902 Sophia Antipolis
  535.    France
  536.  
  537.    EMail:  {bolot|avega|sfosse}@sophia.inria.fr
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Perkins, et. al.            Standards Track                    [Page 10]
  563.  
  564. RFC 2198          RTP Payload for Redundant Audio Data    September 1997
  565.  
  566.  
  567. 9  References
  568.  
  569.    [1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable
  570.    Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu,
  571.    Hawaii, September 1995.  http://www.isoc.org/in95prc/
  572.  
  573.    [2] Schulzrinne, H., Casner, S., Frederick R., and V. Jacobson, "RTP:
  574.    A Transport Protocol for Real-Time Applications", RFC 1889, January
  575.    1996.
  576.  
  577.    [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
  578.    with Minimal Control", RFC 1890, January 1996.
  579.  
  580.    [4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation in
  581.    the MBone multicast network; IEEE Globecom Internet workshop, London,
  582.    November 1996
  583.  
  584.    [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error
  585.    control for packet audio in the Internet; ACM Multimedia Systems,
  586.    1997
  587.  
  588.    [6] Handley, M., and V. Jacobson, "SDP: Session Description Protocol
  589.    (draft 03.2)", Work in Progress.
  590.  
  591.    [7] Bradner, S., "Key words for use in RFCs to indicate requirement
  592.    levels", RFC 2119, March 1997.
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Perkins, et. al.            Standards Track                    [Page 11]
  619.  
  620.