draft-perkins-rtp-redundancy-00.txt | draft-perkins-rtp-redundancy-01.txt | |||
---|---|---|---|---|
Expire in six months | ||||
INTERNET-DRAFT Mark Handley | Mark Handley | |||
draft-perkins-rtp-redundancy-00.txt Vicky Hardman | Vicky Hardman | |||
Isidor Kouvelas | Isidor Kouvelas | |||
Colin Perkins | Colin Perkins | |||
University College London | UniversityCollege London | |||
Jean-Chrysostome Bolot | ||||
Andres Vega-Garcia | ||||
Sacha Fosse-Parisis | ||||
INRIA Sophia Antipolis | ||||
4 July 1996 | Jean-Chrysostome Bolot | |||
Expires: 9 January 1997 | Andres Vega-Garcia | |||
Sacha Fosse-Parisis | ||||
INRIA Sophia Antipolis | ||||
Payload Format Issues for Redundant Encodings in RTP | Payload Format Issues for Redundant Encodings in RTP | |||
draft-perkins-rtp-redundancy-01.txt | ||||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft. Internet-Drafts are | This document is an Internet-Draft. Internet-Drafts are working | |||
working documents of the Internet Engineering Task Force | documents of the Internet Engineering Task Force (IETF), its | |||
(IETF), its areas, and its working groups. Note that other | areas, and its working groups. Note that other groups may also | |||
groups may also distribute working documents as Internet- | distribute working documents as Internet-Drafts. | |||
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 | other documents at any time. It is inappropriate to use | |||
six months and may be updated, replaced, or obsoleted by | Internet-Drafts as reference material or to cite them other | |||
other documents at any time. It is inappropriate to use | than as ``work in progress.'' To learn the current status | |||
Internet-Drafts as reference material or to cite them other | of any Internet-Draft, please check the ``1id-abstracts.txt'' | |||
than as ``work in progress.'' | listing contained in the Internet-Drafts Shadow Directories | |||
on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au | ||||
To learn the current status of any Internet-Draft, please | (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu | |||
check the ``1id-abstracts.txt'' listing contained in the | (US West Coast). | |||
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), | ||||
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), | ||||
ds.internic.net (US East Coast), or ftp.isi.edu (US West | ||||
Coast). | ||||
Distribution of this document is unlimited. | Distribution of this document is unlimited. | |||
Comments are solicited and should be addressed to the | Comments are solicited and should be addressed to the authors | |||
authors and/or the AVT working group's mailing list at rem- | and/or the AVT working group's mailing list at rem-conf@es.net. | |||
conf@es.net. | ||||
Abstract | ||||
This document describes a payload type for use | Abstract | |||
with the real-time transport protocol (RTP), ver- | ||||
sion 2, for encoding redundant data. The primary | ||||
motivation for the scheme described herein is the | ||||
development of audio conferencing tools for use | ||||
with lossy packet networks such as the Internet | ||||
Mbone, although this scheme is not limited to such | ||||
applications. | ||||
1. Introduction | This document describes a payload type for use with | |||
the real-time transport protocol (RTP), version 2, for | ||||
encoding redundant data. The primary motivation for | ||||
the scheme described herein is the development of | ||||
audio conferencing tools for use with lossy packet | ||||
networks such as the Internet Mbone, although this | ||||
scheme is not limited to such applications. | ||||
If multimedia conferencing is to become widely used in the | 1 Introduction | |||
Internet community, users must perceive the quality to be | ||||
sufficiently good for most applications. We have identified | ||||
a number of problems which impair the quality of confer- | ||||
ences, the most significant of which is packet loss over the | ||||
Mbone. Packet loss is a persistent problem, particularly | ||||
given the increasing popularity, and therefore increasing | ||||
load, of the Internet. The disruption of speech intelligi- | ||||
bility even at low loss rates which is currently experienced | ||||
may convince a whole generation of users that multimedia | ||||
conferencing over the Internet is not viable. The addition | ||||
of redundancy to the data stream is offered as a solution | ||||
[1]. If a packet is lost then the missing information may | ||||
be reconstructed at the receiver from the redundant data | ||||
that arrives in the following packet(s). | ||||
This draft proposes an RTP payload format for the transmis- | If multimedia conferencing is to become widely used by the | |||
sion of data encoded in a redundant fashion. Although the | Internet Mbone community, users must perceive the quality to be | |||
primary use of this packet format to date has been in audio | sufficiently good for most applications. We have identified | |||
applications, the packet format specified is quite general, | a number of problems which impair the quality of conferences, | |||
and is not limited to these applications. | the most significant of which is packet loss over the Mbone. | |||
Packet loss is a persistent problem, particularly given the | ||||
increasing popularity, and therefore increasing load, of the | ||||
Internet. The disruption of speech intelligibility even at | ||||
low loss rates which is currently experienced may convince a | ||||
whole generation of users that multimedia conferencing over the | ||||
Internet is not viable. The addition of redundancy to the | ||||
data stream is offered as a solution [1]. If a packet is | ||||
lost then the missing information may be reconstructed at the | ||||
receiver from the redundant data that arrives in the following | ||||
packet(s). | ||||
2. Packetisation problem | This draft proposes an RTP payload format for the transmission | |||
of data encoded in a redundant fashion. Although the | ||||
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. | ||||
The main requirements for a redundant encoding scheme under | 2 Packetisation problem | |||
RTP are as follows: | ||||
o Packets have to carry a primary encoding and one or | The main requirements for a redundant encoding scheme under RTP | |||
more redundant encodings. | are as follows: | |||
o As a multitude of encodings may be used for redundant | o Packets have to carry a primary encoding and one or more | |||
information, each block of redundant encoding has to | redundant encodings. | |||
have an encoding type identifier. | 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 the use of variable size encodings is desirable, | |||
each encoded block in the packet has to have a length | each encoded block in the packet has to have a length | |||
indicator. | indicator. | |||
o The RTP header provides a timestamp field that | o The RTP header provides a timestamp field that corresponds | |||
corresponds to the time of creation of the encoded data. | to the time of creation of the encoded data. When | |||
When redundant encodings are used this timestamp field | redundant encodings are used this timestamp field can refer | |||
can refer to the time of creation of the primary encod- | to the time of creation of the primary encoding data. | |||
ing data. Redundant blocks of data will correspond to | Redundant blocks of data will correspond to different time | |||
different time intervals than the primary data. Each | intervals than the primary data. Each block of redundant | |||
block of redundant encoding has to have its own times- | encoding has to have its own timestamp. To reduce the | |||
tamp. To reduce the number of bytes needed to carry the | number of bytes needed to carry the timestamp, it can | |||
timestamp, it can be computed as the difference of the | be computed as the difference of the timestamp for the | |||
timestamp for the redundant encoding to timestamp for | redundant encoding to timestamp for the primary. | |||
the primary. | ||||
There are two essential means by which redundant audio may | There are two essential means by which redundant audio may be | |||
be added to the standard RTP specification: a header exten- | added to the standard RTP specification: a header extension | |||
sion may hold the redundancy, or one, or more, additional | may hold the redundancy, or one, or more, additional payload | |||
payload types may be defined. | 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 to ignore a header extension. Including all the | prepared to ignore a header extension. Including all the | |||
redundancy information for a packet in a header extension | redundancy information for a packet in a header extension | |||
would make it easy for applications that do not implement | would make it easy for applications that do not implement | |||
redundancy to discard it and just process the primary encod- | redundancy to discard it and just process the primary encoding | |||
ing 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 | o There is a large overhead from the number of bytes needed | |||
needed for the extension header (4) and the possible | for the extension header (4) and the possible padding that | |||
padding that is needed at the end of the extension to | is needed at the end of the extension to round up to | |||
round up to a four byte boundary (up to 3 bytes). Even | a four byte boundary (up to 3 bytes). Even for longer | |||
for longer duration packets especially when high | duration packets especially when high compression encodings | |||
compression encodings are used the overhead is consider- | are used the overhead is considerable. | |||
able. | ||||
o Use of the header extension limits applications to a | o Use of the header extension limits applications to a single | |||
single redundant encoding, unless further structure is | redundant encoding, unless further structure is introduced | |||
introduced into the extension. This would result in | into the extension. This would result in further overhead. | |||
further overhead. | ||||
For these reasons, the use of RTP header extension to | For these reasons, the use of RTP header extension to hold | |||
hold redundant audio encodings is disregarded. | redundant audio 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 | Currently the RTP profile for audio and video conferences [3] | |||
[3] lists a set of payload types and provides for a dynamic | lists a set of payload types and provides for a dynamic range | |||
range of 32 encodings that may be defined through a confer- | of 32 encodings that may be defined through a conference | |||
ence control protocol. This leads to two possible schemes | control protocol. This leads to two possible schemes for | |||
for assigning additional RTP payload types for redundant | assigning additional RTP payload types for redundant audio | |||
audio applications: (1) a dynamic encoding scheme may be | applications: | |||
defined, using the RTP dynamic payload type range (96-127); | ||||
or (2) a fixed payload type may be defined to represent a | ||||
packet with redundancy. | ||||
4.1. Dynamic Encoding Schemes | 1.A dynamic encoding scheme may be defined, for each | |||
combination of primary/redundant payload types, using the | ||||
RTP dynamic payload type range. | ||||
It is possible to define a set of payload types that would | 2.A fixed payload type may be defined to represent a packet | |||
signify a particular combination of primary and secondary | with redundancy. This may then be assigned to either a | |||
encodings for each of the 32 dynamic payload types provided. | static RTP payload type, or the payload type for this may | |||
This would be a slightly restrictive yet feasible solution | be assigned dynamically. | |||
for packets with a single block of redundancy as the number | ||||
of possible combinations is not too large. However the need | ||||
for multiple blocks of redundancy greatly increases the | ||||
number of encoding combinations and makes this solution not | ||||
viable. | ||||
A modified version of the above solution could be to decide | 4.1 Dynamic Encoding Schemes | |||
prior to the beginning of a conference on a set a 32 encod- | ||||
ing combinations that will be used for the duration of the | ||||
conference. All tools in the conference can be initialized | ||||
with this working set of encoding combinations. Communica- | ||||
tion of the working set can be made through the use of an | ||||
external mechanism such as SDR. Setup is complicated as | ||||
great care needs to be taken in starting tools with identi- | ||||
cal parameters. This 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 possible to define a set of payload types that signify | |||
a particular combination of primary and secondary encodings for | ||||
each of the 32 dynamic payload types provided. This would | ||||
be a slightly restrictive yet feasible solution for packets | ||||
with a single block of redundancy as the number of possible | ||||
combinations is not too large. However the need for multiple | ||||
blocks of redundancy greatly increases the number of encoding | ||||
combinations and makes this solution not viable. | ||||
A more flexible solution would be to have only one payload | A modified version of the above solution could be to decide | |||
type to signify a packet with redundancy and have each of | prior to the beginning of a conference on a set a 32 | |||
the encoding blocks in the packet contain it's own payload | encoding combinations that will be used for the duration of the | |||
type field: such a packet acts as a container, encapsulating | conference. All tools in the conference can be initialized | |||
multiple packets into one. | with this working set of encoding combinations. Communication | |||
of the working set can be made through the use of an external | ||||
mechanism such as SDR. Setup is complicated as great care needs | ||||
to be taken in starting tools with identical parameters. This | ||||
scheme is more efficient as only one byte is used to identify | ||||
combinations of encodings. | ||||
Such a scheme is flexible, since any number of redundant | 4.2 Payload type to mean packet-with-redundancy | |||
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 would be to have only one payload | |||
extensible, and has a relatively low overhead. The remainder | type to signify a packet with redundancy and have each of | |||
of this document describes this solution. | 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. | ||||
5. RTP payload type for redundant data | This is the preferred solution, since it is both flexible, | |||
The assignment of an RTP payload type for this new packet | extensible, and has a relatively low overhead. The remainder | |||
format is outside the scope of this document, and will not | of this document describes this solution. | |||
be specified here. An RTP packet containing redundant data | ||||
shall have a standard RTP header, with payload type indicat- | ||||
ing redundancy. The other fields of the RTP header relate to | ||||
the primary data block of the redundant data. | ||||
Following the RTP header are a number of additional headers, | 5 RTP payload type for redundant data | |||
specified 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 con- | ||||
tain the standard RTP payload data for these encodings. It | ||||
is noted that all the headers are aligned to a 32 bit boun- | ||||
dary, but that the payload data will typically not be | ||||
aligned. | ||||
0 1 2 3 | The assignment of an RTP payload type for this new packet | |||
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 | format is outside the scope of this document, and will not | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | be specified here. An RTP packet containing redundant data | |||
|F| block PT | timestamp offset | block length | | shall have a standard RTP header, with payload type indicating | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | redundancy. The other fields of the RTP header relate to the | |||
primary data block of the redundant data. | ||||
The bits in the header are specified as follows: | Following the RTP header are a number of additional headers, | |||
specified 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. | ||||
o F: 1 bit First bit in header indicates whether another | 0 1 2 3 | |||
encoding block follows. If 1 further redundant data | 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 | |||
blocks follow, if 0 this is the last data block. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|F| block PT | timestamp offset | block length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
o block PT: 7 bits Payload type for this block. | The bits in the header are specified as follows: | |||
o timestamp offset: 14 bits Unsigned offset of timestamp | F: 1 bitFirst bit in header indicates whether another encoding | |||
of this block relative to timestamp given in RTP header. | block follows. If 1 further redundant data blocks follow, | |||
The use of an unsigned offset implies that redundant | if 0 this is the last data block. | |||
data must be sent after the primary data, and is hence a | ||||
time to be subtracted from the current timestamp to | ||||
determine the timestamp of the data for which this block | ||||
is the redundancy. | ||||
o block length: 10 bits Length in bytes of the next | block PT: 7 bitsPayload type for this block. | |||
redundant data block excluding header. | ||||
It is noted that this limits the use of redundant data | timestamp offset: 14 bitsUnsigned offset of timestamp of this | |||
slightly: it is not possible to send redundancy before the | block relative to timestamp given in RTP header. The | |||
primary encoding. This may possibly affect schemes, such as | use of an unsigned offset implies that redundant data must | |||
GSM audio, where a low bandwidth coding suitable for redun- | be sent after the primary data, and is hence a time | |||
dancy is produced early in the encoding process, and hence | to be subtracted from the current timestamp to determine | |||
could feasibly be transmitted early. The addition of a sign | the timestamp of the data for which this block is the | |||
bit would unacceptably reduce the range of the timestamp | redundancy. | |||
offset, and increasing the size of the field above 14 bits | block length: 10 bitsLength in bytes of the next redundant | |||
limits the block length field. It seems that limiting redun- | data block excluding header. | |||
dancy 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 | It is noted that this limits the use of redundant data | |||
10 bits, and 14 bits respectively; rather than the more | slightly: it is not possible to send redundancy before the | |||
obvious 8 and 16 bits. Whilst such an encoding complicates | primary encoding. This may possibly affect schemes, such as | |||
parsing the header information slightly, and adds some addi- | GSM audio, where a low bandwidth coding suitable for redundancy | |||
tional processing overhead, there are a number of problems | is produced early in the encoding process, and hence could | |||
involved with the more obvious choice: An 8 bit block length | feasibly be transmitted early. The addition of a sign bit | |||
field is sufficient for most, but not all, possible encod- | would unacceptably reduce the range of the timestamp offset, | |||
ings: for example 80ms PCM and DVI audio packets comprise | and increasing the size of the field above 14 bits limits the | |||
more than 256 bytes, and cannot be encoded with a single | block length field. It seems that limiting redundancy to be | |||
byte length field. It is possible to impose additional | transmitted after the primary will cause fewer problems than | |||
structure on the block length field (for example the high | limiting the size of the other fields. | |||
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 | It is noted that the block length and timestamp offset are 10 | |||
packet. It is therefore required to omit the timestamp and | bits, and 14 bits respectively; rather than the more obvious 8 | |||
block-length fields from the header of this block, since | and 16 bits. Whilst such an encoding complicates parsing the | |||
they may be determined from the RTP header and overall | header information slightly, and adds some additional processing | |||
packet length. The header for the primary (final) block | overhead, there are a number of problems involved with the more | |||
comprises only a zero marker bit, and the block payload type | obvious choice: An 8 bit block length field is sufficient for | |||
information, a total of 8 bits. This is illustrated in | most, but not all, possible encodings: for example 80ms PCM | |||
below: | 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 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 2 3 4 5 6 7 | 0 1 23 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|0| block PT | | |0| Block PT | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
6. Limitations | -+-+-+-+-+-+-+-+ | |||
6 Limitations | ||||
The RTP marker bit is not preserved. That is, a redundant | The RTP marker bit is not preserved. That is, a redundant copy | |||
copy of the RTP marker is not sent, hence if the primary | of the RTP marker is not sent, hence if the primary (containing | |||
(containing this marker) is lost, the marker is lost. It is | this marker) is lost, the marker is lost. It is not thought | |||
not thought that this will 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, | was transmitted with the redundant information, there would be | |||
there would be the possibility of its loss, so applications | the possibility of its loss, so applications would still have | |||
would still have to be written with this in mind. | to be written with this in mind. | |||
7. Example Packet | 7 Example Packet | |||
A redundant audio data packet containing DVI4 (8KHz) pri- | A redundant audio data packet containing DVI4 (8KHz) primary, | |||
mary, and a single block of redundancy encoded using 8KHz | and a single block of redundancy encoded using 8KHz LPC is | |||
LPC is illustrated: | 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 |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 + | |||
| | | | | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
+ + | + + | |||
| DVI4 encoded primary data | | | DVI4 encoded primary data | | |||
+ + | + + | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Author's Addresses | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
8 Author's Addresses | ||||
Mark Handley/Vicky Hardman/Isidor Kouvelas/Colin Perkins | Mark Handley/Vicky Hardman/Isidor Kouvelas/Colin Perkins | |||
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: M.Handley|V.Hardman|I.Kouvelas|C.Perkins@cs.ucl.ac.uk | |||
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 | |||
Sophia Antipolis | 06902 Sophia Antipolis | |||
06902 | ||||
France | France | |||
Email: bolot@sophia.inria.fr | Email: bolot@sophia.inria.fr | |||
References | 9 References | |||
[1] Hardman, V. J. and Sasse, M. A. and Handley, M. and Wat- | [1] Hardman, V. J. and Sasse, M. A. and Handley, M. | |||
son, A., | and Watson, A., Reliable Audio for Use over the Internet, | |||
Reliable Audio for Use over the Internet, | Proceecings INET'95, Honalulu, Oahu, Hawaii, September 1995. | |||
Proceecings INET'95, Honalulu, Oahu, Hawaii, September | http://www.isoc.org/in95prc/ | |||
1995. | ||||
http://www.isoc.org/in95prc/ | ||||
[2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, | [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, | |||
RTP: A Transport Protocol for Real-Time Applications, | RTP: A Transport Protocol for Real-Time Applications, RFC 1889, | |||
RFC 1889, January 1996 | January 1996 | |||
[3] H. Schulzrinne, | [3] H. Schulzrinne, RTP Profile for Audio and Video Conferences | |||
RTP Profile for Audio and Video Conferences with Minimal | with Minimal Control, RFC 1890, January 1996 | |||
Control, | ||||
RFC 1890, January 1996 | ||||
End of changes. 55 change blocks. | ||||
283 lines changed or deleted | 270 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/ |