draft-ietf-avt-rtp-retransmission-02.txt   draft-ietf-avt-rtp-retransmission-03.txt 
David Leon Internet Draft
Internet Draft Viktor Varsa draft-ietf-avt-rtp-retransmission- Jose Rey/Matsushita
Document: Nokia 03.txt David Leon/Nokia
draft-ietf-avt-rtp-retransmission-02.txt Akihiro Miyazaki/Matsushita
Expires: December 2002 June 2002 Viktor Varsa/Nokia
Rolf Hakenberg/Matsushita
RTP retransmission framework Expires: April 2003 November 2002
RTP Retransmission Payload Format
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract [Note to RFC Editor: This paragraph is to be deleted when this
draft is published as an RFC. References in this draft to RFC XXXX
RTP retransmission is an effective packet loss recovery scheme for should be replaced with the RFC number assigned to this document.
real-time applications with relaxed delay bounds. References in this draft to RFC YYYY should be replaced with the RFC
This document describes an RTP retransmission framework. It defines number assigned the draft-ietf-mmusic-fid when published as RFC.
a payload format for retransmitted packets and recommends rules for References in this draft to RFC ZZZZ should be replaced with the RFC
sending these packets. Retransmitted RTP packets are sent in a number assigned the draft-ietf-avt-rtcp-bw when published as RFC.
separate stream from the original RTP stream. It is assumed that References in this draft to RFC UUUU should be replaced with the
feedback from receivers to senders indicating the occurred packet RFC number assigned the draft-ietf-avt-srtp when published as RFC.
losses is available by some means not defined here. References in this draft to RFC VVVV should be replaced with the RFC
number assigned the draft-ietf-avt-rtcp-feedback when published as
Main changes RFC. References in this draft to RFC WWWW should be replaced with
the RFC number of the revision of RFC 1889 being drafted as draft-
ietf-avt-rtp-new.]
*since draft-ietf-avt-rtp-retransmission-01.txt IETF draft - Expires April 2003 1
IANA considerations section added
New appendix on RTP retransmission and multiplexing. It results from
a discussion on mailing list.
*since draft-ietf-avt-rtp-retransmission-00.txt: Abstract
An applicability statement was added.
The security considerations section was expanded.
Leon, Varsa IETF draft - Expires September 2002 1 RTP retransmission is an effective packet loss recovery technique
RTP retransmission framework June 2002 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 it is available. In particular,
availability of enhanced RTCP feedback as defined in the extended
RTP profile for RTCP-based feedback [1] ( denoted AVPF ) is assumed
in this memo.
*since draft-leon-rtp-retransmission-02.txt: Main changes
The previous version of the draft described the use of the This document is the result of the merging of draft-ietf-avt-selret-
redundancy payload format (RFC 2198) in order to send retransmission 05.txt and draft-ietf-avt-rtp-retransmission-02.txt.
data and original data in the same stream. At IETF #53, it was
concluded that RFC 2198 was not intended to such a use. Piggybacking
retransmitted packets was thus removed from the draft.
Table of Contents Table of Contents
Abstract...........................................................1 Abstract...........................................................2
Main changes.......................................................1 Main changes.......................................................2
1. Introduction....................................................2 1. Introduction....................................................2
2. Terminology.....................................................3 2. Terminology.....................................................3
3. Applicability statement.........................................3 3. Requirements and design rationale for a retransmission scheme...4
4. Retransmission framework basic principles.......................4 4. Retransmission payload format...................................5
5. Retransmission payload format...................................5 5. Association of a retransmission stream with its original stream.7
6. Use with the Extended RTP profile for RTCP-based feedback.......6 6. Use with the extended RTP profile for RTCP-based feedback.......8
7. Congestion control..............................................8 7. Congestion control.............................................10
8. Example scenario of unicast streaming...........................9 8. SDP usage......................................................11
9. SDP usage.......................................................9 9. RTSP considerations............................................14
10. IANA considerations............................................9 10. Implementation examples.......................................15
11. Security consideration........................................11 11. IANA considerations...........................................18
Appendix A: Retransmission and SSRC multiplexing..................12 12. Security considerations.......................................22
Appendix B: FEC for retransmission................................13 13. Acknowledgements..............................................22
References........................................................14 14. References....................................................23
Author's Addresses................................................15 Author's Addresses................................................24
1. Introduction 1. Introduction
Packet losses between an RTP sender and receiver may significantly Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received signal. Several techniques, such degrade the quality of the received media. Several techniques, such
as forward error correction (FEC), retransmissions or application as forward error correction (FEC), retransmissions or interleaving
layer (e.g. video) error resilience adaptation based on back-channel may be considered to increase packet loss resiliency. RFC 2354 [9]
messages may be considered to increase the robustness to packet discusses the different options.
loss. RFC-2354 [1] discusses the different options.
When choosing a technique for a particular system, the tolerable When choosing a repair technique for a particular application, the
latency of the application has to be taken into account. In the case tolerable latency of the application has to be taken into account.
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. On the other hand, in
the case of multimedia streaming, the user can tolerate an initial
latency as part of the session setup and thus an end-to-end delay of
several seconds is possible. Retransmission may thus be considered
for such applications.
Leon, Varsa - Expires December 2002 2 Rey/Leon/Miyazaki/Varsa/Hakenberg 2
RTP retransmission framework June 2002 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.
This document proposes a retransmission framework. It defines a However, in the case of multimedia streaming, the user can tolerate
payload format for retransmitted RTP packets and retransmission an initial latency as part of the session set-up and thus an end-to-
rules. This RTP retransmission scheme requires frequent packet loss end delay of several seconds may be acceptable. Retransmission may
indication feedback to the RTP entity performing retransmission. The thus be considered for such applications.
AV profile [2] does not provide this feature and could therefore not
be used. However, the retransmission scheme could be run under the This document specifies a retransmission method for RTP for unicast
extended RTP profile for RTCP-based feedback[3] which defines a NACK and (small) multicast groups: it defines a payload format for
message that can be sent as part of a compound RTCP packet. retransmitted RTP packets and provides protocol rules for the sender
and the receiver involved in retransmissions.
Furthermore, this retransmission payload format was designed for use
with the extended RTP profile for RTCP-based feedback, AVPF [1]. It
may also be used together with other RTP profiles defined in the
future.
The AVPF profile allows for frequent feedback, early feedback and
defines a small number of general-purpose feedback messages, e.g.
ACKs and NACKs, as well as codec and application-specific feedback
messages. See [1] for details.
2. Terminology 2. Terminology
The following terms are used in this document: The following terms are used in this document:
Original packet: refers to an RTP packet which carries user data Original packet: refers to an RTP packet which carries user data
sent for the first time by an RTP sender. sent for the first time by an RTP sender.
Original stream: refers to the stream of original packets. Original stream: refers to the RTP stream of original packets.
Retransmission packet: refers to an RTP packet whose payload Retransmission packet: refers to an RTP packet whose payload
includes the payload of an already sent original packet. Such a includes the payload and possible header extension of an already
retransmission packet is said to be associated with the original RTP sent original packet. Such a retransmission packet is said to be
packet whose payload is included in the retransmission packet. associated with the original RTP packet.
Retransmission request: a means by which an RTP receiver is able to Retransmission request: a means by which an RTP receiver is able to
request that the RTP sender send a retransmission packet associated request that the RTP sender should send a retransmission packet for
with a given original packet. In [3], a retransmission request is a given original packet. Usually, an RTCP NACK message as specified
sent as a packet loss indication in a NACK message. in [1] is used as retransmission request for lost packets.
Retransmission stream: the stream of retransmission packets Retransmission stream: the stream of retransmission packets
associated to with an original stream. associated with an original stream.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Session-multiplexing: scheme by which the original stream and the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this associated retransmission stream are sent into two different RTP
document are to be interpreted as described in RFC-2119 [4]. sessions.
3. Applicability statement Rey/Leon/Miyazaki/Varsa/Hakenberg 3
SSRC-multiplexing: scheme by which the original stream and the
retransmission stream are sent in the same RTP session with
different SSRC values.
There are two proposals for RTP retransmissions (this proposal The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
draft-ietf-avt-rtp-retransmission-01.txt and draft-ietf-avt-rtp- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
selret-05.txt). Both proposals may be optimum under a different set document are to be interpreted as described in RFC 2119 [2].
of constraints.
This draft enables the receiver to perform reliable loss detection 3. Requirements and design rationale for a retransmission scheme
of user data, i.e. the receiver can differentiate between lost
packets sent for first time and lost retransmissions.
Reliable user data loss detection is required for example in RTP
conversational text (RFC 2793) in order to indicate missing text to
the user. For some applications, reliable loss detection of user
data may not be strictly required but may enhance a receiver
performance.
Leon, Varsa - Expires December 2002 3 The retransmission scheme is designed to fulfil the following set of
RTP retransmission framework June 2002 requirements:
This retransmission algorithm allows receivers to trade-off the 1. It must not break general RTP and RTCP mechanisms
playout delay versus the number of retransmissions for a given 2. It must be suitable for unicast and small multicast groups.
packet. This delay does not need to be signalled to the sender and 3. It must work with mixers and translators.
can be changed dynamically during the session in order to adapt to 4. It must work with all known payload types.
varying network conditions. Receivers should choose whether to 5. It must not prevent the use multiple payload types in a session.
request a missing packet based on an estimation of its timestamp 6. In order to support the largest variety of
which is usually obtained from the observed correlation between the payload formats the RTP receiver must be able to indicate how
RTP sequence number and timestamp. Implementers should carefully many and which RTP packets were lost. This requirement is
design their decision retransmission request algorithm in order to referred to as sequence number preservation. Without such a
limit the risk of unnecessary retransmission. requirement, it would be impossible to use retransmission with
payload formats, such as conversational text [10] or most
audio/video streaming applications, that use the RTP sequence
number to detect lost packets.
This retransmission scheme requires a separate RTP session to send When designing a solution for RTP retransmission, several approaches
retransmitted packets. As a consequence, two additional ports are may be considered for the multiplexing of the original RTP packets
needed: one port for the RTP retransmission stream and one port for and the retransmitted RTP packets.
the associated RTCP. While this is generally not a problem, the
implementers should assess the implications in the targeted
environment.
This scheme may be used in a multicast RTP session in order to One approach may be to retransmit the RTP packet with its original
perform unicast retransmission to each participant. sequence number and send original and retransmission packets in the
same 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.
If a separate session is used, mixers, translators and packet caches Another approach may be to multiplex original RTP packets and
may be able to separate retransmission packets from original packets retransmission packets in the same stream using the payload type
at an RTP session level based only on the port being used and field. With such an approach the original stream and the
process them differently if necessary. retransmission stream 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 (i.e. with which sequence number) were lost.
4. Retransmission framework basic principles In other words, this feature 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
Retransmission packets MUST NOT share the RTP Sequence Number (SN) Rey/Leon/Miyazaki/Varsa/Hakenberg 4
space with the original stream. The retransmission stream SHOULD use translators would also be more difficult if they do not understand
a different RTP session (as defined in RTP [5]) from that of the this new payload type in a sender RTP stream.
original stream. Since a separate session is used, the original and For these reasons, a solution based on payload type multiplexing of
retransmission streams are sent to different multicast group/unicast original packets and retransmission packets in the same RTP stream
addresses and/or port numbers. is excluded.
There are several reasons why the SN space must not be shared: 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 SSRCs, i.e. SSRC-multi-
plexing. Since original and retransmission packets carry media of
the same type, the objections in Section 5.2 of RTP, RFC WWWW [3] to
RTP multiplexing do not apply.
Since retransmission packets do not share the SN space with the Using two separate streams satisfies all the requirements listed in
original packets, the receiver is able to distinguish between the this section. Mixers and translators may process the original stream
loss of original packets and retransmission packets. Otherwise, and simply discard the retransmission stream if they are unable to
reliable loss detection of user data would not be possible. Reliable utilise it.
data loss detection of user data is mandated for example in RTP
conversational text [6].
RTP Timestamp (TS) estimation of missing original packets is 3.1 Multiplexing scheme choice
necessary at the receiver in order to decide whether a
retransmission is useful or not. A retransmission is useful if the
retransmission packet sent as a response to the retransmission
request may still be used when it arrives at the receiver. The
missing original packet timestamp can be estimated from timestamp of
Leon, Varsa - Expires December 2002 4 Session-multiplexing and SSRC-multiplexing have different pros and
RTP retransmission framework June 2002 cons:
packets preceding and/or following the sequence number gap caused by Session-multiplexing is based on sending the retransmission stream
the missing packet in the original 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
sessions for retransmission allows a receiver to choose whether to
subscribe or not to the RTP session carrying the retransmission
stream. It is also possible for the original session to be single-
source multicast and have separate unicast sessions to convey
retransmissions to each of the receivers, which will then receive
only the retransmission packets they requested.
The fact that RTP streams for original and retransmission packets do The use of separate sessions also allows differential treatment by
not share the same SN space guarantees that the RTP timestamp the network and may simplify processing in mixers, translators and
estimation method is reliable. Reliability would be sacrificed if packet caches.
original and retransmission packets were sent in the same RTP stream
as the timestamp estimate for a lost retransmission packet would
then be incorrect. This is because the retransmission packet usually
has a smaller "out-of-order" timestamp than the timestamp of the
consecutive original packets.
When the retransmission stream is sent to a multicast RTP session, With SSRC-multiplexing, a single session is needed for the original
receivers may choose whether to subscribe or not to the RTP session and the retransmission stream. This allows streaming servers and
carrying the retransmission stream. Therefore, a multicast streaming middleware which are involved in a high number of concurrent
application can use retransmission and still be backwards compatible sessions to minimise their port usage.
as receivers which do not implement the retransmission payload
format only join the RTP session carrying the original stream. A
scenario where the original session is multicast and separate
unicast sessions carry the retransmission stream to each
participant, is also possible. In this scenario, a receiver receives
only the retransmission packets it has itself requested and not the
retransmission packets that are requested by other receivers.
Mixers, translators and packet caches may be able to separate This retransmission payload format allows for both session-
retransmission packets from original packets at an RTP session level multiplexing and SSRC-multiplexing. From an implementation point of
and process them differently if necessary. view there is little difference between the two approaches.
Hence, in order to maximise interoperability, both multiplexing
approaches SHOULD be supported.
As a consequence of having separate RTP sessions for original and Rey/Leon/Miyazaki/Varsa/Hakenberg 5
retransmission streams, there are also separate RTCP streams and
statistics for these two sessions. There is thus no corruption of
the original stream RTCP statistics. The RTP sender is able to know
the packet loss and jitter of the original stream. It can thus
estimate what the quality of the received signal would be without
the use of retransmission.
5. Retransmission payload format 4. Retransmission payload format
The payload format of a retransmission packet is shown below. The format of a retransmission packet is shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| OPT | OSN | | | OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload | | Original RTP Packet Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leon, Varsa - Expires December 2002 5 The RTP header usage is as follows:
RTP retransmission framework June 2002
RTP header usage: If the original and the retransmission streams are sent in separate
The same SSRC value SHOULD be used for the original stream and the RTP sessions, the same SSRC value MUST be used for the original
retransmission stream. In the RTP header, SN has the standard stream and the retransmission stream.
In case of an SSRC collision, an RTCP BYE packet MUST be sent for
the original RTP session. After a new SSRC identifier is obtained,
the SSRC of the retransmission session MUST be set to this value.
If the original stream and the retransmission stream are sent in the
same RTP session, two different SSRC values MUST be used for the
original stream and the retransmission stream as required by RTP.
For either multiplexing scheme, the sequence number has the standard
definition, i.e. it MUST be one higher than the sequence number of definition, i.e. it MUST be one higher than the sequence number of
the preceding retransmission packet. The payload type is dynamic and the preceding packet sent in the retransmission stream.
indicates the use of the retransmission payload format. All other
fields of the RTP header have the same value as in the original RTP
packet.
The retransmission packet payload carries an E bit, an OPT field (7 The retransmission packet timestamp is set to the original
bits) and an OSN field (2 bytes) followed by the original RTP packet timestamp, i.e. to the timestamp of the original packet. As a
payload. The E bit is an extension bit for future-proofing. It MUST consequence, the initial RTP timestamp for the first packet of the
be set to zero. The OPT field is the payload type of the original retransmission stream is not random but equal to the original
packet payload that is being retransmitted. The OSN field is the timestamp of the first packet requested for retransmission. See the
sequence number of the original packet that originally carried the security considerations section in this document for security
same payload. implications.
6. Use with the Extended RTP profile for RTCP-based feedback 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.
6.1 Sending rules for RTCP-based feedback The payload type is dynamic. Each payload type of the original
stream MUST map to a different payload type value in the
retransmission stream. Therefore, when multiple payload types are
used in the original stream, multiple dynamic payload types will be
mapped to this payload format. See Section 8 for the specification
of how the mapping between original and retransmission payload types
is done.
When the Extended RTP profile for RTCP-based feedback [4] is used, Rey/Leon/Miyazaki/Varsa/Hakenberg 6
it is RECOMMENDED that receivers send retransmission requests As the retransmission packet timestamp carries the original media
according to the rules in this section. The rules described timestamp, the timestamp clockrate used by the retransmission
hereafter aim at limiting the maximum delay before a retransmission payload type is the same as the one used by the original payload
request can be sent and are compliant to the more general rules type. It is thus possible to retransmit RTP packets whose payload
described in the profile itself. types have different timestamp clockrates in the same retransmission
stream if the original payload types have different clock rates, but
this is usually not the case.
The NACK message format defined in the profile should be used. Early If the original RTP header carried any profile-specific payload
RTCP packets should not be used and the NACK message should always header, the retransmission packet MUST include this payload header.
be appended to a regularly scheduled compound RTCP packet that is
sent at every RTCP report interval.
Any other rules to send feedback may be used as long as they are If the original RTP header carried an RTP header extension, the
compliant with the profile. In particular, a receiver may send NACK retransmission packet SHOULD carry the same header extension.
messages in early RTCP packets. However, in that case the time when
the next RTCP packet following this early RTCP packet can be sent
could be too late to report a loss occurring right after the early
RTCP packet was sent. Sending RTCP packets at regular intervals
guarantees that the delay between detecting an original packet loss
and being able to send a NACK message for that packet is no longer
than the RTCP interval.
6.2 Receiver algorithm for generating retransmission requests The retransmission payload carries a payload header followed by the
original RTP packet payload. The length of payload header is 2
octets. The payload header contains only one field, OSN, which MUST
be set to the sequence number of the associated original RTP packet.
This section gives some general guidelines on how a receiver should If the original RTP packet contained RTP padding, that padding must
decide whether or not to request a packet retransmission. An actual be removed before constructing the retransmission packet. If padding
receiver implementation should take into account such factors as the of the retransmission packet is needed, padding is performed as with
network environment and the media type. any RTP packets and the padding bit is set.
Leon, Varsa - Expires December 2002 6 All other fields of the RTP header MUST have the same value as in
RTP retransmission framework June 2002 the associated original RTP packet
A receiver should compute an estimate of the retransmission delay to 5. Association of a retransmission stream with its original stream
receive a retransmission packet after a NACK message has been sent.
This estimate may be obtained from past observations, RTCP report
round-trip time if available or any other means.
The minimum receiver buffering delay (i.e. the time between a packet 5.1 Retransmission session sharing
is received and its payload is used at the receiver) is the RTCP
reporting interval added to the retransmission delay estimate. This
delay guarantees that a retransmission packet sent as a response to
a retransmission request can be received before its payload is used.
It can be seen that the needed receiver buffering delay is dependent In the case of session-multiplexing, a retransmission session MUST
on the amount of RTCP traffic allowed in the session. It is map to exactly one original session, i.e. the same retransmission
illustrated in Section 8 that moderate RTCP feedback traffic is session cannot be used for different original sessions.
enough to perform retransmission with reasonable receiver buffering
delay.
A receiver should maintain a list of missing original packet If retransmission session sharing were allowed, a receiver joining
sequence numbers. A receiver needs also to store for each missing the retransmission session would also receive the retransmissions
original packet an estimated RTP timestamp as described in Section belonging to all other original sessions which the receiver may have
4. At the next scheduled RTCP packet sending time, the receiver not joined. There might also be SSRC identifier conflicts between
estimates which of the missing packets should be requested in the the different original sessions.
NACK message (see usage of the PID and BLP fields of the NACK
message format in [4]) of the RTCP compound packet. A missing packet
should be requested if it is estimated the associated retransmission
packet could still be used at the time it arrives at the receiver.
The receiver should remove from its list of missing packets, the
packets which were deemed too old to be requested.
If the retransmission stream is sent to a multicast session, the 5.2 CNAME use
receiver should listen to NACK messages from other receivers. If a
NACK message for the sequence number of a missing packet has been
sent by another receiver, the receiver should ignore that sequence
number in its list of missing packets and refrain from sending a
retransmission request for that sequence number.
The same retransmission request may be resent in the original RTP A sender MUST use the same CNAME for an original stream and its
session if the requested packet was not received after an estimated associated retransmission stream.
retransmission reception time. This increases the robustness to the
loss of a NACK message or of a retransmission packet. The number of
retransmission requests that may be sent for a given missing
original packet sequence number depends on the receiver buffering
delay.
The receiver should upon reception of a retransmission packet remove 5.3 Association at the receiver
the corresponding original packet sequence number(OSN in the
retransmission payload format) from the list of missing sequence
numbers.
6.3 RTCP sending rules in the retransmission RTP session 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.
Leon, Varsa - Expires December 2002 7 Rey/Leon/Miyazaki/Varsa/Hakenberg 7
RTP retransmission framework June 2002 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 do this coupling as several
media streams may have the same payload type value. The two sessions
are themselves associated out-of-band. See the SDP section to see
how the grouping of the two sessions is done with SDP.
Since the original stream and the retransmission stream are carried If SSRC multiplexing is used, the receiver should first of all look
in separate RTP sessions, the retransmission stream has its own RTCP for two streams that have the same CNAME in the session. In some
stream as well. The amount of RTCP sent for the retransmission cases, the CNAME may not be enough to determine the association as
stream is computed as a fraction of the retransmission RTP session multiple original streams in the same session may share the same
bandwidth. Since the retransmission traffic is limited, the overhead CNAME. For example, there can be in the same video session multiple
caused by the additional RTCP packets in the retransmission RTP video streams mapping to different SSRCs and still use the same
session is moderate. For example, assuming a 64 kbps original RTP CNAME and possibly the same PT values. Each (or some of) these
session and on average 3% packet loss and all lost original packets streams may have an associated retransmission stream.
retransmitted once, the bandwidth of the retransmission RTP session
would be about 2 kbps. In this case the recommended RTCP traffic for
the retransmission RTP session would be 0.1 kbps.
Early RTCP packets and RTCP feedback messages SHOULD NOT be used in In order to find out the association between original and
the retransmission RTP session. 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 which had
been sent earlier. Upon reception of a retransmission whose original
sequence number had 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. In order to
avoid ambiguity, the receiver MUST NOT have two outstanding requests
for the same packet sequence number in two different original
streams before the association is resolved. Note that since the
initial packet timestamps are random, the probability of having two
outstanding requests for the same packet sequence number would be
very small.
If the receiver discovers that two senders are using the same SSRC
or receives an RTCP BYE packet, it MUST stop requesting
retransmissions for that SSRC. Upon reception of original RTP
packets with a new SSRC, the receiver MUST perform the SSRC
association again as described in this section.
6. Use with the extended RTP profile for RTCP-based feedback
This section gives general hints for the usage of this payload
format with the extended RTP profile for RTCP-based feedback [1],
denoted AVPF.
Rey/Leon/Miyazaki/Varsa/Hakenberg 8
6.1 RTCP Receiver reports
If the original RTP stream and the retransmission stream are sent to
separate RTP sessions, the receiver will then send report blocks for
the original stream and the retransmission streams in separate RTCP
receiver reports (RR) packets belonging to separate RTP sessions.
RTCP packets reporting on the original stream are sent in the
original RTP session while RTCP packets reporting on the
retransmission stream are sent in the retransmission session. The
RTCP bandwidth for these two sessions may be chosen independently
(for example through RTCP bandwidth modifiers RFC ZZZZ [4]).
If the original RTP stream and the retransmission stream are sent in
the same session (SSRC multiplexing), the receiver sends report
blocks for the original and the retransmission streams in the same
RTCP RR packet.
6.2 Retransmission requests
The NACK message format defined in the AVPF profile SHOULD be used
by receivers to send retransmission requests.
Whether a receiver chooses to request a packet or not is an
implementation issue. An actual receiver implementation should take
into account such factors as the tolerable application delay, the
network environment and the media type.
The receiver should generally assess whether the retransmitted
packet would still be useful at the time it is received. The
timestamp of the missing packet can be estimated from the timestamps
of packets preceding and/or following the sequence number gap caused
by the missing packet in the original stream. In most cases, some
form of linear estimate of the timestamp is good enough.
Furthermore, a receiver should compute an estimate of RTT to the
sender. This can be done, for example, by measuring the
retransmission delay to receive a retransmission packet after a NACK
message has been sent for that packet. This estimate may also be
obtained from past observations, RTCP report round-trip time if
available or any other means.
To increase the robustness to the loss of a NACK message or of a
retransmission packet, a receiver may send a new NACK message. This
is referred to as multiple retransmissions.
NACK packets MUST be sent only for the original RTP stream. If a
receiver wanted to perform multiple-retransmissions by sending a
NACK in the retransmission stream, it would not be able to know the
original sequence number and a timestamp estimation of the packet it
requests.
Rey/Leon/Miyazaki/Varsa/Hakenberg 9
6.3 Timing rules
The RTCP NACK packet may be sent in a regular full compound RTCP
packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK
in an early packet allows to react more quickly to a given packet
loss. However, in that case if a new packet loss occurs right after
the early RTCP packet was sent, the receiver will then have to wait
for the next regular RTCP compound packet after the early packet.
Sending NACK packets only in regular RTCP compound decreases the
maximum delay between detecting an original packet loss and being
able to send a NACK message for that packet.
Implementers should consider the possible implications of this fact
for the application being used.
Furthermore, receivers MAY make use of the minimum interval between
regular RTCP compound packets. This can be used, for example, to
keep reception reporting down to a given minimum, while still
allowing receivers to react to periods requiring more frequent
feedback, e.g. times of higher packet loss rate. In this way,
receivers will try to keep the amount of sent RTCP packets as low as
specified by the minimum interval, but are still able to react to
events requiring timely feedback, e.g. packet losses. Note that
although RTCP packets may be suppressed because they do not contain
NACK packets, the reserved RTCP bandwidth is the same as if they
were sent. See AVPF [1] for details.
7. Congestion control 7. Congestion control
RTP retransmission poses a risk of increased network congestion. In RTP retransmission poses a risk of increasing network congestion. In
a best-effort environment, packet loss is caused by congestion. a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmission of older packets in addition to Reacting to loss by retransmission of older data without decreasing
the current data would thus further increase congestion. the rate of the original stream would thus further increase
Implementations SHOULD follow the recommendations below in order to congestion. Implementations SHOULD follow the recommendations below
use retransmission. in order to use retransmission.
The RTP profile under which the retransmission scheme is used The RTP profile under which the retransmission scheme is used
defines an appropriate congestion control mechanism in different defines an appropriate congestion control mechanism in different
environments. Following the rules under the profile, an RTP environments. Following the rules under the profile, an RTP
application can determine its acceptable bitrate and packet rate in application can determine its acceptable bitrate and packet rate in
order to be fair to other applications such as TCP flows and other order to be fair to other TCP or RTP flows.
RTP flows.
If an RTP application uses retransmission, the acceptable packet If an RTP application uses retransmission, the acceptable packet
rate and bitrate SHOULD include both the original and retransmitted rate and bitrate includes both the original and retransmitted data.
data. This guarantees that an application using retransmission This guarantees that an application using retransmission achieves
should be fair to any other RTP or TCP flows. Such a rule would the same fairness as one that doesn't. Such a rule would translate
translate in practice into the following actions: in practice into the following actions:
If enhanced service is used, it should be made sure that the total If enhanced service is used, it should be made sure that the total
bitrate and packet rate do not exceed that of the requested service. bitrate and packet rate do not exceed that of the requested service.
It should be further monitored that the requested services are It should be further monitored that the requested services are
actually delivered. In a best-effort environment, the sender SHOULD actually delivered. In a best-effort environment, the sender SHOULD
Rey/Leon/Miyazaki/Varsa/Hakenberg 10
NOT send retransmission packets without reducing the packet rate and NOT send retransmission packets without reducing the packet rate and
bitrate of the original stream (for example by encoding the data at bitrate of the original stream (for example by encoding the data at
a lower rate). a lower rate).
In addition, the sender MAY retransmit only the packets that it In addition, the sender MAY selectively retransmit only the packets
deems important and ignore NACK messages for other packets in order that it deems important and ignore NACK messages for other packets
to limit the bitrate in order to limit the bitrate.
These congestion control mechanisms should keep the congestion level These congestion control mechanisms should keep the packet loss rate
under an acceptable limit. This would in turn guarantee that the within acceptable parameters. Packet loss is considered acceptable
packet loss should be moderate. Too high a packet loss would mean if a TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured on
a reasonable timescale, that is not less than the RTP flow is
achieving. If the packet loss rate exceed acceptable parameters,
this would mean that congestion is not kept under control and
retransmission should then not be used. It may further be necessary
to adapt the transmission rate (or the number of layers subscribed
for a layered multicast session), or to arrange for the receiver to
leave the session if the loss rate is unacceptably high.
Leon, Varsa - Expires December 2002 8 8. SDP usage
RTP retransmission framework June 2002
that congestion is not kept under control and retransmission should 8.1 Introduction
then not be used.
8. Example scenario of unicast streaming This section specifies how to describe the retransmission delivery
method using the Session Description Protocol (SDP), RFC 2327 [5].
As specified in this document, the retransmission stream may be
conveyed in separate RTP sessions, i.e. through session-
multiplexing, or in the same RTP session as the original stream
through SSRC-multiplexing.
Let us assume that the RTP session bandwidth is 64 kbps and the The following attributes and parameters are introduced in this
receiver buffering delay is 3 seconds. The network round trip time document: "rtx", "rtx-time" and "apt".
is 500 ms and Receiver RTCP packets (including NACK messages ) are
sent at 2-second intervals. With these time limitations, when the
receiver algorithm for generating retransmission requests described
in Section 6.2 is followed, only one request per packet loss can be
sent. Let us assume an original packet rate of 50 packets per second
(1 packet every 20 ms). At this packet rate, with the packet loss
distribution worst case scenario where every 17th original packet is
lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages
need to be appended to the RTCP compound packet that is sent every 2
seconds. The 6 NACK messages can report any packet losses in an SN
range of 6*17=102, thus the number of required NACK messages would
not increase with higher packet loss rates. The overhead required
per RTCP compound packet for the 6 NACK messages is 36 bytes which
carries 6 PID and 6 BLP fields in addition to the feedback message
headers.
The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+ The binding used for the retransmission stream to the payload type
RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The number is indicated by an rtpmap attribute. The MIME subtype name
needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP used in the binding is "rtx", as specified in Section 11.
bandwidth is well below the recommended RTCP bandwidth. The receiver
RTCP recommended bandwidth in an RTP session with 64 kbps is about
0.25*64 = 1.6 kbps.
9. SDP usage An OPTIONAL payload format-specific parameter indicates the maximum
time a server will try to retransmit a packet.
The syntax is as follows:
The binding to the payload type number is indicated by an rtpmap a=fmtp <number>: rtx-time=<rtx-time-val>
attribute. The name used in the binding is "rtx". where,
<number> indicates the dynamic payload type number assigned to
the retransmission payload format in an rtpmap attribute.
<rtx-time-val> indicates the time in milliseconds, measured
from the time a packet was first sent until the time the server
will stop trying to retransmit the packet. No rtx-time
parameter present for a retransmission stream means that the
maximum retransmission time is not defined, but MAY be
negotiated by other means.
An SDP example is shown below: Rey/Leon/Miyazaki/Varsa/Hakenberg 11
Additionally, a new SDP payload-format-specific parameter "apt" MUST
be used to map the RTX payload type to the associated original
stream payload type as seen in the SDP description examples below.
If multiple payload types are used in the original stream, then
multiple "apt" parameters MUST be included to map each original
stream payload type to a different RTX payload type. The syntax of
this parameter is as follows:
c=IN IP4 113.3.12.11 a=fmtp <number>: apt=<apt-value>
where,
<number> indicates the dynamic payload type number assigned to
the retransmission payload format.
<apt-value> indicates the original stream payload type to which
this retransmission stream payload type is associated.
Some SDP description examples are presented in the following
subsections.
8.2 Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is
used to specify retransmissions for an RTP stream, the mapping is
done as follows:
- The MIME types ("video"), ("audio") and ("text") go in the SDP
"m=" as the media name.
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be that of the
retransmission payload type. See Section 4 for details
on this.
- The AVPF profile-specific parameters "ack" and "nack" go in SDP
"a=rtcp-fb". Several SDP "a=rtcp-fb" MUST be used for several
types of feedback. See the AVPF profile [1] for details.
- The retransmission payload format-specific parameters "apt" and
"rtx-time" go in the SDP "a=fmtp" as a semicolon separated list
of parameter=value pairs.
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a
semicolon separated list of parameter=value pairs.
In the following sections some example SDP descriptions are
presented.
Note that some example SDP session descriptions utilizing AMR and
MPEG-4 encodings follow.
Rey/Leon/Miyazaki/Varsa/Hakenberg 12
8.3 SDP description with session-multiplexing
In the case of session-multiplexing the SDP description contains one
media specification "m" line per RTP session.
The SDP MUST provide the grouping of the original and associated
retransmission sessions' "m" lines, using the Flow Identification
(FID) semantics defined in RFC YYYY [6].
The following example specifies two original, AMR and MPEG-4,
streams on ports 49170 and 49174 and their corresponding
retransmission streams on ports 49172 and 49176, respectively:
v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session
"m" line, the grouping is then obvious and FID semantics MAY be
omitted in this special case only.
This is illustrated in the following example, which is an SDP
description for a single original MPEG-4 stream and its
corresponding retransmission session:
Rey/Leon/Miyazaki/Varsa/Hakenberg 13
v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
a=rtpmap:96 H263-1998/90000 a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 rtcp-fb nack a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
m=video 49172 RTP/AVPF 97 m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
8.4 SDP description with SSRC-multiplexing
The following is an example of an SDP description for an RTP video
session using SSRC-multiplexing with similar parameters as in the
single-session example above:
v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
10. IANA considerations 9. RTSP considerations
10.1 Registration of audio/rtx The Real-time Streaming Protocol (RTSP) , RFC 2326 [7] is an
application-level protocol for control over the delivery of data
with real-time properties. This section looks at the issues involved
in controlling RTP sessions that use retransmissions.
MIME type: audio Because of the nature of retransmissions, the sending of
retransmission packets should not be controlled through RTSP PLAY
and PAUSE requests from the server. Instead, retransmission packets
should be sent upon receiver requests in the original RTCP stream.
It is described hereafter how the retransmission stream should be
controlled in the SSRC-multiplexing and session-multiplexing case.
Leon, Varsa - Expires December 2002 9 9.1 RTSP control with SSRC-multiplexing
RTP retransmission framework June 2002
In the case of SSRC-multiplexing, there is a single RTSP "control"
attribute for the media session. The receiver controls the original
stream through the session RTSP control URL. As the receiver
receives the original stream it can request retransmission through
RTCP requests without additional RTSP signalling.
Rey/Leon/Miyazaki/Varsa/Hakenberg 14
The RTP-info header that is used to set RTP-specific parameters in
the PLAY response can describe only a single RTP stream in the
session. The RTP-info header returned in the PLAY response MUST be
the RTP information for the original stream.
9.2 RTSP control with session-multiplexing
In the case of Session-multiplexing, each SDP "m" line must have an
RTSP "control" attribute. Hence, when retransmission is used, both
the original session and the retransmission have their own "control"
attribute. The original session and the retransmission session are
associated through the FID semantics as specified in Section 8.
Both the original and the retransmission stream need to be setup
through their respective "control" attribute.
If the presentation supports aggregate control, the session-level
"control" attribute is used as usual to control the whole
presentation. As the receiver receives the presentation original
streams, it can request retransmission through RTCP without
additional RTSP signalling.
If the presentation does not support aggregate control, the receiver
should control each original stream as usual through its "control"
attribute. However, the receiver SHOULD NOT send PLAY or PAUSE
requests for the retransmission streams. As the receiver receives
the presentation original streams, it can request retransmission
through RTCP requests without additional RTSP signalling.
If an original stream is paused (independently of whether aggregate
or non-aggregate control is used), a receiver may still send
retransmission requests through RTCP.
10. Implementation examples
This specification mandates only the sender and receiver behaviours
that are necessary for interoperability. In addition, certain
algorithms, such as rate control or buffer management when targeted
at specific environments, may enhance the retransmission efficiency.
This section gives an overview of different implementation options
allowed within this specification.
The first example is a server-driven retransmission implementation.
With this implementation, it is possible to retransmit lost RTP
packets, detect efficiently the loss of retransmissions and perform
multiple retransmissions, if needed. Most of the necessary
processing is done at the server.
The second example shows a receiver-driven implementation. It
illustrates how a receiver may increase the retransmission
Rey/Leon/Miyazaki/Varsa/Hakenberg 15
efficiency. This implementation also increases the sender
scalability by reducing the work required of the sender.
The third example shows how retransmissions may be used in (small)
multicast groups in conjunction with layered encoding. It
illustrates that retransmissions and layered encoding may be
complementary techniques.
10.1 A sender-driven retransmission example
This section gives an implementation example of multiple
retransmissions. The sender transmits the original data in RTP
packets using the MPEG-4 video RTP payload format.
It is assumed that Generic NACK feedback messages are used, as per
[1]. An SDP description example with SSRC-multiplexing is given
below:
v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The format-specific parameter "rtx-time" would indicate that the
server will buffer the sent packets in a retransmission
buffer for 3.0 seconds, after which the packets are deleted from
the retransmission buffer and will never be sent again.
In this implementation example, the required RTP receiver processing
to handle retransmission is very limited. The receiver detects
packet loss from the gaps observed in the received sequence numbers.
It signals lost packets to the sender through RTCP NACK messages as
defined in the AVPF profile [1]. The receiver should take into
account the signalled sender retransmission buffer length in order
to dimension its own reception buffer. It should also derive from
the buffer length the maximum number of times retransmission of a
packet can be requested.
The sender should retransmit the packets selectively, i.e. it should
choose whether to retransmit a requested packet depending on the
packet importance, the observed QoS and congestion state of the
network connection to the receiver. Obviously, the sender processing
increases with the number of receivers as state information and
processing load must be allocated to each receiver.
Rey/Leon/Miyazaki/Varsa/Hakenberg 16
10.2 A receiver-driven retransmission example
The receiver may have more accurate information than the sender
about the current network QoS such as available bandwidth, packet
loss rate, delay and jitter.
In addition, other receiver-specific parameters like buffer level,
estimated importance of the lost packet and application level QoS
may be used by the receiver to make a more efficient use of RTP
retransmission through selective requests.
Furthermore, a receiver may acknowledge the received packets. This
can be done by sending ACK messages, as per [1]. Upon receiving an
ACK, the sender may delete all the acknowledged packets from its
retransmission buffer. Note that this would also require only
limited increase in the required RTCP bandwidth as long as ACK
packets are sent seldom enough. With the receiver-driven
retransmission implementation, processing load and buffer
requirements at the sender are decreased, allowing greater sender
scalability.
Note that choosing between the sender-driven implementation and the
receiver-driven implementation does not imply any changes in the SDP
description, except for the need to signal the use of ACK RTCP
packets, by means of an additional SDP "a=rtcp-fb" line, as follows:
v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 ack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
10.3 Retransmissions with Layered Transmissions
This section shows how to combine retransmissions with layered
encoding. Note that the retransmission framework is not intended as
a complete solution to reliable multicast. Refer to RFC 2887 [11],
for an overview of the problems related with reliable multicast
transmission.
Packets of different importance are sent in different RTP sessions.
The retransmission streams corresponding to the different layers can
themselves be seen as different retransmission layers. The relative
importance of the different retransmission streams should reflect
the relative importance of the different original streams.
Rey/Leon/Miyazaki/Varsa/Hakenberg 17
A retransmission stream may be sent in the same RTP session as its
corresponding original layer through SSRC multiplexing or in a
different RTP session through session multiplexing.
An SDP description example for SSRC-multiplexing is given below:
c=IN IP4 224.2.1.1/127/3
m=video 8000 RTP/AVPF 98 99
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=fmtp:99 rtx-time=3000
The server and the receiver may implement the retransmission method
as illustrated in the previous examples. In addition, they may
choose to request and retransmit a lost packet depending on the
layer it belongs to.
11. IANA considerations
11.1 Registration of audio/rtx
MIME type: audio
MIME subtype: rtx MIME subtype: rtx
Required parameters: rate Required parameters:
The RTP timestamp clockrate is equal to the RTP timestamp clockrate
of the media that is retransmitted. rate: the RTP timestamp clockrate is equal to the RTP timestamp
Optional parameters: none clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is
the payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the
time a packet was first sent until the time the server will
stop trying to retransmit the packet
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer via
RTP. RTP.
Security considerations: see Section 11 Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxx Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Rey/Leon/Miyazaki/Varsa/Hakenberg 18
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: David Leon Author/Change controller:
Jose Rey
David Leon.
IETF AVT WG
10.2 Registration of video/rtx 11.2 Registration of video/rtx
MIME type: video MIME type: video
MIME subtype: rtx MIME subtype: rtx
Required parameters: rate Required parameters:
The RTP timestamp clockrate is equal to the RTP timestamp clockrate
of the media that is retransmitted. rate: the RTP timestamp clockrate is equal to the RTP timestamp
Optional parameters: none clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is
the payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the
time a packet was first sent until the time the server will
stop trying to retransmit the packet
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer via
RTP. RTP.
Security considerations: see Section 11 Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxx Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Leon, Varsa - Expires December 2002 10 Rey/Leon/Miyazaki/Varsa/Hakenberg 19
RTP retransmission framework June 2002
Person & email address to contact for further information: Person & email address to contact for further information:
David.leon@nokia.com rey@panasonic.de
david.leon@nokia.com
avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: David Leon Author/Change controller:
Jose Rey
David Leon
IETF AVT WG
10.3 Registration of text/rtx 11.3 Registration of text/rtx
MIME type: text MIME type: text
MIME subtype: rtx MIME subtype: rtx
Required parameters: rate Required parameters:
The RTP timestamp clockrate is equal to the RTP timestamp clockrate
of the media that is retransmitted. rate: the RTP timestamp clockrate is equal to the RTP timestamp
Optional parameters: none clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is
the payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the
time a packet was first sent until the time the server will
stop trying to retransmit the packet
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer via
RTP. RTP.
Security considerations: see Section 11 Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxx Published specification: RFC XXXX
Applications which use this media type: multimedia streaming Applications which use this media type: multimedia streaming
applications applications
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
David.leon@nokia.com rey@panasonic.de
david.leon@nokia.com
avt@ietf.org
Rey/Leon/Miyazaki/Varsa/Hakenberg 20
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: David Leon Author/Change controller:
Jose Rey
David Leon
IETF AVT WG
11. Security consideration 11.4 Registration of application/rtx
Retransmission and FEC [7] have similar security conditions as far MIME type: application
as encryption and congestion control are concerned.
Applications utilizing encryption SHOULD encrypt both the original
and the retransmission stream. Old keys will likely need to be
cached so that when the keys change for the original stream, the old
key is used until it is determined that the key has changed on the
retransmission packets as well.
Congestion control considerations with the use of retransmission are
dealt with in Section 7 of this document.
Leon, Varsa - Expires December 2002 11 MIME subtype: rtx
RTP retransmission framework June 2002
Any other security considerations of the profile under which the Required parameters:
retransmission scheme is used should be applied.
Appendix A: Retransmission and SSRC multiplexing rate: the RTP timestamp clockrate is equal to the RTP timestamp
clockrate of the media that is retransmitted.
In this document, it is required that two separate RTP streams with apt: associated payload type. The value of this parameter is
their own sequence number space be used for the original stream and the payload type of the associated original stream.
the retransmission stream. This should be achieved by sending the
RTP stream and its associated retransmission stream to different
ports.
Another way the original and the retransmission stream could be Optional parameters:
multiplexed is through the use of different SSRCs if these streams
are sent to the same port.
In general, SSRC multiplexing is not feasible as in a multicast
group it would not be possible to associate an original stream and
its retransmission stream since the SSRC is a random number chosen
by the RTP sender.
However, in unicast this should not be an issue if exactly one RTP
stream and its retransmission stream are multiplexed based on their
SSRC. Since the receiver knows the payload types used by the
original stream and the retransmission stream, it would be able to
derive which SSRC maps to the original data and which SSRC maps to
retransmissions.
SSRC multiplexing should generally be avoided as discussed in rtx-time: indicates the time in milliseconds, measured from the
Section 5.2 of RTP [5]. One of the advantage of multiplexing at the time a packet was first sent until the time the server will
transport layer (i.e. based on the IP address or port number) is the stop trying to retransmit the packet
use of different network paths or resources for different streams.
However, in the case of unicast retransmission, it is the same media
sent in both the original and the retransmission.
It also has to be noted that the SSRC-multiplexing approach is Encoding considerations: this type is only defined for transfer via
allowed in FEC [7]. Section 3 of FEC states "This document does not RTP.
prescribe the definition of "separate streams", but leaves this to
applications and higher level protocols to define. For multicast,
the separate stream may be implemented by separate multicast groups,
different ports in the same group, or by a different SSRC within the
same group/port. For unicast, different ports or different SSRC may
be used. Each of these approaches has drawbacks and benefits which
depend on the application".
This retransmission draft recommends the following rules: Security considerations: see Section 12 of RFC XXXX
Separate addresses and/or ports must be used in the multicast case
and should be used in the unicast case to multiplex the original
stream and the retransmission stream. In the unicast case, exactly
one RTP stream and its associated retransmission stream may be sent
to the same port and multiplexed based on their SSRCs
The motivation not to prevent SSRC multiplexing is to minimise the Interoperability considerations: none
number of ports usage when it may be a performance issue for high-
scale RTP servers and/or middle-ware proxies while allowing the
Leon, Varsa - Expires December 2002 12 Published specification: RFC XXXX
RTP retransmission framework June 2002
original and the retransmitted data to be sent into separate RTP Applications which use this media type: multimedia streaming
streams with their own sequence number spaces. applications
Appendix B: FEC for retransmission Additional information: none
It is possible to retransmit the payload of an original packet by Person & email address to contact for further information:
sending a FEC packet as defined in [7] instead of using the rey@panasonic.de
retransmission payload format. The base sequence number of the FEC david.leon@nokia.com
header is the sequence number of the original packet that carried avt@ietf.org
the same payload and the mask is set to zero. There are some
advantages in using the FEC payload format in particular in
multicast sessions as a single FEC packet may repair the loss of
different packets at different receivers. In a multicast session,
FEC may be combined with retransmission requests as described in [8]
in order to achieve scalable reliable multicast transmission.
There are however the following motivations to define the Intended usage: COMMON
retransmission payload format in order to perform retransmission
instead of using the FEC payload format:
*The retransmission payload format has reduced overhead (3 bytes Author/Change controller:
instead of 12 bytes). Jose Rey
David Leon
IETF AVT WG
*In the retransmission payload format, the RTP header TS field is Rey/Leon/Miyazaki/Varsa/Hakenberg 21
the actual timestamp of the (retransmitted) media carried in the
packets. This is in line with RTP [5] specifications. This is useful
in particular for RTP mixers/translators which process the TS field.
On the other hand, the FEC payload format uses the RTP transmission
time (as the FEC packet should be computed over data with different
timestamp).
*Assuming that no retransmission payload format were defined, the 12. Security considerations
FEC payload format would then be used in different ways: sending
computed FEC packets proactively for correction of lost packets at
the receiver without requiring NACK messages (referred hereafter as
proactive FEC) or sending retransmitted data upon receipt of a NACK
message from the receiver.
Although they could use the same payload format, these two repair
mechanisms are different. For a given amount of overhead, they offer
a different residual packet loss vs. latency trade-off.
Retransmission provides higher packet loss recovery at the expense
of higher delay. If a sender uses proactive FEC and none of the
packets protected by a given FEC packet is lost, there is then no
use of the FEC packet at the receiver. On the other hand, data which
are retransmitted are known to have been lost.
Therefore, a receiver may wish to use only retransmission and not
receive any proactive FEC from the sender in order to trade-off
itself the buffering delay, the data-loss rate and the overhead.
There is thus a motivation to let the receiver decide at session
setup whether the sender may send proactive FEC or retransmission
only.
Leon, Varsa - Expires December 2002 13 Applications utilising encryption SHOULD encrypt both the original
RTP retransmission framework June 2002 and the retransmission stream. Old keys will likely need to be
cached so that when the keys change for the original stream, the old
key is used until it is determined that the key has changed on the
retransmission packets as well.
If the same payload format were used for these different purposes, The use of the same key for the retransmitted stream and the
the receiver would not know at session establishment which repair original stream may lead to security problems, e.g. two-time pads.
mechanism is used by the sender (without defining out-of-band This sharing has to be evaluated towards the chosen security
signalling). The sender would decide by itself whether FEC or protocol and security algorithms, e.g. the Secure Real-Time
retransmission (or both) is used and the receiver would not know Transport Protocol (SRTP) RFC UUUU [8] establishes requirements for
until receiving the FEC packets whether proactive FEC or avoiding the two-time pad.
retransmission is used.
On the other hand, having different payload formats or at least
different out of band signalling for these two repair mechanisms
(e.g. through defining the binding name 'RTX' SDP rtpmap attribute)
would allow the receiver to choose which mechanism to use (among
those supported by the sender). The receiver would then have an
explicit way to tell the sender not to send proactive FEC.
Furthermore, if the receiver did not know at session establishment
whether it will receive FEC packets or retransmission, it would have
to be prepared to receive FEC and thus be able to perform FEC packet
recovery operations. Implementers would thus not be able choose to
implement only a FEC or retransmission scheme.
References RTP recommends that the initial RTP timestamp SHOULD be random to
secure the stream against known plain text attacks. This payload
format does not follow this recommendation as the initial timestamp
will be the media timestamp of the first retransmitted packet.
1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", However, since the initial timestamp of the original stream is
RFC 2354, June 1998. itself random, if the original stream is encrypted, the first
retransmitted packet timestamp would also be random to an attacker.
Therefore, security would not be compromised.
2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and Congestion control considerations with the use of retransmission are
VideoConferences with Minimal Control," Internet Draft draft- dealt with in Section 7 of this document.
ietf-avt-profile-new-12.txt, November 2001.
3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, Any other security considerations of the profile under which the
R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based retransmission scheme is used should be applied.
feedback", November 2001
4 RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate 13. Acknowledgements
Requirement Levels", BCP 14, RFC 2119, March 1997
5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: We would like to express our gratitude to Carsten Burmeister for his
A Transport Protocol for Real-Time Applications", Internet Draft participation in the development of this document. Our thanks also
draft-ietf-avt-rtp-new-11.txt, November 2001. go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund,
Go Hori and Rahul Agarwal for their helpful comments.
6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 Rey/Leon/Miyazaki/Varsa/Hakenberg 22
7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 14. References
Generic Forward Error Correction", RFC 2733, December 1999.
8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 14.1 Normative References
recovery for reliable multicast transmission", ACM SIGCOMM'97,
Cannes, France, September 1997
Leon, Varsa - Expires December 2002 14 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP
RTP retransmission framework June 2002 profile for RTCP-based feedback", RFC VVVV, September 2002.
2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC WWWW, May
2002.
4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC ZZZZ,
May 2002.
5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
2327, April 1998.
6 G. Camarillo,J. Holler, G. AP. Eriksson, "Grouping of media lines
in SDP", RFC YYYY, February 2002.
7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol
(RTSP)", RFC 2326, April 1998.
8 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
RFC UUUU, June 2002.
14.2 Non-normative References
9 C. Perkins, O. Hodson, "Options for Repair of Streaming Media",
RFC 2354, June 1998.
10 J. Hellstrom, "RTP for conversational text", RFC 2793, May 2000
11 M. Handley, et al., "The Reliable Multicast Design Space for Bulk
Data Transfer", RFC 2887, August 2000.
Rey/Leon/Miyazaki/Varsa/Hakenberg 23
Author's Addresses Author's Addresses
David Leon Jose Rey rey@panasonic.de
Panasonic European Laboratories GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
David Leon david.leon@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1860 6000 Connection Drive
Irving, TX. USA Email: david.leon@nokia.com Irving, TX. USA
Phone: 1-972-374-1860
Viktor Varsa Akihiro Miyazaki akihiro@isl.mei.co.jp
Core Software Development Center
Corporate Software Development Division
Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
Phone: +81-6-6900-9192
Fax: +81-6-6900-9193
Viktor Varsa viktor.varsa@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1861 6000 Connection Drive
Irving, TX. USA Email: viktor.varsa@nokia.com Irving, TX. USA
Phone: 1-972-374-1861
Leon, Varsa - Expires December 2002 15 Rolf Hakenberg hakenberg@panasonic.de
Panasonic European Laboratories GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
Rey/Leon/Miyazaki/Varsa/Hakenberg 24
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/