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/