draft-perkins-rtp-redundancy-01.txt   draft-perkins-rtp-redundancy-02.txt 
Expire in six months
Mark Handley INTERNET-DRAFT 3 January 1997
Vicky Hardman
Isidor Kouvelas Colin Perkins
Colin Perkins Isidor Kouvelas
UniversityCollege London Vicky Hardman
University College London
Mark Handley
ISI
Jean-Chrysostome Bolot Jean-Chrysostome Bolot
Andres Vega-Garcia Andres Vega-Garcia
Sacha Fosse-Parisis Sacha Fosse-Parisis
INRIA Sophia Antipolis INRIA Sophia Antipolis
Payload Format Issues for Redundant Encodings in RTP RTP Payload for Redundant Audio Data
draft-perkins-rtp-redundancy-01.txt draft-perkins-rtp-redundancy-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working documents
documents of the Internet Engineering Task Force (IETF), its of the Internet Engineering Task Force (IETF), its areas, and its working
areas, and its working groups. Note that other groups may also groups. Note that other groups may also distribute working documents as
distribute working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by Internet-Drafts are draft documents valid for a maximum of six months and
other documents at any time. It is inappropriate to use may be updated, replaced, or obsoleted by other documents at any time. It
Internet-Drafts as reference material or to cite them other is inappropriate to use Internet-Drafts as reference material or to cite
than as ``work in progress.'' To learn the current status them other than as ``work in progress''. To learn the current status of any
of any Internet-Draft, please check the ``1id-abstracts.txt'' Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in
listing contained in the Internet-Drafts Shadow Directories the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu ftp.isi.edu (US West Coast).
(US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Comments are solicited and should be addressed to the authors Comments are solicited and should be addressed to the authors and/or
and/or the AVT working group's mailing list at rem-conf@es.net. the AVT working group's mailing list at rem-conf@es.net.
Abstract Abstract
This document describes a payload type for use with This document describes a payload type for use with the real-time
the real-time transport protocol (RTP), version 2, for transport protocol (RTP), version 2, for encoding redundant data. The
encoding redundant data. The primary motivation for primary motivation for the scheme described herein is the development
the scheme described herein is the development of of audio conferencing tools for use with lossy packet networks such as
audio conferencing tools for use with lossy packet the Internet Mbone, although this scheme is not limited to such
networks such as the Internet Mbone, although this applications.
scheme is not limited to such applications.
1 Introduction 1 Introduction
If multimedia conferencing is to become widely used by the If multimedia conferencing is to become widely used by the Internet Mbone
Internet Mbone community, users must perceive the quality to be community, users must perceive the quality to be sufficiently good for most
sufficiently good for most applications. We have identified applications. We have identified a number of problems which impair the
a number of problems which impair the quality of conferences, quality of conferences, the most significant of which is packet loss over
the most significant of which is packet loss over the Mbone. the Internet Mbone. Packet loss is a persistent problem, particularly
Packet loss is a persistent problem, particularly given the given the increasing popularity, and therefore increasing load, of the
increasing popularity, and therefore increasing load, of the Internet. The disruption of speech intelligibility even at low loss rates
Internet. The disruption of speech intelligibility even at which is currently experienced may convince a whole generation of users
low loss rates which is currently experienced may convince a that multimedia conferencing over the Internet is not viable. The addition
whole generation of users that multimedia conferencing over the of redundancy to the data stream is offered as a solution [1]. If a packet
Internet is not viable. The addition of redundancy to the is lost then the missing information may be reconstructed at the receiver
data stream is offered as a solution [1]. If a packet is from the redundant data that arrives in the following packet(s), provided
lost then the missing information may be reconstructed at the that the average number of consequutively lost packet is small. Recent work
receiver from the redundant data that arrives in the following [4,5] shows that packet loss patterns in the Internet are such that this
packet(s). scheme typically functions well.
This draft proposes an RTP payload format for the transmission This document proposes an RTP payload format for the transmission of data
of data encoded in a redundant fashion. Although the encoded in such a redundant fashion.
primary use of this packet format to date has been in audio
applications, the packet format specified is quite general, and
is not limited to these applications.
2 Packetisation problem 2 Requirements
The main requirements for a redundant encoding scheme under RTP The requirements for a redundant encoding scheme under RTP are as follows:
are as follows:
o Packets have to carry a primary encoding and one or more o Packets have to carry a primary encoding and one or more redundant
redundant encodings. encodings.
o As a multitude of encodings may be used for redundant
information, each block of redundant encoding has to have
an encoding type identifier.
o As the use of variable size encodings is desirable, o As a multitude of encodings may be used for redundant information,
each encoded block in the packet has to have a length each block of redundant encoding has to have an encoding type
indicator. identifier.
o The RTP header provides a timestamp field that corresponds o As the use of variable size encodings is desirable, each encoded
to the time of creation of the encoded data. When block in the packet has to have a length indicator.
redundant encodings are used this timestamp field can refer
to the time of creation of the primary encoding data.
Redundant blocks of data will correspond to different time
intervals than the primary data. Each block of redundant
encoding has to have its own timestamp. To reduce the
number of bytes needed to carry the timestamp, it can
be computed as the difference of the timestamp for the
redundant encoding to timestamp for the primary.
There are two essential means by which redundant audio may be o The RTP header provides a timestamp field that corresponds to
added to the standard RTP specification: a header extension the time of creation of the encoded data. When redundant encodings
may hold the redundancy, or one, or more, additional payload are used this timestamp field can refer to the time of creation
types may be defined. These are now discussed in turn. of the primary encoding data. Redundant blocks of data will correspond
to different time intervals than the primary data, and hence each
block of redundant encoding will require its own timestamp. To
reduce the number of bytes needed to carry the timestamp, it can
be encoded as the difference of the timestamp for the redundant
encoding and the timestamp ofthe primary.
There are two essential means by which redundant audio may be added
to the standard RTP specification: a header extension may hold the
redundancy, or one, or more, additional payload types may be defined.
These are now discussed in turn.
3 Use of RTP Header Extension 3 Use of RTP Header Extension
The RTP specification [2] states that applications should be The RTP specification [2] states that applications should be prepared
prepared to ignore a header extension. Including all the to ignore a header extension. Including all the redundancy information
redundancy information for a packet in a header extension for a packet in a header extension would make it easy for applications
would make it easy for applications that do not implement that do not implement redundancy to discard it and just process the
redundancy to discard it and just process the primary encoding primary encoding data. There are, however, a number of disadvantages
data. There are, however, a number of disadvantages with this with this scheme:
scheme:
o There is a large overhead from the number of bytes needed o There is a large overhead from the number of bytes needed for
for the extension header (4) and the possible padding that the extension header (4) and the possible padding that is needed
is needed at the end of the extension to round up to at the end of the extension to round up to a four byte boundary
a four byte boundary (up to 3 bytes). Even for longer (up to 3 bytes). For many applications this overhead is unacceptable.
duration packets especially when high compression encodings
are used the overhead is considerable.
o Use of the header extension limits applications to a single o Use of the header extension limits applications to a single redundant
redundant encoding, unless further structure is introduced encoding, unless further structure is introduced into the extension.
into the extension. This would result in further overhead. This would result in further overhead.
For these reasons, the use of RTP header extension to hold For these reasons, the use of RTP header extension to hold redundant audio
redundant audio encodings is disregarded. encodings is disregarded.
4 Use Of Additional RTP Payload Types 4 Use Of Additional RTP Payload Types
Currently the RTP profile for audio and video conferences [3] The RTP profile for audio and video conferences [3] lists a set of
lists a set of payload types and provides for a dynamic range payload types and provides for a dynamic range of 32 encodings that
of 32 encodings that may be defined through a conference may be defined through a conference control protocol. This leads to
control protocol. This leads to two possible schemes for two possible schemes for assigning additional RTP payload types for
assigning additional RTP payload types for redundant audio redundant audio applications:
applications:
1.A dynamic encoding scheme may be defined, for each 1.A dynamic encoding scheme maybe defined, for each combination
combination of primary/redundant payload types, using the of primary/redundant payload types, using the RTP dynamic payload
RTP dynamic payload type range. type range.
2.A fixed payload type may be defined to represent a packet 2.A single fixed payload type may be defined to represent a packet
with redundancy. This may then be assigned to either a with redundancy. This may then be assigned to either a static
static RTP payload type, or the payload type for this may RTP payload type, or the payload type for this may be assigned
be assigned dynamically. dynamically.
4.1 Dynamic Encoding Schemes 4.1 Dynamic Encoding Schemes
It is possible to define a set of payload types that signify It is possible to define a set of payload types that signify a particular
a particular combination of primary and secondary encodings for combination of primary and secondary encodings for each of the 32 dynamic
each of the 32 dynamic payload types provided. This would payload types provided. This would be a slightly restrictive yet feasible
be a slightly restrictive yet feasible solution for packets solution for packets with a single block of redundancy as the number
with a single block of redundancy as the number of possible of possible combinations is not too large. However the need for multiple
combinations is not too large. However the need for multiple blocks of redundancy greatly increases the number of encoding combinations
blocks of redundancy greatly increases the number of encoding and makes this solution not viable.
combinations and makes this solution not viable.
A modified version of the above solution could be to decide A modified version of the above solution could be to decide prior to the
prior to the beginning of a conference on a set a 32 beginning of a conference on a set a 32 encoding combinations that will be
encoding combinations that will be used for the duration of the used for the duration of the conference. All tools in the conference can
conference. All tools in the conference can be initialized be initialized with this working set of encoding combinations. Communication
with this working set of encoding combinations. Communication of the working set can be made through the use of an external, out of band,
of the working set can be made through the use of an external mechanism. Setup is complicated as great care needs to be taken in
mechanism such as SDR. Setup is complicated as great care needs starting tools with identical parameters. This scheme is more efficient as
to be taken in starting tools with identical parameters. This only one byte is used to identify combinations of encodings.
scheme is more efficient as only one byte is used to identify
combinations of encodings.
4.2 Payload type to mean packet-with-redundancy It is felt that the complication inherent in distributing the mapping
of payload types onto combinations of redundant data preclude the use
of this mechanism.
A more flexible solution would be to have only one payload 4.2 Payload Type to Mean ``Packet-With-Redundancy''
type to signify a packet with redundancy and have each of
the encoding blocks in the packet contain it's own payload
type field: such a packet acts as a container, encapsulating
multiple packets into one.
Such a scheme is flexible, since any number of redundant
encodings may be enclosed within a single packet. There is,
however, a small overhead since each encapsulated packet must
be preceded by a header indicating the type of data enclosed.
This is the preferred solution, since it is both flexible, A more flexible solution is to have a single payload type which signifies a
extensible, and has a relatively low overhead. The remainder packet with redundancy and have each of the encoding blocks in the packet
of this document describes this solution. contain it's own payload type field: such a packet acts as a container,
encapsulating multiple packets into one.
Such a scheme is flexible, since any number of redundant encodings
may be enclosed within a single packet. There is, however, a small
overhead since each encapsulated packet must be preceded by a header
indicating the type of data enclosed. This is the preferred solution,
since it is both flexible, extensible, and has a relatively low overhead.
The remainder of this document describes this solution.
5 RTP payload type for redundant data 5 RTP payload type for redundant data
The assignment of an RTP payload type for this new packet The assignment of an RTP payload type for this new packet format is
format is outside the scope of this document, and will not outside the scope of this document, and will not be specified here.
be specified here. An RTP packet containing redundant data It is expected that the RTP profile for a particular class of applications
shall have a standard RTP header, with payload type indicating will assign a payload type for this encoding, or if that is not done
redundancy. The other fields of the RTP header relate to the then a payload type in the dynamic range shall be chosen.
primary data block of the redundant data.
Following the RTP header are a number of additional headers, An RTP packet containing redundant data shall have a standard RTP header,
specified in the figure below, which specify the contents of with payload type indicating redundancy. The other fields of the RTP
each of the encodings carried by the packet. Following these header relate to the primary data block of the redundant data.
additional headers are a number of data blocks, which contain
the standard RTP payload data for these encodings. It is noted
that all the headers are aligned to a 32 bit boundary, but that
the payload data will typically not be aligned.
0 1 2 3 Following the RTP header are a number of additional headers, defined
0 1 23 4 5 6 7 8 90 1 2 3 4 5 67 8 9 0 1 23 4 5 6 7 8 90 1 in the figure below, which specify the contents of each of the encodings
carried by the packet. Following these additional headers are a number
of data blocks, which contain the standard RTP payload data for these
encodings. It is noted that all the headers are aligned to a 32 bit
boundary, but that the payload data will typically not be aligned.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length | |F| block PT | timestamp offset | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits in the header are specified as follows: The bits in the header are specified as follows:
F: 1 bitFirst bit in header indicates whether another encoding F: 1 bit First bit in header indicates whether another header block
block follows. If 1 further redundant data blocks follow, follows. If 1 further header blocks follow, if 0 this is the
if 0 this is the last data block. last header block.
block PT: 7 bitsPayload type for this block. block PT: 7 bits RTP payload type for this block.
timestamp offset: 14 bitsUnsigned offset of timestamp of this timestamp offset: 14 bits Unsigned offset of timestamp of this block
block relative to timestamp given in RTP header. The relative to timestamp given in RTP header. This uses the same
use of an unsigned offset implies that redundant data must clock as the primary encoding. The use of an unsigned offset
be sent after the primary data, and is hence a time implies that redundant data must be sent after the primary data,
to be subtracted from the current timestamp to determine and is hence a time to be subtracted from the current timestamp
the timestamp of the data for which this block is the to determine the timestamp of the data for which this block is
redundancy. the redundancy.
block length: 10 bitsLength in bytes of the next redundant
data block excluding header.
It is noted that this limits the use of redundant data block length: 10 bits Length in bytes of the corresponding data block
slightly: it is not possible to send redundancy before the excluding header.
primary encoding. This may possibly affect schemes, such as
GSM audio, where a low bandwidth coding suitable for redundancy
is produced early in the encoding process, and hence could
feasibly be transmitted early. The addition of a sign bit
would unacceptably reduce the range of the timestamp offset,
and increasing the size of the field above 14 bits limits the
block length field. It seems that limiting redundancy to be
transmitted after the primary will cause fewer problems than
limiting the size of the other fields.
It is noted that the block length and timestamp offset are 10 It is noted that the use of an unsigned timestamp offest limits the
bits, and 14 bits respectively; rather than the more obvious 8 use of redundant data slightly: it is not possible to send redundancy
and 16 bits. Whilst such an encoding complicates parsing the before the primary encoding. This may affect schemes where a low bandwidth
header information slightly, and adds some additional processing coding suitable for redundancy is produced early in the encoding process,
overhead, there are a number of problems involved with the more and hence could feasibly be transmitted early. However, the addition
obvious choice: An 8 bit block length field is sufficient for of a sign bit would unacceptably reduce the range of the timestamp
most, but not all, possible encodings: for example 80ms PCM offset, and increasing the size of the field above 14 bits limits the
and DVI audio packets comprise more than 256 bytes, and cannot block length field. It seems that limiting redundancy to be transmitted
be encoded with a single byte length field. It is possible after the primary will cause fewer problems than limiting the size
to impose additional structure on the block length field (for of the other fields.
example the high bit set could imply the lower 7 bits code a
length in words, rather than bytes), however such schemes are
complex. The use of a 10 bit block length field retains
simplicity and provides an enlarged range, at the expense of a
reduced range of timestamp values. A 14 bit timestamp value
does, however, allow for 4.5 complete packets delay with 48KHz
audio, more at lower sampling rates, and it is felt that this
is sufficient.
The primary encoding block should be placed last in the packet.
It is therefore required to omit the timestamp and block-length
fields from the header of this block, since they may be
determined from the RTP header and overall packet length. The
header for the primary (final) block comprises only a zero
marker bit, and the block payload type information, a total of
8 bits. This is illustrated in below:
0 1 23 4 5 6 7 It is further noted that the block length and timestamp offset are
10 bits, and 14 bits respectively; rather than the more obvious 8 and
16 bits. Whilst such an encoding complicates parsing the header information
slightly, and adds some additional processing overhead, there are a
number of problems involved with the more obvious choice: An 8 bit
block length field is sufficient for most, but not all, possible encodings:
for example 80ms PCM and DVI audio packets comprise more than 256 bytes,
and cannot be encoded with a single byte length field. It is possible
to impose additional structure on the block length field (for example
the high bit set could imply the lower 7 bits code a length in words,
rather than bytes), however such schemes are complex. The use of a
10 bit block length field retains simplicity and provides an enlarged
range, at the expense of a reduced range of timestamp values. A 14
bit timestamp value does, however, allow for 4.5 complete packets delay
with 48KHz audio, more at lower sampling rates, and it is felt that
this is sufficient.
The primary encoding block header is placed last in the packet. It
is therefore possible to omit the timestamp and block-length fields
from the header of this block, since they may be determined from the
RTP header and overall packet length. The header for the primary (final)
block comprises only a zero marker bit, and the block payload type
information, a total of 8 bits. This is illustrated in the figure
below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| Block PT | |0| BlockPT |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The final header is followed, immediately, by the data blocks, stored
in the same order as the headers. There is no padding or other delimiter
between the data blocks, and they are typically not 32 bit aligned.
Again, this choice was made to reduce bandwidth overheads, at the expense
of additional decoding time.
6 Limitations 6 Limitations
The RTP marker bit is not preserved. That is, a redundant copy The RTP marker bit is not preserved for redundant data blocks. Hence
of the RTP marker is not sent, hence if the primary (containing if the primary (containing this marker) is lost, the marker is lost.
this marker) is lost, the marker is lost. It is not thought It is believed that this will not cause undue problems: even if the
that this will cause undue problems: even if the marker bit marker bit was transmitted with the redundant information, there would
was transmitted with the redundant information, there would be still be the possibility of its loss, so applications would still have
the possibility of its loss, so applications would still have
to be written with this in mind. to be written with this in mind.
7 Example Packet In addition, CSRC information is not preserved for redundant data.
The CSRC data in the RTP header of a redundant audio packet relates
to the primary only. Since CSRC data in an audio stream is expected
to change relatively infrequently, it is recommended that applications
which require this information assume that the CSRC data in the RTP
header may be applied to the reconstructed redundant data.
A redundant audio data packet containing DVI4 (8KHz) primary, 7 Security Considerations
and a single block of redundancy encoded using 8KHz LPC is
illustrated: RTP packets containing redundant information are subject to the security
considerations discussed in the RTP specification [2], and any appropriate
RTP profile (for example[3]). This implies that confidentiality of
the media streams is achieved by encryption.
Encryption of a redundant data-stream may occur in two ways:
1.The entire stream is to be secured, and all participants are expected
to have keys to decode the entire stream. In this case, nothing
special need be done, and encryption is performed in the usual
manner.
2.A portion of the stream is to be encrypted with a different key
to the remainder. In this case a redundant copy of the last packet
of that portion cannot be sent, since there is no following packet
which is encrypted with the correct key in which to send it. Similar
limitations may occur when enabling/disabling encryption.
The choice between these two is a matter for the encoder only. Decoders
can decrypt either form without modification.
8 Example Packet
An RTP audio data packet containing a DVI4 (8KHz) primary, and a single
block of redundancy encoded using 8KHz LPC is illustrated:
0 1 2 3 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 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 of primary | |V=2|P|X| CC=0 |M| PT | sequence number of primary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp of primary encoding | | timestamp of primary encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=7 | timestamp offset | block length | |1| block PT=7 | timestamp offset | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=5 | | |0| block PT=5 | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
+ LPC encoded redundant data + + LPC encoded redundant data (PT=7) +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| DVI4 encoded primary data | | DVI4 encoded primary data (PT=5) |
+ + + +---------+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 Author's Addresses
8 Author's Addresses
Mark Handley/Vicky Hardman/Isidor Kouvelas/Colin Perkins Colin Perkins/Isidor Kouvelas/Vicky Hardman
Department of Computer Science Department of Computer Science
University College London University College London
London WC1E 6BT London WC1E 6BT
United Kingdom United Kingdom
Email: M.Handley|V.Hardman|I.Kouvelas|C.Perkins@cs.ucl.ac.uk Email: {c.perkins|i.kouvelas|v.hardman}@cs.ucl.ac.uk
Mark Handley
USC Information Sciences Institute
c/o MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Email: mjh@isi.edu
Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis
INRIA Sophia Antipolis INRIA Sophia Antipolis
2004 Route des Lucioles, BP 93 2004 Route des Lucioles, BP 93
06902 Sophia Antipolis 06902 Sophia Antipolis
France France
Email: bolot@sophia.inria.fr Email: {bolot|avega}@sophia.inria.fr
9 References
[1] Hardman, V. J. and Sasse, M. A. and Handley, M. 10 References
and Watson, A., Reliable Audio for Use over the Internet,
Proceecings INET'95, Honalulu, Oahu, Hawaii, September 1995.
http://www.isoc.org/in95prc/
[2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [1] V.J. Hardman, M.A.Sasse, M. Handley and A. Watson; Reliable Audio
RTP: A Transport Protocol for Real-Time Applications, RFC 1889, for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, Hawaii,
January 1996 September 1995. http://www.isoc.org/in95prc/
[3] H. Schulzrinne, RTP Profile for Audio and Video Conferences [2] H. Schulzrinne, S.Casner, R. Frederick and V. Jacobson; RTP: A
with Minimal Control, RFC 1890, January 1996 Transport Protocol for Real-Time Applications; RFC 1889, January 1996
[3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with
Minimal Control; RFC 1890, January 1996
[4] M. Yajnik, J.Kurose and D. Towsley; Packet loss correlation in
the MBone multicast network; IEEE Globecom Internet workshop, London,
November 1996
[5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error control
for packet audio in the Internet; Multimedia Systems, 1997
 End of changes. 49 change blocks. 
233 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/