draft-perkins-rtp-redundancy-03.txt | draft-perkins-rtp-redundancy-04.txt | |||
---|---|---|---|---|
INTERNET-DRAFT 26 March 1997 | INTERNET-DRAFT 16 June 1997 | |||
Colin Perkins | Colin Perkins | |||
Isidor Kouvelas | Isidor Kouvelas | |||
Vicky Hardman | Orion Hodson | |||
UniversityCollege London | Vicky Hardman | |||
University College London | ||||
Mark Handley | Mark Handley | |||
ISI | 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 | |||
RTP Payload for Redundant Audio Data | RTP Payload for Redundant Audio Data | |||
draft-perkins-rtp-redundancy-03.txt | draft-perkins-rtp-redundancy-04.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft. Internet-Drafts are working documents | This document is an Internet-Draft. Internet-Drafts are working documents | |||
of the Internet Engineering Task Force (IETF), its areas, and its working | of the Internet Engineering Task Force (IETF), its areas, and its working | |||
groups. Note that other groups may also distribute working documents as | groups. Note that other groups may also distribute working documents as | |||
Internet-Drafts. | Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months and | Internet-Drafts are draft documents valid for a maximum of six months and | |||
may be updated, replaced, or obsoleted by other documents at any time. It | may be updated, replaced, or obsoleted by other documents at any time. It | |||
is inappropriate to use Internet-Drafts as reference material or to cite | is inappropriate to use Internet-Drafts as reference material or to cite | |||
them other than as ``work in progress''. To learn the current status of | them other than as ``work in progress''. To learn the current status of | |||
any Internet-Draft, please check the ``1id-abstracts.txt'' listing | any Internet-Draft, please check the ``1id-abstracts.txt'' listing | |||
contained in the Internet-Drafts Shadow Directories on ftp.is.co.za | contained in the Internet-Drafts Shadow Directories on ftp.is.co.za | |||
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), | (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), | |||
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). | 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 authors and/or | Comments are solicited and should be addressed to the authors 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 format for use with the | This document describes a payload format for use with the | |||
real-time transport protocol (RTP), version 2, for encoding | real-time transport protocol (RTP), version 2, for encoding | |||
redundant data. The primary motivation for the scheme described | redundant audio data. The primary motivation for the scheme | |||
herein is the development of audio conferencing tools for | described herein is the development of audio conferencing | |||
use with lossy packet networks such as the Internet Mbone, | tools for use with lossy packet networks such as the Internet | |||
although this scheme is not limited to such applications. | Mbone, although this scheme is not limited to such applications. | |||
1 Introduction | 1 Introduction | |||
If multimedia conferencing is to become widely used by the Internet | If multimedia conferencing is to become widely used by the Internet Mbone | |||
Mbone community, users must perceive the quality to be sufficiently | community, users must perceive the quality to be sufficiently good for most | |||
good for most applications. We have identified a number of problems | applications. We have identified a number of problems which impair the | |||
which impair the quality of conferences, the most significant of | quality of conferences, the most significant of which is packet loss. This | |||
which is packet loss over the Internet Mbone. Packet loss is a persistent | is a persistent problem, particularly given the increasing popularity, and | |||
problem, particularly given the increasing popularity, and therefore | therefore increasing load, of the Internet. The disruption of speech | |||
increasing load, of the Internet. The disruption of speech intelligibility | intelligibility even at low loss rates which is currently experienced may | |||
even at low loss rates which is currently experienced may convince | convince a whole generation of users that multimedia conferencing over the | |||
a whole generation of users that multimedia conferencing over the | Internet is not viable. The addition of redundancy to the data stream is | |||
Internet is not viable. The addition of redundancy to the data stream | offered as a solution [1]. If a packet is lost then the missing information | |||
is offered as a solution [1]. If a packet is lost then the missing | may be reconstructed at the receiver from the redundant data that arrives | |||
information may be reconstructed at the receiver from the redundant | in the following packet(s), provided that the average number of | |||
data that arrives in the following packet(s), provided that the average | consecutively lost packets is small. Recent work [4,5] shows that packet | |||
number of consequutively lost packet is small. Recent work [4,5] | loss patterns in the Internet are such that this scheme typically functions | |||
shows that packet loss patterns in the Internet are such that this | well. | |||
scheme typically functions well. | ||||
This document describes an RTP payload format for the transmission | This document describes an RTP payload format for the transmission | |||
of audio data encoded in such a redundant fashion. Section 2 presents | of audio data encoded in such a redundant fashion. Section 2 presents | |||
the requirements and motivation leading to the definition of this | the requirements and motivation leading to the definition of this | |||
payload format, and does not form part of the payload format definition. | payload format, and does not form part of the payload format definition. | |||
Sections 3 onwards define the RTP payload format for redundant audio | Sections 3 onwards define the RTP payload format for redundant audio | |||
data. | data. | |||
2 Requirements/Motivation | 2 Requirements/Motivation | |||
skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 37 ¶ | |||
Sections 3 onwards define the RTP payload format for redundant audio | Sections 3 onwards define the RTP payload format for redundant audio | |||
data. | data. | |||
2 Requirements/Motivation | 2 Requirements/Motivation | |||
The requirements for a redundant encoding scheme under RTP are as | The requirements for a redundant encoding scheme under RTP are as | |||
follows: | follows: | |||
o Packets have to carry a primary encoding and one or more redundant | o Packets have to carry a primary encoding and one or more redundant | |||
encodings. | encodings. | |||
o As a multitude of encodings may be used for redundant information, | o As a multitude of encodings may be used for redundant information, | |||
each block of redundant encoding has to have an encoding type | each block of redundant encoding has to have an encoding type | |||
identifier. | identifier. | |||
o As the use of variable size encodings is desirable, each encoded | o As the use of variable size encodings is desirable, each encoded | |||
block in the packet has to have a length indicator. | block in the packet has to have a length indicator. | |||
o The RTP header provides a timestamp field that corresponds to | o The RTP header provides a timestamp field that corresponds to | |||
the time of creation of the encoded data. When redundant encodings | the time of creation of the encoded data. When redundant encodings | |||
are used this timestamp field can refer to the time of creation | are used this timestamp field can refer to the time of creation | |||
of the primary encoding data. Redundant blocks of data will | of the primary encoding data. Redundant blocks of data will | |||
correspond to different time intervals than the primary data, | correspond to different time intervals than the primary data, | |||
and hence each block of redundant encoding will require its own | and hence each block of redundant encoding will require its own | |||
timestamp. To reduce the number of bytes needed to carry the | timestamp. To reduce the number of bytes needed to carry the | |||
timestamp, it can be encoded as the difference of the timestamp | timestamp, it can be encoded as the difference of the timestamp | |||
for the redundant encoding and the timestamp of the primary. | for the redundant encoding and the timestamp of the primary. | |||
There are two essential means by which redundant audio may be added | There are two essential means by which redundant audio may be added | |||
to the standard RTP specification: a header extension may hold the | to the standard RTP specification: a header extension may hold the | |||
redundancy, or one, or more, additional payload types may be defined. | redundancy, or one, or more, additional payload types may be defined. | |||
Including all the redundancy information for a packet in a header | Including all the redundancy information for a packet in a header extension | |||
extension would make it easy for applications that do not implement | would make it easy for applications that do not implement redundancy to | |||
redundancy to discard it and just process the primary encoding data. | discard it and just process the primary encoding data. There are, however, | |||
There are, however, a number of disadvantages with this scheme: | a number of disadvantages with this scheme: | |||
o There is a large overhead from the number of bytes needed for | o There is a large overhead from the number of bytes needed for | |||
the extension header (4) and the possible padding that is needed | the extension header (4) and the possible padding that is needed | |||
at the end of the extension to round up to a four byte boundary | at the end of the extension to round up to a four byte boundary | |||
(up to 3 bytes). For many applications this overhead is unacceptable. | (up to 3 bytes). For many applications this overhead is unacceptable. | |||
o Use of the header extension limits applications to a single redundant | o Use of the header extension limits applications to a single redundant | |||
encoding, unless further structure is introduced into the extension. | encoding, unless further structure is introduced 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 redundant | For these reasons, the use of RTP header extension to hold redundant | |||
audio encodings is disregarded. | audio encodings is disregarded. | |||
The RTP profile for audio and video conferences [3] lists a set of | The RTP profile for audio and video conferences [3] lists a set of | |||
payload types and provides for a dynamic range of 32 encodings that | payload types and provides for a dynamic range of 32 encodings that | |||
may be defined through a conference control protocol. This leads | may be defined through a conference control protocol. This leads | |||
to two possible schemes for assigning additional RTP payload types | to two possible schemes for assigning additional RTP payload types | |||
for redundant audio applications: | for redundant audio applications: | |||
1.A dynamic encoding scheme may be defined, for each combination | 1. A dynamic encoding scheme may be defined, for each combination | |||
of primary/redundant payload types, using the RTP dynamic payload | of primary/redundant payload types, using the RTP dynamic payload | |||
type range. | type range. | |||
2.A single 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 static | with redundancy. This may then be assigned to either a static | |||
RTP payload type, or the payload type for this may be assigned | RTP payload type, or the payload type for this may be assigned | |||
dynamically. | dynamically. | |||
It is possible to define a set of payload types that signify a particular | 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 | combination of primary and secondary encodings for each of the 32 dynamic | |||
dynamic payload types provided. This would be a slightly restrictive | payload types provided. This would be a slightly restrictive yet feasible | |||
yet feasible solution for packets with a single block of redundancy | solution for packets with a single block of redundancy as the number of | |||
as the number of possible combinations is not too large. However | possible combinations is not too large. However the need for multiple | |||
the need for multiple blocks of redundancy greatly increases the | blocks of redundancy greatly increases the number of encoding combinations | |||
number of encoding combinations and makes this solution not viable. | and makes this solution not viable. | |||
A modified version of the above solution could be to decide prior | A modified version of the above solution could be to decide prior | |||
to the beginning of a conference on a set a 32 encoding combinations | to the beginning of a conference on a set a 32 encoding combinations | |||
that will be used for the duration of the conference. All tools | that will be used for the duration of the conference. All tools | |||
in the conference can be initialized with this working set of encoding | in the conference can be initialized with this working set of encoding | |||
combinations. Communication of the working set could be made through | combinations. Communication of the working set could be made through | |||
the use of an external, out of band, mechanism. Setup is complicated | the use of an external, out of band, mechanism. Setup is complicated | |||
as great care needs to be taken in starting tools with identical | as great care needs to be taken in starting tools with identical | |||
parameters. This scheme is more efficient as only one byte is used | parameters. This scheme is more efficient as only one byte is used | |||
to identify combinations of encodings. | to identify combinations of encodings. | |||
It is felt that the complication inherent in distributing the mapping | It is felt that the complication inherent in distributing the mapping of | |||
of payload types onto combinations of redundant data preclude the | payload types onto combinations of redundant data preclude the use of this | |||
use of this mechanism. | mechanism. | |||
A more flexible solution is to have a single payload type which signifies | ||||
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 | A more flexible solution is to have a single payload type which signifies a | |||
may be enclosed within a single packet. There is, however, a small | packet with redundancy. That packet then becomes a container, encapsulating | |||
overhead since each encapsulated packet must be preceded by a header | multiple payloads into a single RTP packet. Such a scheme is flexible, | |||
indicating the type of data enclosed. This is the preferred solution, | since any amount of redundancy may be encapsulated within a single packet. | |||
since it is both flexible, extensible, and has a relatively low overhead. | There is, however, a small overhead since each encapsulated payload must be | |||
The remainder of this document describes this solution. | 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. | ||||
3 Payload Format Specification | 3 Payload Format Specification | |||
The assignment of an RTP payload type for this new packet format | The assignment of an RTP payload type for this new packet format is outside | |||
is outside the scope of this document, and will not be specified | the scope of this document, and will not be specified here. It is expected | |||
here. It is expected that the RTP profile for a particular class | that the RTP profile for a particular class of applications will assign a | |||
of applications will assign a payload type for this encoding, or | payload type for this encoding, or if that is not done then a payload type | |||
if that is not done then a payload type in the dynamic range shall | in the dynamic range shall be chosen. | |||
be chosen. | ||||
An RTP packet containing redundant data shall have a standard RTP | An RTP packet containing redundant data shall have a standard RTP header, | |||
header, with payload type indicating redundancy. The other fields | with payload type indicating redundancy. The other fields of the RTP | |||
of the RTP header relate to the primary data block of the redundant | header relate to the primary data block of the redundant data. | |||
data. | ||||
Following the RTP header are a number of additional headers, defined | Following the RTP header are a number of additional headers, defined in the | |||
in the figure below, which specify the contents of each of the encodings | figure below, which specify the contents of each of the encodings carried | |||
carried by the packet. Following these additional headers are a | by the packet. Following these additional headers are a number of data | |||
number of data blocks, which contain the standard RTP payload data | blocks, which contain the standard RTP payload data for these encodings. | |||
for these encodings. It is noted that all the headers are aligned | It is noted that all the headers are aligned to a 32 bit boundary, but that | |||
to a 32 bit boundary, but that the payload data will typically not | the payload data will typically not be aligned. If multiple redundant | |||
be aligned. | encodings are carried in a packet, they should correspond to different time | |||
intervals: there is no reason to include multiple copies of data for a | ||||
single time interval within a packet. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|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 header block | F: 1 bit First bit in header indicates whether another header block | |||
follows. If 1 further header blocks follow, if 0 this is the | follows. If 1 further header blocks follow, if 0 this is the | |||
last header block. | last header block. | |||
block PT: 7 bitsRTP payload type for this block. | block PT: 7 bits RTP payload type for this block. | |||
timestamp offset: 14 bitsUnsigned offset of timestamp of this block | timestamp offset: 14 bits Unsigned offset of timestamp of this block | |||
relative to timestamp given in RTP header. The use of an unsigned | relative to timestamp given in RTP header. The use of an unsigned | |||
offset implies that redundant data must be sent after the primary | offset implies that redundant data must be sent after the primary | |||
data, and is hence a time to be subtracted from the current | data, and is hence a time to be subtracted from the current | |||
timestamp to determine the timestamp of the data for which this | timestamp to determine the timestamp of the data for which this | |||
block is the redundancy. | block is the redundancy. | |||
block length: 10 bitsLength in bytes of the corresponding data | ||||
block length: 10 bits Length in bytes of the corresponding data | ||||
block excluding header. | block excluding header. | |||
It is noted that the use of an unsigned timestamp offest limits the | It is noted that the use of an unsigned timestamp offset limits the use of | |||
use of redundant data slightly: it is not possible to send redundancy | redundant data slightly: it is not possible to send redundancy before the | |||
before the primary encoding. This may affect schemes where a low | primary encoding. This may affect schemes where a low bandwidth coding | |||
bandwidth coding suitable for redundancy is produced early in the | suitable for redundancy is produced early in the encoding process, and | |||
encoding process, and hence could feasibly be transmitted early. However, | hence could feasibly be transmitted early. However, the addition of a sign | |||
the addition of a sign bit would unacceptably reduce the range of | bit would unacceptably reduce the range of the timestamp offset, and | |||
the timestamp offset, and increasing the size of the field above | increasing the size of the field above 14 bits limits the block length | |||
14 bits limits the block length field. It seems that limiting redundancy | field. It seems that limiting redundancy to be transmitted after the | |||
to be transmitted after the primary will cause fewer problems than | primary will cause fewer problems than limiting the size of the other | |||
limiting the size of the other fields. | fields. | |||
The timestamp offset for a redundant block is measured in the same | ||||
units as the timestamp of the primary encoding. This does not necessarily | ||||
imply that the redundant block is sampled at the same rate as the | ||||
primary, and if the sampling rates are different, conversion must | ||||
be performed, with the offset being rounded to the nearest sampling | ||||
instant of the redundant audio clock. | ||||
It is further noted that the block length and timestamp offset are | The timestamp offset for a redundant block is measured in the same units as | |||
10 bits, and 14 bits respectively; rather than the more obvious 8 | the timestamp of the primary encoding (ie: audio samples, with the same | |||
and 16 bits. Whilst such an encoding complicates parsing the header | clock rate as the primary). The implication of this is that the redundant | |||
information slightly, and adds some additional processing overhead, | encoding MUST be sampled at the same rate as the primary. | |||
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, | It is further noted that the block length and timestamp offset are 10 bits, | |||
possible encodings: for example 80ms PCM and DVI audio packets comprise | and 14 bits respectively; rather than the more obvious 8 and 16 bits. | |||
more than 256 bytes, and cannot be encoded with a single byte length | Whilst such an encoding complicates parsing the header information | |||
field. It is possible to impose additional structure on the block | slightly, and adds some additional processing overhead, there are a number | |||
length field (for example the high bit set could imply the lower | of problems involved with the more obvious choice: An 8 bit block length | |||
7 bits code a length in words, rather than bytes), however such schemes | field is sufficient for most, but not all, possible encodings: for example | |||
are complex. The use of a 10 bit block length field retains simplicity | 80ms PCM and DVI audio packets comprise more than 256 bytes, and cannot be | |||
and provides an enlarged range, at the expense of a reduced range | encoded with a single byte length field. It is possible to impose | |||
of timestamp values. A 14 bit timestamp value does, however, allow | additional structure on the block length field (for example the high bit | |||
for 4.5 complete packets delay with 48KHz audio, more at lower sampling | set could imply the lower 7 bits code a length in words, rather than | |||
rates, and it is felt that this is sufficient. | 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. | ||||
The primary encoding block header is placed last in the packet. It | The primary encoding block header is placed last in the packet. It | |||
is therefore possible to omit the timestamp and block-length fields | is therefore possible to omit the timestamp and block-length fields | |||
from the header of this block, since they may be determined from | from the header of this block, since they may be determined from | |||
the RTP header and overall packet length. The header for the primary | the RTP header and overall packet length. The header for the primary | |||
(final) block comprises only a zero F bit, and the block payload | (final) block comprises only a zero F bit, and the block payload | |||
type information, a total of 8 bits. This is illustrated in the | type information, a total of 8 bits. This is illustrated in the | |||
figure below: | figure below: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|0| Block PT | | |0| Block PT | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
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 | The final header is followed, immediately, by the data blocks, stored in | |||
between the data blocks, and they are typically not 32 bit aligned. | the same order as the headers. There is no padding or other delimiter | |||
Again, this choice was made to reduce bandwidth overheads, at the | between the data blocks, and they are typically not 32 bit aligned. Again, | |||
expense of additional decoding time. | this choice was made to reduce bandwidth overheads, at the expense of | |||
additional decoding time. | ||||
The choice of encodings used should reflect the bandwidth requirements of | ||||
those encodings. It is expected that the redundant encoding shall use | ||||
significantly less bandwidth that the primary encoding: the exception | ||||
being the case where the primary is very low-bandwidth and has high | ||||
processing requirement, in which case a copy of the primary MAY be used as | ||||
the redundancy. The redundant encoding MUST NOT be higher bandwidth than | ||||
the primary. | ||||
The use of multiple levels of redundancy is rarely necessary. However, in | ||||
those cases which require it, the bandwidth required by each level of | ||||
redundancy is expected to be significantly less than that of the previous | ||||
level. | ||||
4 Limitations | 4 Limitations | |||
The RTP marker bit is not preserved for redundant data blocks. Hence | The RTP marker bit is not preserved for redundant data blocks. Hence | |||
if the primary (containing this marker) is lost, the marker is lost. | if the primary (containing this marker) is lost, the marker is lost. | |||
It is believed that this will not cause undue problems: even if | It is believed that this will not cause undue problems: even if | |||
the marker bit was transmitted with the redundant information, there | the marker bit was transmitted with the redundant information, there | |||
would still be the possibility of its loss, so applications would | would still be the possibility of its loss, so applications would | |||
still have to be written with this in mind. | still have to be written with this in mind. | |||
In addition, CSRC information is not preserved for redundant data. | In addition, CSRC information is not preserved for redundant data. | |||
The CSRC data in the RTP header of a redundant audio packet relates | 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 the primary only. Since CSRC data in an audio stream is expected | |||
to change relatively infrequently, it is recommended that applications | to change relatively infrequently, it is recommended that applications | |||
which require this information assume that the CSRC data in the RTP | which require this information assume that the CSRC data in the RTP | |||
header may be applied to the reconstructed redundant data. | header may be applied to the reconstructed redundant data. | |||
5 Relation to SDP | 5 Relation to SDP | |||
When a redundant payload is used, it may need to be bound to an | When a redundant payload is used, it may need to be bound to an RTP dynamic | |||
RTP dynamic payload type. This may be achieved through any out-of-band | payload type. This may be achieved through any out-of-band mechanism, but | |||
mechanism, but one common way is to communicate this binding using | one common way is to communicate this binding using the Session Description | |||
the Session Description Protocol (SDP) [6]. SDP has a mechanism | Protocol (SDP) [6]. SDP has a mechanism for binding a dynamic payload | |||
for binding a dynamic payload types to particular codec, sample rate, | types to particular codec, sample rate, and number of channels using the | |||
and number of channels using the ``rtpmap'' attribute. An example | ``rtpmap'' attribute. An example of its use (using the RTP audio/video | |||
of its use is: | profile [3]) is: | |||
m=audio 12345 RTP/AVP 121 0 5 | m=audio 12345 RTP/AVP 121 0 5 | |||
a=rtpmap:121 red/8000/1 | a=rtpmap:121 red/8000/1 | |||
This specifies that an audio stream using RTP is using payload types | This specifies that an audio stream using RTP is using payload types 121 (a | |||
121 (a dynamic payload type), 0 (PCM u-law) and 5 (DVI). The ``rtpmap'' | dynamic payload type), 0 (PCM u-law) and 5 (DVI). The ``rtpmap'' attribute | |||
attribute is used to bind payload type 121 to codec ``red'' indicating | is used to bind payload type 121 to codec ``red'' indicating this codec is | |||
this codec is actually a redundancy frame, 8KHz, and monoaural. When | actually a redundancy frame, 8KHz, and monaural. When used with SDP, the | |||
used with SDP, the term ``red'' is used to indicate the redundancy | term ``red'' is used to indicate the redundancy format discussed in this | |||
format discussed in this document. | document. | |||
In this case the additional formats of PCM and DVI are specified. | In this case the additional formats of PCM and DVI are specified. The | |||
The receiver must therefore be prepared to use these formats. Such | receiver must therefore be prepared to use these formats. Such a | |||
a specification means the sender will send redundancy by default, | specification means the sender will send redundancy by default, but also | |||
but also may send PCM or DVI. However, with a redundant payload we | may send PCM or DVI. However, with a redundant payload we additionally take | |||
additionally take this to mean that no codec other than PCM or DVI | this to mean that no codec other than PCM or DVI will be used in the | |||
will be used in the redundant encodings. | redundant encodings. Note that the additional payload formats defined in | |||
the ``m='' field may themselves be dynamic payload types, and if so a | ||||
number of additional ``a='' attributes may be required to describe these | ||||
dynamic payload types. | ||||
To receive a redundant stream, this is all that is required. However to | ||||
send a redundant stream, the sender needs to know which codecs are | ||||
recommended for the primary and secondary (and tertiary, etc) encodings. | ||||
This information is specific to the redundancy format, and is specified | ||||
using an additional attribute ``fmtp'' which conveys format-specific | ||||
information. A session directory does not parse the values specified in an | ||||
fmtp attribute but merely hands it to the media tool unchanged. For | ||||
redundancy, we define the format parameters to be a slash ``/'' separated | ||||
list of RTP payload types. | ||||
To receive a redundant stream, this is all that is required. However | ||||
to send a redundant stream, the sender needs to know which codecs | ||||
are recommended for the primary and secondary (and tertiary, etc) | ||||
encodings. This information is specific to the redundancy format, | ||||
and is specified using an additional attribute ``fmtp'' which conveys | ||||
format-specific information. A session directory does not parse the | ||||
values specified in an fmtp attribute but merely hands it to the | ||||
media tool unchanged. For redundancy, we define the format parameters | ||||
to be a slash ``/'' separated list of RTP payload types. | ||||
Thus a complete example is: | Thus a complete example is: | |||
m=audio 12345 RTP/AVP 121 0 5 | m=audio 12345 RTP/AVP 121 0 5 | |||
a=rtpmap:121 red/8000/1 | a=rtpmap:121 red/8000/1 | |||
a=fmtp:121 0/5 | a=fmtp:121 0/5 | |||
This specifies that the default format for senders is redundancy | This specifies that the default format for senders is redundancy with PCM | |||
with PCM as the primary encoding and DVI as the secondary encoding. | as the primary encoding and DVI as the secondary encoding. Encodings | |||
Encodings cannot be specified in the fmtp attribute unless they are | cannot be specified in the fmtp attribute unless they are also specified as | |||
also specified as valid encodings on the media (``m='') line. | valid encodings on the media (``m='') line. | |||
6 Security Considerations | 6 Security Considerations | |||
RTP packets containing redundant information are subject to the security | RTP packets containing redundant information are subject to the security | |||
considerations discussed in the RTP specification [2], and any appropriate | considerations discussed in the RTP specification [2], and any appropriate | |||
RTP profile (for example [3]). This implies that confidentiality | RTP profile (for example [3]). This implies that confidentiality of the | |||
of the media streams is achieved by encryption. | media streams is achieved by encryption. Encryption of a redundant data | |||
stream may occur in two ways: | ||||
Encryption of a redundant data-stream may occur in two ways: | ||||
1.The entire stream is to be secured, and all participants are | 1. The entire stream is to be secured, and all participants are | |||
expected to have keys to decode the entire stream. In this | expected to have keys to decode the entire stream. In this | |||
case, nothing special need be done, and encryption is performed | case, nothing special need be done, and encryption is performed | |||
in the usual manner. | in the usual manner. | |||
2.A portion of the stream is to be encrypted with a different | 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 | key to the remainder. In this case a redundant copy of the | |||
last packet of that portion cannot be sent, since there is no | last packet of that portion cannot be sent, since there is no | |||
following packet which is encrypted with the correct key in which | following packet which is encrypted with the correct key in which | |||
to send it. Similar limitations may occur when enabling/disabling | to send it. Similar limitations may occur when enabling/disabling | |||
encryption. | encryption. | |||
The choice between these two is a matter for the encoder only. Decoders | The choice between these two is a matter for the encoder only. Decoders | |||
can decrypt either form without modification. | can decrypt either form without modification. | |||
Whilst the addition of low-bandwidth redundancy to an audio stream is an | ||||
effective means by which that stream may be protected against packet loss, | ||||
application designers should be aware that the addition of large amounts of | ||||
redundancy will increase network congestion, and hence packet loss, leading | ||||
to a worsening of the problem which the use of redundancy was intended to | ||||
solve. At its worst, this can lead to excessive network congestion and may | ||||
constitute a denial of service attack. | ||||
7 Example Packet | 7 Example Packet | |||
An RTP audio data packet containing a DVI4 (8KHz) primary, and a | An RTP audio data packet containing a DVI4 (8KHz) primary, and a | |||
single block of redundancy encoded using 8KHz LPC (both 20ms packets) | single block of redundancy encoded using 8KHz LPC (both 20ms packets), | |||
is illustrated: | as defined in the RTP audio/video profile [3] 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=0 |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 (PT=7) + | + LPC encoded redundant data (PT=7) + | |||
| (14 bytes) | | | (14 bytes) | | |||
+ +---------------+ | + +---------------+ | |||
| | | | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
+ + | + + | |||
| | | | | | |||
+ + | + + | |||
| | | | | | |||
+ + | + + | |||
| DVI4 encoded primary data (PT=5) | | | DVI4 encoded primary data (PT=5) | | |||
+ (84 bytes, not to scale) + | + (84 bytes, not to scale) + | |||
/ / | / / | |||
+ + | + + | |||
| | | | | | |||
+ + | + + | |||
| | | | | | |||
+ +---------------+ | + +---------------+ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
8 Author's Addresses | 8 Author's Addresses | |||
Colin Perkins/Isidor Kouvelas/Vicky Hardman | Colin Perkins/Isidor Kouvelas/Orion Hodson/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: {c.perkins|i.kouvelas|v.hardman}@cs.ucl.ac.uk | Email: {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk | |||
Mark Handley | Mark Handley | |||
USC Information Sciences Institute | USC Information Sciences Institute | |||
c/o MIT Laboratory for Computer Science | c/o MIT Laboratory for Computer Science | |||
545 Technology Square | 545 Technology Square | |||
Cambridge, MA 02139, USA | Cambridge, MA 02139, USA | |||
Email: mjh@isi.edu | 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|avega}@sophia.inria.fr | Email: {bolot|avega|sfosse}@sophia.inria.fr | |||
9 References | 9 References | |||
[1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable | [1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable | |||
Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, | Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, | |||
Hawaii, September 1995. http://www.isoc.org/in95prc/ | Hawaii, September 1995. http://www.isoc.org/in95prc/ | |||
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson; RTP: | [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson; RTP: | |||
A Transport Protocol for Real-Time Applications; RFC 1889, January | A Transport Protocol for Real-Time Applications; RFC 1889, January | |||
1996 | 1996 | |||
[3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with | [3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with | |||
Minimal Control; RFC 1890, January 1996 | Minimal Control; RFC 1890, January 1996 | |||
[4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation | [4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation | |||
in the MBone multicast network; IEEE Globecom Internet workshop, London, | in the MBone multicast network; IEEE Globecom Internet workshop, London, | |||
November 1996 | November 1996 | |||
[5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error | [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error | |||
control for packet audio in the Internet; Multimedia Systems, 1997 | control for packet audio in the Internet; ACM Multimedia Systems, | |||
1997 | ||||
[6] M. Handley and V. Jacobson; SDP: Session Description Protocol | [6] M. Handley and V. Jacobson; SDP: Session Description Protocol | |||
(draft 03.2) draft-ietf-mmusic-sdp-03.txt, November 1996 | (draft 03.2) draft-ietf-mmusic-sdp-03.txt, November 1996 | |||
End of changes. 49 change blocks. | ||||
201 lines changed or deleted | 226 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/ |