Request for Comments: 4588 Panasonic
Category: Standards Track D. Leon
Consultant
A. Miyazaki
Panasonic
V. Varsa
Nokia
R. Hakenberg
Panasonic
July 2006
RTP Retransmission Payload Format
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
RTP retransmission is an effective packet loss recovery technique for
real-time applications with relaxed delay bounds. This document
describes an RTP payload format for performing retransmissions.
Retransmitted RTP packets are sent in a separate stream from the
original RTP stream. It is assumed that feedback from receivers to
senders is available. In particular, it is assumed that Real-time
Transport Control Protocol (RTCP) feedback as defined in the extended
RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available
in this memo.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements and Design Rationale for a Retransmission Scheme ...4
3.1. Multiplexing Scheme Choice .................................6
4. Retransmission Payload Format ...................................7
5. Association of Retransmission and Original Streams ..............9
5.1. Retransmission Session Sharing .............................9
5.2. CNAME Use ..................................................9
5.3. Association at the Receiver ................................9
6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1. RTCP at the Sender ........................................11
6.2. RTCP Receiver Reports .....................................11
6.3. Retransmission Requests ...................................12
6.4. Timing Rules ..............................................13
7. Congestion Control .............................................13
8. Retransmission Payload Format MIME Type Registration ...........15
8.1. Introduction ..............................................15
8.2. Registration of audio/rtx .................................16
8.3. Registration of video/rtx .................................17
8.4. Registration of text/rtx ..................................18
8.5. Registration of application/rtx ...........................19
8.6. Mapping to SDP ............................................20
8.7. SDP Description with Session-Multiplexing .................20
8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP Considerations ............................................22
9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2. RTSP Control with Session-Multiplexing ....................22
9.3. RTSP Control of the Retransmission Stream .................23
9.4. Cache Control .............................................23
10. Implementation Examples .......................................23
10.1. A Minimal Receiver Implementation Example ................24
10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA Considerations ...........................................26
12. Security Considerations .......................................26
13. Acknowledgements ..............................................27
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
Appendix A. How to Control the Number of Rtxs. per Packet .........29
1. Introduction
Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received media. Several techniques, such
as forward error correction (FEC), retransmissions, or interleaving,
may be considered to increase packet loss resiliency. RFC 2354 [8]
discusses the different options.
When choosing a repair technique for a particular application, the
tolerable latency of the application has to be taken into account.
In the case of multimedia conferencing, the end-to-end delay has to
be at most a few hundred milliseconds in order to guarantee
interactivity, which usually excludes the use of retransmission.
With sufficient latency, the efficiency of the repair scheme can be
increased. The sender may use the receiver feedback in order to
react to losses before their playout time at the receiver.
In the case of multimedia streaming, the user can tolerate an initial
latency as part of the session set-up and thus an end-to-end delay of
several seconds may be acceptable. RTP retransmission as defined in
this document is targeted at such applications.
Furthermore, the RTP retransmission method defined herein is
applicable to unicast and (small) multicast groups. The present
document defines a payload format for retransmitted RTP packets and
provides protocol rules for the sender and the receiver involved in
retransmissions.
This retransmission payload format was designed for use with the
extended RTP profile for RTCP-based feedback, AVPF [1]. It may also
be used with other RTP profiles defined in the future.
The AVPF profile allows for more frequent feedback and for early
feedback. It defines a general-purpose feedback message, i.e., NACK,
as well as codec and application-specific feedback messages. See [1]
for details.
2. Terminology
The following terms are used in this document:
CSRC: contributing source. See [3].
Original packet: an RTP packet that carries user data sent for the
first time by an RTP sender.
Original stream: the RTP stream of original packets.
Retransmission packet: an RTP packet that is to be used by the
receiver instead of a lost original packet. Such a retransmission
packet is said to be associated with the original RTP packet.
Retransmission request: a means by which an RTP receiver is able to
request that the RTP sender should send a retransmission packet for a
given original packet. Usually, an RTCP NACK packet as specified in
[1] is used as retransmission request for lost packets.
Retransmission stream: the stream of retransmission packets
associated with an original stream.
Session-multiplexing: scheme by which the original stream and the
associated retransmission stream are sent into two different RTP
sessions.
SSRC: synchronization source. See [3].
SSRC-multiplexing: scheme by which the original stream and the
retransmission stream are sent in the same RTP session with different
SSRC values.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
3. Requirements and Design Rationale for a Retransmission Scheme
The use of retransmissions in RTP as a repair method for streaming
media is appropriate in those scenarios with relaxed delay bounds and
where full reliability is not a requirement. More specifically, RTP
retransmission allows one to trade off reliability vs. delay; i.e.,
the endpoints may give up retransmitting a lost packet after a given
buffering time has elapsed. Unlike TCP, there is thus no head-of-
line blocking caused by RTP retransmissions. The implementer should
be aware that in cases where full reliability is required or higher
delay and jitter can be tolerated, TCP or other transport options
should be considered.
The RTP retransmission scheme defined in this document is designed to
fulfill the following set of requirements:
1. It must not break general RTP and RTCP mechanisms.
2. It must be suitable for unicast and small multicast groups.
3. It must work with mixers and translators.
4. It must work with all known payload types.
5. It must not prevent the use of multiple payload types in a
session.
6. In order to support the largest variety of payload formats, the
RTP receiver must be able to derive how many and which RTP packets
were lost as a result of a gap in received RTP sequence numbers.
This requirement is referred to as sequence number preservation.
Without such a requirement, it would be impossible to use
retransmission with payload formats, such as conversational text
[9] or most audio/video streaming applications, that use the RTP
sequence number to detect lost packets.
When designing a solution for RTP retransmission, several approaches
may be considered for the multiplexing of the original RTP packets
and the retransmitted RTP packets.
One approach may be to retransmit the RTP packet with its original
sequence number and send original and retransmission packets in the
same RTP stream. The retransmission packet would then be identical
to the original RTP packet, i.e., the same header (and thus same
sequence number) and the same payload. However, such an approach is
not acceptable because it would corrupt the RTCP statistics. As a
consequence, requirement 1 would not be met. Correct RTCP statistics
require that for every RTP packet within the RTP stream, the sequence
number be increased by one.
Another approach may be to multiplex original RTP packets and
retransmission packets in the same RTP stream using different payload
type values. With such an approach, the original packets and the
retransmission packets would share the same sequence number space.
As a result, the RTP receiver would not be able to infer how many and
which original packets (which sequence numbers) were lost.
In other words, this approach does not satisfy the sequence number
preservation requirement (requirement 6). This in turn implies that
requirement 4 would not be met. Interoperability with mixers and
translators would also be more difficult if they did not understand
this new retransmission payload type in a sender RTP stream. For
these reasons, a solution based on payload type multiplexing of
original packets and retransmission packets in the same RTP stream is
excluded.
Finally, the original and retransmission packets may be sent in two
separate streams. These two streams may be multiplexed either by
sending them in two different sessions , i.e., session-multiplexing,
or in the same session using different SSRC values, i.e., SSRC-
multiplexing. Since original and retransmission packets carry media
of the same type, the objections in Section 5.2 of RTP [3] to RTP
multiplexing do not apply in this case.
Mixers and translators may process the original stream and simply
discard the retransmission stream if they are unable to utilise it.
On the other hand, sending the original and retransmission packets in
two separate streams does not alone satisfy requirements 1 and 6.
For this purpose, this document includes the original sequence number
in the retransmitted packets.
In this manner, using two separate streams satisfies all the
requirements listed in this section.
3.1. Multiplexing Scheme Choice
Session-multiplexing and SSRC-multiplexing have different pros and
cons:
Session-multiplexing is based on sending the retransmission stream in
a different RTP session (as defined in RTP [3]) from that of the
original stream; i.e., the original and retransmission streams are
sent to different network addresses and/or port numbers. Having a
separate session allows more flexibility. In multicast, using two
separate sessions for the original and the retransmission streams
allows a receiver to choose whether or not to subscribe to the RTP
session carrying the retransmission stream. The original session may
also be single-source multicast while separate unicast sessions are
used to convey retransmissions to each of the receivers, which as a
result will receive only the retransmission packets they request.
The use of separate sessions also facilitates differential treatment
by the network and may simplify processing in mixers, translators,
and packet caches.
With SSRC-multiplexing, a single session is needed for the original
and the retransmission streams. This allows streaming servers and
middleware that are involved in a high number of concurrent sessions
to minimise their port usage.
This retransmission payload format allows both session-multiplexing
and SSRC-multiplexing for unicast sessions. From an implementation
point of view, there is little difference between the two approaches.
Hence, in order to maximise interoperability, both multiplexing
approaches SHOULD be supported by senders and receivers. For
multicast sessions, session-multiplexing MUST be used because the
association of the original stream and the retransmission stream is
problematic if SSRC-multiplexing is used with multicast sessions(see
Section 5.3 for motivation).
4. Retransmission Payload Format
The format of a retransmission packet is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP header usage is as follows:
In the case of session-multiplexing, the same SSRC value MUST be used
for the original stream and the retransmission stream. In the case
of an SSRC collision in either the original session or the
retransmission session, the RTP specification requires that an RTCP
BYE packet MUST be sent in the session where the collision happened.
In addition, an RTCP BYE packet MUST also be sent for the associated
stream in its own session. After a new SSRC identifier is obtained,
the SSRC of both streams MUST be set to this value.
In the case of SSRC-multiplexing, two different SSRC values MUST be
used for the original stream and the retransmission stream as
required by RTP. If an SSRC collision is detected for either the
original stream or the retransmission stream, the RTP specification
requires that an RTCP BYE packet MUST be sent for this stream. An
RTCP BYE packet MUST NOT be sent for the associated stream.
Therefore, only the stream that experienced SSRC collision MUST
choose a new SSRC value. Refer to Section 5.3 for the implications
on the original stream and retransmission stream SSRC association at
the receiver.
For either multiplexing scheme, the sequence number has the standard
definition; i.e., it MUST be one higher than the sequence number of
the preceding packet sent in the retransmission stream.
The retransmission packet timestamp MUST be set to the original
timestamp, i.e., to the timestamp of the original packet. As a
consequence, the initial RTP timestamp for the first packet of the
retransmission stream is not random but equal to the original
timestamp of the first packet that is retransmitted. See the
Security Considerations section in this document for security
implications.
Implementers have to be aware that the RTCP jitter value for the
retransmission stream does not reflect the actual network jitter
since there could be little correlation between the time a packet is
retransmitted and its original timestamp.
The payload type is dynamic. If multiple payload types using
retransmission are present in the original stream, then for each of
these, a dynamic payload type MUST be mapped to the retransmission
payload format. See Section 8.1 for the specification of how the
mapping between original and retransmission payload types is done
with Session Description Protocol (SDP).
As the retransmission packet timestamp carries the original media
timestamp, the timestamp clockrate used by the retransmission payload
type MUST be the same as the one used by the associated original
payload type. Therefore, if an RTP stream carries payload types of
different clockrates, this will also be the case for the associated
retransmission stream. Note that an RTP stream does not usually
carry payload types of different clockrates.
The payload of the RTP retransmission packet comprises the
retransmission payload header followed by the payload of the original
RTP packet. The length of the retransmission payload header is 2
octets. This payload header contains only one field, OSN (original
sequence number), which MUST be set to the sequence number of the
associated original RTP packet. The original RTP packet payload,
including any possible payload headers specific to the original
payload type, MUST be placed right after the retransmission payload
header.
For payload formats that support encoding at multiple rates, instead
of retransmitting the same payload as the original RTP packet the
sender MAY retransmit the same data encoded at a lower rate. This
aims at limiting the bandwidth usage of the retransmission stream.
When doing so, the sender MUST ensure that the receiver will still be
able to decode the payload of the already sent original packets that
might have been encoded based on the payload of the lost original
packet. In addition, if the sender chooses to retransmit at a lower
rate, the values in the payload header of the original RTP packet may
no longer apply to the retransmission packet and may need to be
modified in the retransmission packet to reflect the change in rate.
The sender SHOULD trade off the decrease in bandwidth usage with the
decrease in quality caused by resending at a lower rate.
If the original RTP header carried any profile-specific extensions,
the retransmission packet SHOULD include the same extensions
immediately following the fixed RTP header as expected by
applications running under this profile. In this case, the
retransmission payload header MUST be placed after the profile-
specific extensions.
If the original RTP header carried an RTP header extension, the
retransmission packet SHOULD carry the same header extension. This
header extension MUST be placed right after the fixed RTP header, as
specified in RTP [3]. In this case, the retransmission payload
header MUST be placed after the header extension.
If the original RTP packet contained RTP padding, that padding MUST
be removed before constructing the retransmission packet. If padding
of the retransmission packet is needed, padding MUST be performed as
with any RTP packets and the padding bit MUST be set.
The marker bit (M), the CSRC count (CC), and the CSRC list of the
original RTP header MUST be copied "as is" into the RTP header of the
retransmission packet.
5. Association of Retransmission and Original Streams
5.1. Retransmission Session Sharing
In the case of session-multiplexing, a retransmission session MUST
map to exactly one original session; i.e., the same retransmission
session cannot be used for different original sessions.
If retransmission session sharing were allowed, it would be a problem
for receivers, since they would receive retransmissions for original
sessions they might not have joined. For example, a receiver wishing
to receive only audio would receive also retransmitted video packets
if an audio and video session shared the same retransmission session.
5.2. CNAME Use
In both the session-multiplexing and the SSRC-multiplexing cases, a
sender MUST use the same RTCP CNAME [3] for an original stream and
its associated retransmission stream.
5.3. Association at the Receiver
A receiver receiving multiple original and retransmission streams
needs to associate each retransmission stream with its original
stream. The association is done differently depending on whether
session-multiplexing or SSRC-multiplexing is used.
If session-multiplexing is used, the receiver associates the two
streams having the same SSRC in the two sessions. Note that the
payload type field cannot be used to perform the association as
several media streams may have the same payload type value. The two
sessions are themselves associated out-of-band. See Section 8 for
how the grouping of the two sessions is done with SDP.
If SSRC-multiplexing is used, the receiver should first of all look
for two streams that have the same CNAME in the session. In some
cases, the CNAME may not be enough to determine the association as
multiple original streams in the same session may share the same
CNAME. For example, there can be in the same video session multiple
video streams mapping to different SSRCs and still using the same
CNAME and possibly the same payload type (PT) values. Each (or some)
of these streams may have an associated retransmission stream.
In this case, in order to find out the association between original
and retransmission streams having the same CNAME, the receiver SHOULD
behave as follows.
The association can generally be resolved when the receiver receives
a retransmission packet matching a retransmission request that had
been sent earlier. Upon reception of a retransmission packet whose
original sequence number has been previously requested, the receiver
can derive that the SSRC of the retransmission packet is associated
to the sender SSRC from which the packet was requested.
However, this mechanism might fail if there are two outstanding
requests for the same packet sequence number in two different
original streams of the session. Note that since the initial packet
sequence numbers are random, the probability of having two
outstanding requests for the same packet sequence number would be
very small. Nevertheless, in order to avoid ambiguity in the unicast
case, the receiver MUST NOT have two outstanding requests for the
same packet sequence number in two different original streams before
the association is resolved. In multicast, this ambiguity cannot be
completely avoided, because another receiver may have requested the