As per Relevance of the word timestamp, we have this rfc below:
Network Working Group C.
Request for Comments: 2198 I.
Category: Standards Track O.
V.
University College
M.
J.C.
A. Vega-
S. Fosse-
INRIA Sophia
September 1997
RTP Payload for Redundant Audio
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes a payload format for use with the real-
transport protocol (RTP), version 2, for encoding redundant
data. The primary motivation for the scheme described herein is
development of audio conferencing tools for use with lossy
networks such as the Internet Mbone, although this scheme is
limited to such applications
1
If multimedia conferencing is to become widely used by the
Mbone community, users must perceive the quality to be
good for most applications. We have identified a number of
which impair the quality of conferences, the most significant
which is packet loss. This is a persistent problem,
given the increasing popularity, and therefore increasing load,
the Internet. The disruption of speech intelligibility even at
loss rates which is currently experienced may convince a
generation of users that multimedia conferencing over the Internet
not viable. The addition of redundancy to the data stream is
as a solution [1]. If a packet is lost then the missing
may be reconstructed at the receiver from the redundant data
arrives in the following packet(s), provided that the average
Perkins, et. al. Standards Track [Page 1]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
of consecutively lost packets is small. Recent work [4,5] shows
packet loss patterns in the Internet are such that this
typically functions well
This document describes an RTP payload format for the transmission
audio data encoded in such a redundant fashion. Section 2
the requirements and motivation leading to the definition of
payload format, and does not form part of the payload
definition. Sections 3 onwards define the RTP payload format
redundant audio data
2 Requirements/
The requirements for a redundant encoding scheme under RTP are
follows
o Packets have to carry a primary encoding and one or
redundant encodings
o As a multitude of encodings may be used for
information, each block of redundant encoding has to have
encoding type identifier
o As the use of variable size encodings is desirable, each
block in the packet has to have a length indicator
o The RTP header provides a timestamp field that corresponds
the time of creation of the encoded data. When
encodings are used this timestamp field can refer to the time
creation of the primary encoding data. Redundant blocks of
will correspond to different time intervals than the
data, and hence each block of redundant encoding will require
own timestamp. To reduce the number of bytes needed to carry
timestamp, it can be encoded as the difference of the
for the redundant encoding and the timestamp of the primary
There are two essential means by which redundant audio may be
to the standard RTP specification: a header extension may hold
redundancy, or one, or more, additional payload types may be defined
Including all the redundancy information for a packet in a
extension would make it easy for applications that do not
redundancy to discard it and just process the primary encoding data
There are, however, a number of disadvantages with this scheme
Perkins, et. al. Standards Track [Page 2]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
o There is a large overhead from the number of bytes needed
the extension header (4) and the possible padding that is
at the end of the extension to round up to a four byte
(up to 3 bytes). For many applications this overhead
unacceptable
o Use of the header extension limits applications to a
redundant encoding, unless further structure is introduced
the extension. This would result in further overhead
For these reasons, the use of RTP header extension to hold
audio encodings is disregarded
The RTP profile for audio and video conferences [3] lists a set
payload types and provides for a dynamic range of 32 encodings
may be defined through a conference control protocol. This leads
two possible schemes for assigning additional RTP payload types
redundant audio applications
1.A dynamic encoding scheme may be defined, for each
of primary/redundant payload types, using the RTP dynamic
type range
2.A single fixed payload type may be defined to represent a
with redundancy. This may then be assigned to either a
RTP payload type, or the payload type for this may be
dynamically
It is possible to define a set of payload types that signify
particular combination of primary and secondary encodings for each
the 32 dynamic payload types provided. This would be a
restrictive yet feasible solution for packets with a single block
redundancy as the number of possible combinations is not too large
However the need for multiple blocks of redundancy greatly
the number of encoding combinations and makes this solution
viable
A modified version of the above solution could be to decide prior
the beginning of a conference on a set a 32 encoding
that will be used for the duration of the conference. All tools
the conference can be initialized with this working set of
combinations. Communication of the working set could be made
the use of an external, out of band, mechanism. Setup is
as great care needs to be taken in starting tools with
parameters. This scheme is more efficient as only one byte is
to identify combinations of encodings
Perkins, et. al. Standards Track [Page 3]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
It is felt that the complication inherent in distributing the
of payload types onto combinations of redundant data preclude the
of this mechanism
A more flexible solution is to have a single payload type
signifies a packet with redundancy. That packet then becomes
container, encapsulating multiple payloads into a single RTP packet
Such a scheme is flexible, since any amount of redundancy may
encapsulated within a single packet. There is, however, a
overhead since each encapsulated payload must be preceded by a
indicating the type of data enclosed. This is the
solution, since it is both flexible, extensible, and has a
low overhead. The remainder of this document describes
solution
3 Payload Format
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC2119 [7].
The assignment of an RTP payload type for this new packet format
outside the scope of this document, and will not be specified here
It is expected that the RTP profile for a particular class
applications will assign a payload type for this encoding, or if
is not done then a payload type in the dynamic range shall be chosen
An RTP packet containing redundant data shall have a standard
header, with payload type indicating redundancy. The other fields
the RTP header relate to the primary data block of the
data
Following the RTP header are a number of additional headers,
in the figure below, which specify the contents of each of
encodings carried by the packet. Following these additional
are a number of data blocks, which contain the standard RTP
data for these encodings. It is noted that all the headers
aligned to a 32 bit boundary, but that the payload data
typically not be aligned. If multiple redundant encodings
carried in a packet, they should correspond to different
intervals: there is no reason to include multiple copies of data
a single time interval within a packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins, et. al. Standards Track [Page 4]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
The bits in the header are specified as follows
F: 1 bit First bit in header indicates whether another header
follows. If 1 further header blocks follow, if 0 this is
last header block
block PT: 7 bits RTP payload type for this block
timestamp offset: 14 bits Unsigned offset of timestamp of this
relative to timestamp given in RTP header. The use of an
offset implies that redundant data must be sent after the
data, and is hence a time to be subtracted from the
timestamp to determine the timestamp of the data for which
block is the redundancy
block length: 10 bits Length in bytes of the corresponding
block excluding header
It is noted that the use of an unsigned timestamp offset limits
use of redundant data slightly: it is not possible to
redundancy before the primary encoding. This may affect
where a low bandwidth coding suitable for redundancy is
early in the encoding process, and hence could feasibly
transmitted early. However, the addition of a sign bit
unacceptably reduce the range of the timestamp offset, and
the size of the field above 14 bits limits the block length field
It seems that limiting redundancy to be transmitted after the
will cause fewer problems than limiting the size of the other fields
The timestamp offset for a redundant block is measured in the
units as the timestamp of the primary encoding (ie: audio samples
with the same clock rate as the primary). The implication of this
that the redundant encoding MUST be sampled at the same rate as
primary
It is further noted that the block length and timestamp offset are 10
bits, and 14 bits respectively; rather than the more obvious 8 and 16
bits. Whilst such an encoding complicates parsing the
information slightly, and adds some additional processing overhead
there are a number of problems involved with the more obvious choice
An 8 bit block length field is sufficient for most, but not all
possible encodings: for example 80ms PCM and DVI audio
comprise more than 256 bytes, and cannot be encoded with a
byte length field. It is possible to impose additional structure
the block length field (for example the high bit set could imply
lower 7 bits code a length in words, rather than bytes), however
schemes are complex. The use of a 10 bit block length field
Perkins, et. al. Standards Track [Page 5]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
simplicity and provides an enlarged range, at the expense of
reduced range of timestamp values
The primary encoding block header is placed last in the packet.
is therefore possible to omit the timestamp and block-length
from the header of this block, since they may be determined from
RTP header and overall packet length. The header for the
(final) block comprises only a zero F bit, and the block payload
information, a total of 8 bits. This is illustrated in the
below
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| Block PT |
+-+-+-+-+-+-+-+-+
The final header is followed, immediately, by the data blocks,
in the same order as the headers. There is no padding or
delimiter between the data blocks, and they are typically not 32
aligned. Again, this choice was made to reduce bandwidth overheads
at the expense of additional decoding time
The choice of encodings used should reflect the
requirements of those encodings. It is expected that the
encoding shall use significantly less bandwidth that the
encoding: the exception being the case where the primary is
low-bandwidth and has high processing requirement, in which case
copy of the primary MAY be used as the redundancy. The
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
each level of redundancy is expected to be significantly less
that of the previous level
4
The RTP marker bit is not preserved for redundant data blocks.
if the primary (containing this marker) is lost, the marker is lost
It is believed that this will not cause undue problems: even if
marker bit was transmitted with the redundant information,
would still be the possibility of its loss, so applications
still have to be written with this in mind
In addition, CSRC information is not preserved for redundant data
The CSRC data in the RTP header of a redundant audio packet
to the primary only. Since CSRC data in an audio stream is
to change relatively infrequently, it is recommended
Perkins, et. al. Standards Track [Page 6]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
applications which require this information assume that the CSRC
in the RTP header may be applied to the reconstructed redundant data
5 Relation to
When a redundant payload is used, it may need to be bound to an
dynamic payload type. This may be achieved through any out-of-
mechanism, but one common way is to communicate this binding
the Session Description Protocol (SDP) [6]. SDP has a mechanism
binding a dynamic payload types to particular codec, sample rate,
number of channels using the "rtpmap" attribute. An example of
use (using the RTP audio/video profile [3]) is
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1
This specifies that an audio stream using RTP is using payload
121 (a dynamic payload type), 0 (PCM u-law) and 5 (DVI). The "rtpmap
attribute is used to bind payload type 121 to codec "red"
this codec is actually a redundancy frame, 8KHz, and monaural.
used with SDP, the term "red" is used to indicate the
format discussed in this document
In this case the additional formats of PCM and DVI are specified
The receiver must therefore be prepared to use these formats. Such
specification means the sender will send redundancy by default,
also may send PCM or DVI. However, with a redundant payload
additionally take this to mean that no codec other than PCM or
will be used in the redundant encodings. Note that the
payload formats defined in the "m=" field may themselves be
payload types, and if so a number of additional "a=" attributes
be required to describe these dynamic payload types
To receive a redundant stream, this is all that is required.
to send a redundant stream, the sender needs to know which codecs
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
format-specific information. A session directory does not parse
values specified in an fmtp attribute but merely hands it to
media tool unchanged. For redundancy, we define the
parameters to be a slash "/" separated list of RTP payload types
Thus a complete example is
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1
a=fmtp:121 0/5
Perkins, et. al. Standards Track [Page 7]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
This specifies that the default format for senders is redundancy
PCM as the primary encoding and DVI as the secondary encoding
Encodings cannot be specified in the fmtp attribute unless they
also specified as valid encodings on the media ("m=") line
6 Security
RTP packets containing redundant information are subject to
security considerations discussed in the RTP specification [2],
any appropriate RTP profile (for example [3]). This implies
confidentiality of the media streams is achieved by encryption
Encryption of a redundant data stream may occur in two ways
1.The entire stream is to be secured, and all participants
expected to have keys to decode the entire stream. In this case
nothing special need be done, and encryption is performed in
usual manner
2.A portion of the stream is to be encrypted with a
key to the remainder. In this case a redundant copy of the
packet of that portion cannot be sent, since there is
following packet which is encrypted with the correct key in
to send it. Similar limitations may occur
enabling/disabling encryption
The choice between these two is a matter for the encoder only
Decoders can decrypt either form without modification
Whilst the addition of low-bandwidth redundancy to an audio stream
an effective means by which that stream may be protected
packet loss, application designers should be aware that the
of large amounts of redundancy will increase network congestion,
hence packet loss, leading to a worsening of the problem which
use of redundancy was intended to solve. At its worst, this can
to excessive network congestion and may constitute a denial
service attack
Perkins, et. al. Standards Track [Page 8]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
7 Example
An RTP audio data packet containing a DVI4 (8KHz) primary, and
single block of redundancy encoded using 8KHz LPC (both 20
packets), as defined in the RTP audio/video profile [3]
illustrated
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| PT | sequence number of primary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp of primary encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=7 | timestamp offset | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=5 | |
+-+-+-+-+-+-+-+-+ +
| |
+ LPC encoded redundant data (PT=7) +
| (14 bytes) |
+ +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ +
| |
+ +
| DVI4 encoded primary data (PT=5) |
+ (84 bytes, not to scale) +
/ /
+ +
| |
+ +
| |
+ +---------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins, et. al. Standards Track [Page 9]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
8 Authors'
Colin Perkins/Isidor Kouvelas/Orion Hodson/Vicky
Department of Computer
University College
London WC1E 6
United
EMail: {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.
Mark
USC Information Sciences
c/o MIT Laboratory for Computer
545 Technology
Cambridge, MA 02139,
EMail: mjh@isi.
Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-
INRIA Sophia
2004 Route des Lucioles, BP 93
06902 Sophia
EMail: {bolot|avega|sfosse}@sophia.inria.
Perkins, et. al. Standards Track [Page 10]
RFC 2198 RTP Payload for Redundant Audio Data September 1997
9
[1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson;
Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu
Hawaii, September 1995. http://www.isoc.org/in95prc
[2] Schulzrinne, H., Casner, S., Frederick R., and V. Jacobson, "RTP
A Transport Protocol for Real-Time Applications", RFC 1889,
1996.
[3] Schulzrinne, H., "RTP Profile for Audio and Video
with Minimal Control", RFC 1890, January 1996.
[4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation
the MBone multicast network; IEEE Globecom Internet workshop, London
November 1996
[5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based
control for packet audio in the Internet; ACM Multimedia Systems
1997
[6] Handley, M., and V. Jacobson, "SDP: Session Description
(draft 03.2)", Work in Progress
[7] Bradner, S., "Key words for use in RFCs to indicate
levels", RFC 2119, March 1997.
Perkins, et. al. Standards Track [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
