draft-ietf-avt-rtp-retransmission-03.txt   draft-ietf-avt-rtp-retransmission-04.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission- Jose Rey/Matsushita draft-ietf-avt-rtp-retransmission- Jose Rey/Matsushita
03.txt David Leon/Nokia 04.txt David Leon/Nokia
Akihiro Miyazaki/Matsushita Akihiro Miyazaki/Matsushita
Viktor Varsa/Nokia Viktor Varsa/Nokia
Rolf Hakenberg/Matsushita Rolf Hakenberg/Matsushita
Expires: April 2003 November 2002 Expires: May 2003 December 2002
RTP Retransmission Payload Format 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.
[Note to RFC Editor: This paragraph is to be deleted when this [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 draft is published as an RFC. References in this draft to RFC XXXX
should be replaced with the RFC number assigned to this document. should be replaced with the RFC number assigned to this document.
References in this draft to RFC YYYY should be replaced with the RFC References in this draft to RFC YYYY should be replaced with the RFC
number assigned the draft-ietf-mmusic-fid when published as RFC. number assigned the draft-ietf-mmusic-fid when published as RFC.
References in this draft to RFC ZZZZ should be replaced with the RFC References in this draft to RFC ZZZZ should be replaced with the RFC
number assigned the draft-ietf-avt-rtcp-bw when published as RFC. number assigned the draft-ietf-avt-rtcp-bw when published as RFC.
References in this draft to RFC UUUU should be replaced with the References in this draft to RFC UUUU should be replaced with the
RFC number assigned the draft-ietf-avt-srtp when published as RFC. RFC number assigned the draft-ietf-avt-srtp when published as RFC.
References in this draft to RFC VVVV should be replaced with the RFC References in this draft to RFC VVVV should be replaced with the RFC
number assigned the draft-ietf-avt-rtcp-feedback when published as number assigned the draft-ietf-avt-rtcp-feedback when published as
RFC. References in this draft to RFC WWWW should be replaced with 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- the RFC number of the revision of RFC 1889 being drafted as draft-
ietf-avt-rtp-new.] ietf-avt-rtp-new. Main changes since draft-ietf-avt-rtp-
retransmission-02.txt: this document is the result of the merging of
IETF draft - Expires April 2003 1 draft-ietf-avt-selret-05.txt and draft-ietf-avt-rtp-retransmission-
02.txt. Main changes since draft-ietf-avt-rtp-retransmission-03.txt:
RTSP section new drafted.]
IETF draft - Expires May 2003 1
Abstract Abstract
RTP retransmission is an effective packet loss recovery technique RTP retransmission is an effective packet loss recovery technique
for real-time applications with relaxed delay bounds. for real-time applications with relaxed delay bounds. This document
This document describes an RTP payload format for performing describes an RTP payload format for performing retransmissions.
retransmissions. Retransmitted RTP packets are sent in a separate Retransmitted RTP packets are sent in a separate stream from the
stream from the original RTP stream. It is assumed that feedback original RTP stream. It is assumed that feedback from receivers to
from receivers to senders it is available. In particular, senders is available. In particular, it is assumed that RTCP
availability of enhanced RTCP feedback as defined in the extended feedback as defined in the extended RTP profile for RTCP-based
RTP profile for RTCP-based feedback [1] ( denoted AVPF ) is assumed feedback [1] ( denoted AVPF ), is available in this memo.
in this memo.
Main changes
This document is the result of the merging of draft-ietf-avt-selret-
05.txt and draft-ietf-avt-rtp-retransmission-02.txt.
Table of Contents Table of Contents
Abstract...........................................................2 1. Introduction....................................................3
Main changes.......................................................2
1. Introduction....................................................2
2. Terminology.....................................................3 2. Terminology.....................................................3
3. Requirements and design rationale for a retransmission scheme...4 3. Requirements and design rationale for a retransmission scheme...4
4. Retransmission payload format...................................5 4. Retransmission payload format...................................6
5. Association of a retransmission stream with its original stream.7 5. Association of a retransmission stream with its original stream.7
6. Use with the extended RTP profile for RTCP-based feedback.......8 6. Use with the extended RTP profile for RTCP-based feedback.......8
7. Congestion control.............................................10 7. Congestion control.............................................10
8. SDP usage......................................................11 8. SDP usage......................................................11
9. RTSP considerations............................................14 9. RTSP considerations............................................14
10. Implementation examples.......................................15 10. Implementation examples.......................................15
11. IANA considerations...........................................18 11. IANA considerations...........................................18
12. Security considerations.......................................22 12. Security considerations.......................................22
13. Acknowledgements..............................................22 13. Acknowledgements..............................................22
14. References....................................................23 14. References....................................................22
Author's Addresses................................................24 Author's Addresses................................................23
Rey/Leon/Miyazaki/Varsa/Hakenberg 2
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 media. Several techniques, such degrade the quality of the received media. Several techniques, such
as forward error correction (FEC), retransmissions or interleaving as forward error correction (FEC), retransmissions or interleaving
may be considered to increase packet loss resiliency. RFC 2354 [9] may be considered to increase packet loss resiliency. RFC 2354 [9]
discusses the different options. discusses the different options.
When choosing a repair technique for a particular application, the When choosing a repair technique for a particular application, the
tolerable latency of the application has to be taken into account. tolerable latency of the application has to be taken into account.
Rey/Leon/Miyazaki/Varsa/Hakenberg 2
In the case of multimedia conferencing, the end-to-end delay has to In the case of multimedia conferencing, the end-to-end delay has to
be at most a few hundred milliseconds in order to guarantee be at most a few hundred milliseconds in order to guarantee
interactivity, which usually excludes the use of retransmission. interactivity, which usually excludes the use of retransmission.
However, in the case of multimedia streaming, the user can tolerate However, 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- an initial latency as part of the session set-up and thus an end-to-
end delay of several seconds may be acceptable. Retransmission may end delay of several seconds may be acceptable. Retransmission may
thus be considered for such applications. thus be considered for such applications.
This document specifies a retransmission method for RTP for unicast This document specifies a retransmission method for RTP applicable
and (small) multicast groups: it defines a payload format for to unicast and (small) multicast groups: it defines a payload format
retransmitted RTP packets and provides protocol rules for the sender for retransmitted RTP packets and provides protocol rules for the
and the receiver involved in retransmissions. sender and the receiver involved in retransmissions.
Furthermore, this retransmission payload format was designed for use Furthermore, this retransmission payload format was designed for use
with the extended RTP profile for RTCP-based feedback, AVPF [1]. It with the extended RTP profile for RTCP-based feedback, AVPF [1]. It
may also be used together with other RTP profiles defined in the may also be used with other RTP profiles defined in the future.
future.
The AVPF profile allows for frequent feedback, early feedback and The AVPF profile allows for more frequent feedback and for early
defines a small number of general-purpose feedback messages, e.g. feedback. It defines a small number of general-purpose feedback
ACKs and NACKs, as well as codec and application-specific feedback messages, e.g. ACKs and NACKs, as well as codec and application-
messages. See [1] for details. 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 RTP 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 and possible header extension of an already includes the payload of an already sent original packet. Such a
sent original packet. Such a retransmission packet is said to be retransmission packet is said to be associated with the original RTP
associated with the original RTP packet. 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 should send a retransmission packet for request that the RTP sender should send a retransmission packet for
a given original packet. Usually, an RTCP NACK message as specified a given original packet. Usually, an RTCP NACK message as specified
in [1] is used as retransmission request for lost packets. in [1] is used as retransmission request for lost packets.
Rey/Leon/Miyazaki/Varsa/Hakenberg 3
Retransmission stream: the stream of retransmission packets Retransmission stream: the stream of retransmission packets
associated with an original stream. associated with an original stream.
Session-multiplexing: scheme by which the original stream and the Session-multiplexing: scheme by which the original stream and the
associated retransmission stream are sent into two different RTP associated retransmission stream are sent into two different RTP
sessions. sessions.
Rey/Leon/Miyazaki/Varsa/Hakenberg 3
SSRC-multiplexing: scheme by which the original stream and the SSRC-multiplexing: scheme by which the original stream and the
retransmission stream are sent in the same RTP session with retransmission stream are sent in the same RTP session with
different SSRC values. different SSRC values.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
3. Requirements and design rationale for a retransmission scheme 3. Requirements and design rationale for a retransmission scheme
The retransmission scheme is designed to fulfil the following set of The retransmission scheme is designed to fulfil the following set of
requirements: requirements:
1. It must not break general RTP and RTCP mechanisms 1. It must not break general RTP and RTCP mechanisms
2. It must be suitable for unicast and small multicast groups. 2. It must be suitable for unicast and small multicast groups.
3. It must work with mixers and translators. 3. It must work with mixers and translators.
4. It must work with all known payload types. 4. It must work with all known payload types.
5. It must not prevent the use multiple payload types in a session. 5. It must not prevent the use multiple payload types in a session.
6. In order to support the largest variety of 6. In order to support the largest variety of payload formats the
payload formats the RTP receiver must be able to indicate how RTP receiver must be able to indicate how many and which RTP
many and which RTP packets were lost. This requirement is packets were lost. This requirement is referred to as sequence
referred to as sequence number preservation. Without such a number preservation. Without such a requirement, it would be
requirement, it would be impossible to use retransmission with impossible to use retransmission with payload formats, such as
payload formats, such as conversational text [10] or most conversational text [10] or most audio/video streaming
audio/video streaming applications, that use the RTP sequence applications, that use the RTP sequence number to detect lost
number to detect lost packets. packets.
When designing a solution for RTP retransmission, several approaches When designing a solution for RTP retransmission, several approaches
may be considered for the multiplexing of the original RTP packets may be considered for the multiplexing of the original RTP packets
and the retransmitted RTP packets. and the retransmitted RTP packets.
One approach may be to retransmit the RTP packet with its original One approach may be to retransmit the RTP packet with its original
sequence number and send original and retransmission packets in the sequence number and send original and retransmission packets in the
same stream. The retransmission packet would then be identical to same stream. The retransmission packet would then be identical to
the original RTP packet, i.e. the same header (and thus same the original RTP packet, i.e. the same header (and thus same
sequence number) and the same payload. However, such an approach is sequence number) and the same payload. However, such an approach is
not acceptable because it would corrupt the RTCP statistics. As a not acceptable because it would corrupt the RTCP statistics. As a
consequence, requirement 1 would not be met. Correct RTCP statistics consequence, requirement 1 would not be met. Correct RTCP statistics
require that for every RTP packet within the RTP stream, the require that for every RTP packet within the RTP stream, the
sequence number be increased by one. sequence number be increased by one.
Another approach may be to multiplex original RTP packets and Another approach may be to multiplex original RTP packets and
retransmission packets in the same stream using the payload type retransmission packets in the same stream using the payload type
field. With such an approach the original stream and the field. With such an approach the original stream and the
Rey/Leon/Miyazaki/Varsa/Hakenberg 4
retransmission stream would share the same sequence number space. As retransmission stream would share the same sequence number space. As
a result, the RTP receiver would not be able to infer how many and 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. which original packets (i.e. with which sequence number) were lost.
In other words, this feature does not satisfy the sequence number In other words, this feature does not satisfy the sequence number
preservation requirement (requirement 6). This in turn implies that preservation requirement (requirement 6). This in turn implies that
requirement 4 would not be met. Interoperability with mixers and requirement 4 would not be met. Interoperability with mixers and
Rey/Leon/Miyazaki/Varsa/Hakenberg 4
translators would also be more difficult if they do not understand translators would also be more difficult if they do not understand
this new payload type in a sender RTP stream. this new payload type in a sender RTP stream. For these reasons, a
For these reasons, a solution based on payload type multiplexing of solution based on payload type multiplexing of original packets and
original packets and retransmission packets in the same RTP stream retransmission packets in the same RTP stream is excluded.
is excluded.
Finally, the original and retransmission packets may be sent in two Finally, the original and retransmission packets may be sent in two
separate streams. These two streams may be multiplexed either by separate streams. These two streams may be multiplexed either by
sending them in two different sessions , i.e. session-multiplexing, sending them in two different sessions , i.e. session-multiplexing,
or in the same session using different SSRCs, i.e. SSRC-multi- or in the same session using different SSRCs, i.e. SSRC-multi-
plexing. Since original and retransmission packets carry media of plexing. Since original and retransmission packets carry media of
the same type, the objections in Section 5.2 of RTP, RFC WWWW [3] to the same type, the objections in Section 5.2 of RTP, RFC WWWW [3] to
RTP multiplexing do not apply. RTP multiplexing do not apply.
Using two separate streams satisfies all the requirements listed in Using two separate streams satisfies all the requirements listed in
skipping to change at line 248 skipping to change at line 241
The use of separate sessions also allows differential treatment by The use of separate sessions also allows differential treatment by
the network and may simplify processing in mixers, translators and the network and may simplify processing in mixers, translators and
packet caches. packet caches.
With SSRC-multiplexing, a single session is needed for the original With SSRC-multiplexing, a single session is needed for the original
and the retransmission stream. This allows streaming servers and and the retransmission stream. This allows streaming servers and
middleware which are involved in a high number of concurrent middleware which are involved in a high number of concurrent
sessions to minimise their port usage. sessions to minimise their port usage.
This retransmission payload format allows for both session- This retransmission payload format allows both session-multiplexing
multiplexing and SSRC-multiplexing. From an implementation point of and SSRC-multiplexing. From an implementation point of view, there
view there is little difference between the two approaches.
Hence, in order to maximise interoperability, both multiplexing
approaches SHOULD be supported.
Rey/Leon/Miyazaki/Varsa/Hakenberg 5 Rey/Leon/Miyazaki/Varsa/Hakenberg 5
is little difference between the two approaches. Hence, in order to
maximise interoperability, both multiplexing approaches SHOULD be
supported.
4. Retransmission payload format 4. Retransmission payload format
The format of a retransmission packet is shown below: The format of a retransmission packet is shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | | | OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload | | Original RTP Packet Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP header usage is as follows: The RTP header usage is as follows:
If the original and the retransmission streams are sent in separate If the original and the retransmission streams are sent in separate
RTP sessions, the same SSRC value MUST be used for the original RTP sessions, the same SSRC value MUST be used for the original
stream and the retransmission stream. stream and the retransmission stream. In case of an SSRC collision,
an RTCP BYE packet MUST be sent for the original RTP session. After
In case of an SSRC collision, an RTCP BYE packet MUST be sent for a new SSRC identifier is obtained, the SSRC of the retransmission
the original RTP session. After a new SSRC identifier is obtained, session MUST be set to this value.
the SSRC of the retransmission session MUST be set to this value.
If the original stream and the retransmission stream are sent in the If the original stream and the retransmission stream are sent in the
same RTP session, two different SSRC values MUST be used for the same RTP session, two different SSRC values MUST be used for the
original stream and the retransmission stream as required by RTP. original stream and the retransmission stream as required by RTP.
For either multiplexing scheme, the sequence number has the standard 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 packet sent in the retransmission stream. the preceding packet sent in the retransmission stream.
The retransmission packet timestamp is set to the original The retransmission packet timestamp is set to the original
skipping to change at line 303 skipping to change at line 295
implications. implications.
Implementers have to be aware that the RTCP jitter value for the Implementers have to be aware that the RTCP jitter value for the
retransmission stream does not reflect the actual network jitter retransmission stream does not reflect the actual network jitter
since there could be little correlation between the time a packet is since there could be little correlation between the time a packet is
retransmitted and its original timestamp. retransmitted and its original timestamp.
The payload type is dynamic. Each payload type of the original The payload type is dynamic. Each payload type of the original
stream MUST map to a different payload type value in the stream MUST map to a different payload type value in the
retransmission stream. Therefore, when multiple payload types are 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.
Rey/Leon/Miyazaki/Varsa/Hakenberg 6 Rey/Leon/Miyazaki/Varsa/Hakenberg 6
used in the original stream, multiple dynamic payload types will be
mapped to this retransmission payload format. See Section 8 for the
specification of how the mapping between original and retransmission
payload types is done.
As the retransmission packet timestamp carries the original media As the retransmission packet timestamp carries the original media
timestamp, the timestamp clockrate used by the retransmission timestamp, the timestamp clockrate used by the retransmission
payload type is the same as the one used by the original payload payload type is the same as the one used by the associated original
type. It is thus possible to retransmit RTP packets whose payload payload type. It is thus possible to retransmit RTP packets whose
types have different timestamp clockrates in the same retransmission payload types have different timestamp clockrates in the same
stream if the original payload types have different clock rates, but retransmission stream if the original payload types have different
this is usually not the case. clock rates, but this is usually not the case.
If the original RTP header carried any profile-specific payload If the original RTP header carried any profile-specific payload
header, the retransmission packet MUST include this payload header. header, the retransmission packet MUST include this payload header.
If the original RTP header carried an RTP header extension, the If the original RTP header carried an RTP header extension, the
retransmission packet SHOULD carry the same header extension. retransmission packet SHOULD carry the same header extension.
The retransmission payload carries a payload header followed by the The retransmission payload carries a payload header followed by the
original RTP packet payload. The length of payload header is 2 original RTP packet payload. The length of payload header is 2
octets. The payload header contains only one field, OSN, which MUST octets. The payload header contains only one field, OSN, which MUST
skipping to change at line 347 skipping to change at line 340
5.1 Retransmission session sharing 5.1 Retransmission session sharing
In the case of session-multiplexing, a retransmission session MUST In the case of session-multiplexing, a retransmission session MUST
map to exactly one original session, i.e. the same retransmission map to exactly one original session, i.e. the same retransmission
session cannot be used for different original sessions. session cannot be used for different original sessions.
If retransmission session sharing were allowed, a receiver joining If retransmission session sharing were allowed, a receiver joining
the retransmission session would also receive the retransmissions the retransmission session would also receive the retransmissions
belonging to all other original sessions which the receiver may have belonging to all other original sessions which the receiver may have
not joined. There might also be SSRC identifier conflicts between not joined. For example, a receiver wishing to receive only audio
the different original sessions. would receive retransmitted video packets if an audio and video
session would share the same retransmission session.
5.2 CNAME use 5.2 CNAME use
A sender MUST use the same CNAME for an original stream and its A sender MUST use the same CNAME for an original stream and its
associated retransmission stream. associated retransmission stream.
Rey/Leon/Miyazaki/Varsa/Hakenberg 7
5.3 Association at the receiver 5.3 Association at the receiver
A receiver receiving multiple original and retransmission streams A receiver receiving multiple original and retransmission streams
needs to associate each retransmission stream with its original needs to associate each retransmission stream with its original
stream. The association is done differently depending on whether stream. The association is done differently depending on whether
session-multiplexing or SSRC-multiplexing is used. session-multiplexing or SSRC-multiplexing is used.
Rey/Leon/Miyazaki/Varsa/Hakenberg 7
If session-multiplexing is used, the receiver associates the two If session-multiplexing is used, the receiver associates the two
streams having the same SSRC in the two sessions. Note that the streams having the same SSRC in the two sessions. Note that the
payload type field cannot be used to do this coupling as several payload type field cannot be used to do this coupling as several
media streams may have the same payload type value. The two sessions media streams may have the same payload type value. The two sessions
are themselves associated out-of-band. See the SDP section to see are themselves associated out-of-band. See the SDP section to see
how the grouping of the two sessions is done with SDP. how the grouping of the two sessions is done with SDP.
If SSRC multiplexing is used, the receiver should first of all look 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 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 cases, the CNAME may not be enough to determine the association as
multiple original streams in the same session may share the same multiple original streams in the same session may share the same
CNAME. For example, there can be in the same video session multiple CNAME. For example, there can be in the same video session multiple
video streams mapping to different SSRCs and still use the same video streams mapping to different SSRCs and still using the same
CNAME and possibly the same PT values. Each (or some of) these CNAME and possibly the same PT values. Each (or some of) these
streams may have an associated retransmission stream. streams may have an associated retransmission stream.
In order to find out the association between original and In order to find out the association between original and
retransmission streams having the same CNAME, the receiver SHOULD retransmission streams having the same CNAME, the receiver SHOULD
behave as follows. behave as follows.
The association can generally be resolved when the receiver receives The association can generally be resolved when the receiver receives
a retransmission packet matching a retransmission request which had a retransmission packet matching a retransmission request which had
been sent earlier. Upon reception of a retransmission whose original been sent earlier. Upon reception of a retransmission whose original
skipping to change at line 397 skipping to change at line 392
derive that the SSRC of the retransmission packet is associated to derive that the SSRC of the retransmission packet is associated to
the sender SSRC from which the packet was requested. In order to the sender SSRC from which the packet was requested. In order to
avoid ambiguity, the receiver MUST NOT have two outstanding requests avoid ambiguity, the receiver MUST NOT have two outstanding requests
for the same packet sequence number in two different original for the same packet sequence number in two different original
streams before the association is resolved. Note that since the streams before the association is resolved. Note that since the
initial packet timestamps are random, the probability of having two initial packet timestamps are random, the probability of having two
outstanding requests for the same packet sequence number would be outstanding requests for the same packet sequence number would be
very small. very small.
If the receiver discovers that two senders are using the same SSRC If the receiver discovers that two senders are using the same SSRC
or receives an RTCP BYE packet, it MUST stop requesting or if it receives an RTCP BYE packet, it MUST stop requesting
retransmissions for that SSRC. Upon reception of original RTP retransmissions for that SSRC. Upon reception of original RTP
packets with a new SSRC, the receiver MUST perform the SSRC packets with a new SSRC, the receiver MUST perform the SSRC
association again as described in this section. association again as described in this section.
6. Use with the extended RTP profile for RTCP-based feedback 6. Use with the extended RTP profile for RTCP-based feedback
This section gives general hints for the usage of this payload This section gives general hints for the usage of this payload
format with the extended RTP profile for RTCP-based feedback [1], format with the extended RTP profile for RTCP-based feedback [1],
denoted AVPF. denoted AVPF.
Rey/Leon/Miyazaki/Varsa/Hakenberg 8 Rey/Leon/Miyazaki/Varsa/Hakenberg 8
6.1 RTCP Receiver reports 6.1 RTCP Receiver reports
If the original RTP stream and the retransmission stream are sent to If the original RTP stream and the retransmission stream are sent to
separate RTP sessions, the receiver will then send report blocks for separate RTP sessions, the receiver will then send report blocks for
the original stream and the retransmission streams in separate RTCP the original stream and the retransmission stream in separate RTCP
receiver reports (RR) packets belonging to separate RTP sessions. receiver reports (RR) packets belonging to separate RTP sessions.
RTCP packets reporting on the original stream are sent in the RTCP packets reporting on the original stream are sent in the
original RTP session while RTCP packets reporting on the original RTP session while RTCP packets reporting on the
retransmission stream are sent in the retransmission session. The retransmission stream are sent in the retransmission session. The
RTCP bandwidth for these two sessions may be chosen independently RTCP bandwidth for these two sessions may be chosen independently
(for example through RTCP bandwidth modifiers RFC ZZZZ [4]). (for example through RTCP bandwidth modifiers RFC ZZZZ [4]).
If the original RTP stream and the retransmission stream are sent in If the original RTP stream and the retransmission stream are sent in
the same session (SSRC multiplexing), the receiver sends report the same session (SSRC multiplexing), the receiver sends report
blocks for the original and the retransmission streams in the same blocks for the original and the retransmission streams in the same
skipping to change at line 443 skipping to change at line 438
into account such factors as the tolerable application delay, the into account such factors as the tolerable application delay, the
network environment and the media type. network environment and the media type.
The receiver should generally assess whether the retransmitted The receiver should generally assess whether the retransmitted
packet would still be useful at the time it is received. The packet would still be useful at the time it is received. The
timestamp of the missing packet can be estimated from the timestamps timestamp of the missing packet can be estimated from the timestamps
of packets preceding and/or following the sequence number gap caused of packets preceding and/or following the sequence number gap caused
by the missing packet in the original stream. In most cases, some by the missing packet in the original stream. In most cases, some
form of linear estimate of the timestamp is good enough. form of linear estimate of the timestamp is good enough.
Furthermore, a receiver should compute an estimate of RTT to the Furthermore, a receiver should compute an estimate of the round-trip
sender. This can be done, for example, by measuring the time (RTT) to the sender. This can be done, for example, by
retransmission delay to receive a retransmission packet after a NACK measuring the retransmission delay to receive a retransmission
message has been sent for that packet. This estimate may also be packet after a NACK message has been sent for that packet. This
obtained from past observations, RTCP report round-trip time if estimate may also be obtained from past observations, RTCP report
available or any other means. round-trip time if available or any other means.
The receiver should not send a retransmission request as soon as it
detects a missing sequence number but should add some extra delay to
compensate for packet reordering. This extra delay may, for example,
be based on past observations of the experienced packet reordering.
To increase the robustness to the loss of a NACK message or of a 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 retransmission packet, a receiver may send a new NACK message. This
is referred to as multiple retransmissions. is referred to as multiple retransmissions. Before sending a new
NACK message for a missing packet, the receiver should rely on a
timer to be reasonably sure that the previous retransmission attempt
has failed in order not to cause unnecessary retransmissions.
Rey/Leon/Miyazaki/Varsa/Hakenberg 9
NACK packets MUST be sent only for the original RTP stream. If a NACK packets MUST be sent only for the original RTP stream. If a
receiver wanted to perform multiple-retransmissions by sending a receiver wanted to perform multiple-retransmissions by sending a
NACK in the retransmission stream, it would not be able to know the NACK in the retransmission stream, it would not be able to know the
original sequence number and a timestamp estimation of the packet it original sequence number and a timestamp estimation of the packet it
requests. requests.
Rey/Leon/Miyazaki/Varsa/Hakenberg 9
6.3 Timing rules 6.3 Timing rules
The RTCP NACK packet may be sent in a regular full compound RTCP 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 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 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 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 the early RTCP packet was sent, the receiver will then have to wait
for the next regular RTCP compound packet after the early packet. for the next regular RTCP compound packet after the early packet.
Sending NACK packets only in regular RTCP compound decreases the Sending NACK packets only in regular RTCP compound decreases the
maximum delay between detecting an original packet loss and being maximum delay between detecting an original packet loss and being
able to send a NACK message for that packet. able to send a NACK message for that packet. Implementers should
consider the possible implications of this fact for the application
Implementers should consider the possible implications of this fact being used.
for the application being used.
Furthermore, receivers MAY make use of the minimum interval between Furthermore, receivers may make use of the minimum interval between
regular RTCP compound packets. This can be used, for example, to regular RTCP compound packets. This can be used, for example, to
keep reception reporting down to a given minimum, while still keep reception reporting down to a given minimum, while still
allowing receivers to react to periods requiring more frequent allowing receivers to react to periods requiring more frequent
feedback, e.g. times of higher packet loss rate. In this way, 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 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 specified by the minimum interval, but are still able to report
events requiring timely feedback, e.g. packet losses. Note that packet losses quickly enough. Note that although RTCP packets may be
although RTCP packets may be suppressed because they do not contain suppressed because they do not contain NACK packets, the reserved
NACK packets, the reserved RTCP bandwidth is the same as if they RTCP bandwidth is the same as if they were sent. See AVPF [1] for
were sent. See AVPF [1] for details. details.
7. Congestion control 7. Congestion control
RTP retransmission poses a risk of increasing 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 data without decreasing Reacting to loss by retransmission of older data without decreasing
the rate of the original stream would thus further increase the rate of the original stream would thus further increase
congestion. Implementations SHOULD follow the recommendations below congestion. Implementations SHOULD follow the recommendations below
in order to 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 TCP or RTP flows. order to be fair to other TCP or RTP flows.
If an RTP application uses retransmission, the acceptable packet If an RTP application uses retransmission, the acceptable packet
rate and bitrate includes both the original and retransmitted data. rate and bitrate includes both the original and retransmitted data.
This guarantees that an application using retransmission achieves This guarantees that an application using retransmission achieves
the same fairness as one that doesn't. Such a rule would translate the same fairness as one that does not. Such a rule would translate
in practice into the following actions: in practice into the following actions:
Rey/Leon/Miyazaki/Varsa/Hakenberg 10
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 selectively retransmit only the packets In addition, the sender MAY selectively retransmit only the packets
that it deems important and ignore NACK messages for other packets that it deems important and ignore NACK messages for other packets
in order to limit the bitrate. in order to limit the bitrate.
These congestion control mechanisms should keep the packet loss rate These congestion control mechanisms should keep the packet loss rate
within acceptable parameters. Packet loss is considered acceptable within acceptable parameters. Packet loss is considered acceptable
skipping to change at line 540 skipping to change at line 540
this would mean that congestion is not kept under control and this would mean that congestion is not kept under control and
retransmission should then not be used. It may further be necessary retransmission should then not be used. It may further be necessary
to adapt the transmission rate (or the number of layers subscribed to adapt the transmission rate (or the number of layers subscribed
for a layered multicast session), or to arrange for the receiver to for a layered multicast session), or to arrange for the receiver to
leave the session if the loss rate is unacceptably high. leave the session if the loss rate is unacceptably high.
8. SDP usage 8. SDP usage
8.1 Introduction 8.1 Introduction
This section specifies how to describe the retransmission delivery This section specifies how to describe the use of retransmission
method using the Session Description Protocol (SDP), RFC 2327 [5]. with the Session Description Protocol (SDP), RFC 2327 [5]. As
As specified in this document, the retransmission stream may be specified in this document, the retransmission stream may be
conveyed in separate RTP sessions, i.e. through session- conveyed in a separate RTP session, i.e. through session-
multiplexing, or in the same RTP session as the original stream multiplexing, or in the same RTP session as the original stream
through SSRC-multiplexing. through SSRC-multiplexing.
The following attributes and parameters are introduced in this The following attributes and parameters are introduced in this
document: "rtx", "rtx-time" and "apt". document: "rtx", "rtx-time" and "apt".
The binding used for the retransmission stream to the payload type The binding used for the retransmission stream to the payload type
number is indicated by an rtpmap attribute. The MIME subtype name number is indicated by an rtpmap attribute. The MIME subtype name
used in the binding is "rtx", as specified in Section 11. used in the binding is "rtx", as specified in Section 11.
An OPTIONAL payload format-specific parameter indicates the maximum An OPTIONAL payload format-specific parameter indicates the maximum
time a server will try to retransmit a packet. time a server will try to retransmit a packet.
The syntax is as follows: The syntax is as follows:
a=fmtp <number>: rtx-time=<rtx-time-val> a=fmtp <number>: rtx-time=<rtx-time-val>
where, where,
<number> indicates the dynamic payload type number assigned to <number> indicates the dynamic payload type number assigned to
the retransmission payload format in an rtpmap attribute. the retransmission payload format in an rtpmap attribute.
Rey/Leon/Miyazaki/Varsa/Hakenberg 11
<rtx-time-val> indicates the time in milliseconds, measured <rtx-time-val> indicates the time in milliseconds, measured
from the time a packet was first sent until the time the server from the time a packet was first sent until the time the server
will stop trying to retransmit the packet. No rtx-time will stop trying to retransmit the packet. The absence of the
parameter present for a retransmission stream means that the rtx-time parameter for a retransmission stream means that the
maximum retransmission time is not defined, but MAY be maximum retransmission time is not defined, but MAY be
negotiated by other means. negotiated by other means.
Rey/Leon/Miyazaki/Varsa/Hakenberg 11
Additionally, a new SDP payload-format-specific parameter "apt" MUST Additionally, a new SDP payload-format-specific parameter "apt" MUST
be used to map the RTX payload type to the associated original be used to map the RTX payload type to the associated original
stream payload type as seen in the SDP description examples below. stream payload type as seen in the SDP description examples below.
If multiple payload types are used in the original stream, then If multiple payload types are used in the original stream, then
multiple "apt" parameters MUST be included to map each original multiple "apt" parameters MUST be included to map each original
stream payload type to a different RTX payload type. The syntax of stream payload type to a different RTX payload type. The syntax of
this parameter is as follows: this parameter is as follows:
a=fmtp <number>: apt=<apt-value> a=fmtp <number>: apt=<apt-value>
where, where,
skipping to change at line 592 skipping to change at line 593
<apt-value> indicates the original stream payload type to which <apt-value> indicates the original stream payload type to which
this retransmission stream payload type is associated. this retransmission stream payload type is associated.
Some SDP description examples are presented in the following Some SDP description examples are presented in the following
subsections. subsections.
8.2 Mapping MIME Parameters into SDP 8.2 Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is describe RTP sessions. When SDP is used to specify retransmissions
used to specify retransmissions for an RTP stream, the mapping is for an RTP stream, the mapping is done as follows:
done as follows:
- The MIME types ("video"), ("audio") and ("text") go in the SDP - The MIME types ("video"), ("audio") and ("text") go in the SDP
"m=" as the media name. "m=" as the media name.
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding - 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 name. The RTP clock rate in "a=rtpmap" MUST be that of the
retransmission payload type. See Section 4 for details retransmission payload type. See Section 4 for details on this.
on this.
- The AVPF profile-specific parameters "ack" and "nack" go in SDP - The AVPF profile-specific parameters "ack" and "nack" go in SDP
"a=rtcp-fb". Several SDP "a=rtcp-fb" MUST be used for several "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of
types of feedback. See the AVPF profile [1] for details. feedback. See the AVPF profile [1] for details.
- The retransmission payload format-specific parameters "apt" and - The retransmission payload format-specific parameters "apt" and
"rtx-time" go in the SDP "a=fmtp" as a semicolon separated list "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of
of parameter=value pairs. parameter=value pairs.
- Any remaining parameters go in the SDP "a=fmtp" attribute by - Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a copying them directly from the MIME media type string as a semicolon
semicolon separated list of parameter=value pairs. separated list of parameter=value pairs.
Rey/Leon/Miyazaki/Varsa/Hakenberg 12
In the following sections some example SDP descriptions are In the following sections some example SDP descriptions are
presented. 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 8.3 SDP description with session-multiplexing
In the case of session-multiplexing the SDP description contains one In the case of session-multiplexing, the SDP description contains
media specification "m" line per RTP session. one media specification "m" line per RTP session. The SDP MUST
The SDP MUST provide the grouping of the original and associated provide the grouping of the original and associated retransmission
retransmission sessions' "m" lines, using the Flow Identification sessions' "m" lines, using the Flow Identification (FID) semantics
(FID) semantics defined in RFC YYYY [6]. defined in RFC YYYY [6].
The following example specifies two original, AMR and MPEG-4, The following example specifies two original, AMR and MPEG-4,
streams on ports 49170 and 49174 and their corresponding streams on ports 49170 and 49174 and their corresponding
retransmission streams on ports 49172 and 49176, respectively: retransmission streams on ports 49172 and 49176, respectively:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1 c=IN IP4 125.25.5.1
a=group:FID 1 2 a=group:FID 1 2
a=group:FID 3 4 a=group:FID 3 4
skipping to change at line 669 skipping to change at line 664
A special case of the SDP description is a description that contains A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session only one original session "m" line and one retransmission session
"m" line, the grouping is then obvious and FID semantics MAY be "m" line, the grouping is then obvious and FID semantics MAY be
omitted in this special case only. omitted in this special case only.
This is illustrated in the following example, which is an SDP This is illustrated in the following example, which is an SDP
description for a single original MPEG-4 stream and its description for a single original MPEG-4 stream and its
corresponding retransmission session: corresponding retransmission session:
Rey/Leon/Miyazaki/Varsa/Hakenberg 13
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1 c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
Rey/Leon/Miyazaki/Varsa/Hakenberg 13
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 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 a=fmtp:97 apt=96;rtx-time=3000
8.4 SDP description with SSRC-multiplexing 8.4 SDP description with SSRC-multiplexing
The following is an example of an SDP description for an RTP video The following is an example of an SDP description for an RTP video
skipping to change at line 704 skipping to change at line 700
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
9. RTSP considerations 9. RTSP considerations
The Real-time Streaming Protocol (RTSP) , RFC 2326 [7] is an The Real-time Streaming Protocol (RTSP) , RFC 2326 [7] is an
application-level protocol for control over the delivery of data application-level protocol for control over the delivery of data
with real-time properties. This section looks at the issues involved with real-time properties. This section looks at the issues involved
in controlling RTP sessions that use retransmissions. in controlling RTP sessions that use retransmissions.
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.
9.1 RTSP control with SSRC-multiplexing 9.1 RTSP control with SSRC-multiplexing
In the case of SSRC-multiplexing, there is a single RTSP "control" In the case of SSRC-multiplexing, the "m" line includes both
attribute for the media session. The receiver controls the original original and retransmission payload types and has a single RTSP
stream through the session RTSP control URL. As the receiver "control" attribute. The receiver uses the "m" line to request SETUP
receives the original stream it can request retransmission through and TEARDOWN of the whole media session. The RTP profile contained
RTCP requests without additional RTSP signalling. in the transport header MUST be the AVPF profile or another suitable
profile allowing extended feedback.
Rey/Leon/Miyazaki/Varsa/Hakenberg 14 In order to control the sending of the session original media
The RTP-info header that is used to set RTP-specific parameters in stream, the receiver sends as usual PLAY and PAUSE requests to the
the PLAY response can describe only a single RTP stream in the sender for the session. The RTP-info header that is used to set RTP-
session. The RTP-info header returned in the PLAY response MUST be specific parameters in the PLAY response MUST be set according to
the RTP information for the original stream. the RTP information of the original stream.
When the receiver starts receiving the original stream, it can then
request retransmission through RTCP NACKs without additional RTSP
signalling.
9.2 RTSP control with session-multiplexing 9.2 RTSP control with session-multiplexing
In the case of Session-multiplexing, each SDP "m" line must have an Rey/Leon/Miyazaki/Varsa/Hakenberg 14
RTSP "control" attribute. Hence, when retransmission is used, both In the case of session-multiplexing, each SDP "m" line has an RTSP
the original session and the retransmission have their own "control" "control" attribute. Hence, when retransmission is used, both the
attribute. The original session and the retransmission session are original session and the retransmission have their own "control"
associated through the FID semantics as specified in Section 8. attributes. The receiver can associate the original session and the
Both the original and the retransmission stream need to be setup retransmission session through the FID semantics as specified in
through their respective "control" attribute. Section 8.
If the presentation supports aggregate control, the session-level The original and the retransmission streams are set up and torn down
"control" attribute is used as usual to control the whole separately through their respective media "control" attribute. The
presentation. As the receiver receives the presentation original RTP profile contained in the transport header MUST be the AVPF
streams, it can request retransmission through RTCP without profile or another suitable profile allowing extended feedback for
additional RTSP signalling. both the original and the retransmission session.
If the presentation does not support aggregate control, the receiver The RTSP presentation SHOULD support aggregate control and SHOULD
should control each original stream as usual through its "control" contain a session level RTSP URL. The receiver SHOULD use aggregate
attribute. However, the receiver SHOULD NOT send PLAY or PAUSE control for an original session and its associated retransmission
requests for the retransmission streams. As the receiver receives session. Otherwise, there would need to be two different 'session-
the presentation original streams, it can request retransmission id' values, i.e. different values for the original and
through RTCP requests without additional RTSP signalling. retransmission sessions, and the sender would not know how to
associate them.
If an original stream is paused (independently of whether aggregate The session-level "control" attribute is then used as usual to
or non-aggregate control is used), a receiver may still send control the playing of the original stream. When the receiver starts
retransmission requests through RTCP. receiving the original stream, it can then request retransmissions
through RTCP without additional RTSP signalling.
9.3 Retransmission in pause state
Because of the nature of retransmissions, the sending of
retransmission packets SHOULD NOT be controlled through RTSP PLAY
and PAUSE requests. The PLAY and PAUSE requests should not affect
the retransmission stream. Retransmission packets are sent upon
receiver requests in the original RTCP stream, regardless of the
state.
9.4 Cache control
Retransmission streams SHOULD NOT be cached.
In the case of session-multiplexing, the "Cache-Control" header
SHOULD be set to "no-cache" for the retransmission stream.
In the case of SSRC-multiplexing, RTSP cannot specify independent
caching for the retransmission stream, because there is a single "m"
line in SDP. Therefore, the implementer should take this fact into
account when deciding whether to cache an SSRC-multiplexed session
or not.
10. Implementation examples 10. Implementation examples
This specification mandates only the sender and receiver behaviours This document mandates only the sender and receiver behaviours that
that are necessary for interoperability. In addition, certain are necessary for interoperability. In addition, certain algorithms,
algorithms, such as rate control or buffer management when targeted
at specific environments, may enhance the retransmission efficiency. Rey/Leon/Miyazaki/Varsa/Hakenberg 15
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 This section gives an overview of different implementation options
allowed within this specification. allowed within this specification.
The first example is a server-driven retransmission implementation. The first example is a server-driven retransmission implementation.
With this implementation, it is possible to retransmit lost RTP With this implementation, it is possible to retransmit lost RTP
packets, detect efficiently the loss of retransmissions and perform packets, detect efficiently the loss of retransmissions and perform
multiple retransmissions, if needed. Most of the necessary multiple retransmissions, if needed. Most of the necessary processing
processing is done at the server. is done at the server.
The second example shows a receiver-driven implementation. It The second example shows a receiver-driven implementation. It
illustrates how a receiver may increase the retransmission illustrates how a receiver may increase the retransmission
efficiency. This implementation also increases the sender scalability
Rey/Leon/Miyazaki/Varsa/Hakenberg 15 by reducing the load required at the sender.
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) The third example shows how retransmissions may be used in (small)
multicast groups in conjunction with layered encoding. It multicast groups in conjunction with layered encoding. It illustrates
illustrates that retransmissions and layered encoding may be that retransmissions and layered encoding may be complementary
complementary techniques. techniques.
10.1 A sender-driven retransmission example 10.1 A sender-driven retransmission example
This section gives an implementation example of multiple This section gives an implementation example of multiple
retransmissions. The sender transmits the original data in RTP retransmissions. The sender transmits the original data in RTP
packets using the MPEG-4 video RTP payload format. packets using the MPEG-4 video RTP payload format.
It is assumed that Generic NACK feedback messages are used, as per It is assumed that Generic NACK feedback messages are used, as per
[1]. An SDP description example with SSRC-multiplexing is given [1]. An SDP description example with SSRC-multiplexing is given
below: below:
skipping to change at line 804 skipping to change at line 822
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
The format-specific parameter "rtx-time" would indicate that the The format-specific parameter "rtx-time" would indicate that the
server will buffer the sent packets in a retransmission server will buffer the sent packets in a retransmission
buffer for 3.0 seconds, after which the packets are deleted from buffer for 3.0 seconds, after which the packets are deleted from
the retransmission buffer and will never be sent again. the retransmission buffer and will never be sent again.
In this implementation example, the required RTP receiver processing In this implementation example, the required RTP receiver processing
to handle retransmission is very limited. The receiver detects to handle retransmission is very limited. The receiver detects packet
packet loss from the gaps observed in the received sequence numbers. loss from the gaps observed in the received sequence numbers. It
It signals lost packets to the sender through RTCP NACK messages as signals lost packets to the sender through RTCP NACK messages as
defined in the AVPF profile [1]. The receiver should take into defined in the AVPF profile [1]. The receiver should take into
account the signalled sender retransmission buffer length in order account the signalled sender retransmission buffer length in order to
to dimension its own reception buffer. It should also derive from dimension its own reception buffer. It should also derive from the
the buffer length the maximum number of times retransmission of a
packet can be requested. Rey/Leon/Miyazaki/Varsa/Hakenberg 16
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 The sender should retransmit the packets selectively, i.e. it should
choose whether to retransmit a requested packet depending on the choose whether to retransmit a requested packet depending on the
packet importance, the observed QoS and congestion state of the packet importance, the observed QoS and congestion state of the
network connection to the receiver. Obviously, the sender processing network connection to the receiver. Obviously, the sender processing
increases with the number of receivers as state information and increases with the number of receivers as state information and
processing load must be allocated to each receiver. processing load must be allocated to each receiver.
Rey/Leon/Miyazaki/Varsa/Hakenberg 16
10.2 A receiver-driven retransmission example 10.2 A receiver-driven retransmission example
The receiver may have more accurate information than the sender The receiver may have more accurate information than the sender about
about the current network QoS such as available bandwidth, packet the current network QoS such as available bandwidth, packet loss
loss rate, delay and jitter. rate, delay and jitter. In addition, other receiver-specific
In addition, other receiver-specific parameters like buffer level, parameters like buffer level, estimated importance of the lost packet
estimated importance of the lost packet and application level QoS and application level QoS may be used by the receiver to make a more
may be used by the receiver to make a more efficient use of RTP efficient use of RTP retransmission through selective requests.
retransmission through selective requests.
Furthermore, a receiver may acknowledge the received packets. This Furthermore, a receiver may acknowledge the received packets. This
can be done by sending ACK messages, as per [1]. Upon receiving an can be done by sending ACK messages, as per [1]. Upon receiving an
ACK, the sender may delete all the acknowledged packets from its ACK, the sender may delete all the acknowledged packets from its
retransmission buffer. Note that this would also require only retransmission buffer. Note that this would also require only limited
limited increase in the required RTCP bandwidth as long as ACK increase in the required RTCP bandwidth as long as ACK packets are
packets are sent seldom enough. With the receiver-driven sent seldom enough. With the receiver-driven retransmission
retransmission implementation, processing load and buffer implementation, processing load and buffer requirements at the sender
requirements at the sender are decreased, allowing greater sender are decreased, allowing greater sender scalability.
scalability.
Note that choosing between the sender-driven implementation and the Note that choosing between the sender-driven implementation and the
receiver-driven implementation does not imply any changes in the SDP receiver-driven implementation does not imply any changes in the SDP
description, except for the need to signal the use of ACK RTCP 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: packets, by means of an additional SDP "a=rtcp-fb" line, as follows:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 at.home.ru
c=IN IP4 125.25.5.1 c=IN IP4 125.25.5.1
m=video 49170 RTP/AVPF 96 97 m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtcp-fb:96 ack a=rtcp-fb:96 ack
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
10.3 Retransmissions with Layered Transmissions 10.3 Retransmissions with Layered Transmissions
This section shows how to combine retransmissions with layered This section shows how to combine retransmissions with layered
encoding. Note that the retransmission framework is not intended as encoding. Note that the retransmission framework is not intended as a
a complete solution to reliable multicast. Refer to RFC 2887 [11], complete solution to reliable multicast. Refer to RFC 2887 [11], for
for an overview of the problems related with reliable multicast an overview of the problems related with reliable multicast
transmission. transmission.
Packets of different importance are sent in different RTP sessions. Packets of different importance are sent in different RTP sessions.
The retransmission streams corresponding to the different layers can 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 Rey/Leon/Miyazaki/Varsa/Hakenberg 17
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.
A retransmission stream may be sent in the same RTP session as its A retransmission stream may be sent in the same RTP session as its
corresponding original layer through SSRC multiplexing or in a corresponding original layer through SSRC multiplexing or in a
different RTP session through session multiplexing. different RTP session through session multiplexing.
An SDP description example for SSRC-multiplexing is given below: An SDP description example for SSRC-multiplexing is given below:
c=IN IP4 224.2.1.1/127/3 c=IN IP4 224.2.1.1/127/3
m=video 8000 RTP/AVPF 98 99 m=video 8000 RTP/AVPF 98 99
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98 a=fmtp:99 apt=98;rtx-time=3000
a=fmtp:99 rtx-time=3000
The server and the receiver may implement the retransmission method The server and the receiver may implement the retransmission methods
as illustrated in the previous examples. In addition, they may illustrated in the previous examples. In addition, they may choose to
choose to request and retransmit a lost packet depending on the request and retransmit a lost packet depending on the layer it
layer it belongs to. belongs to.
11. IANA considerations 11. IANA considerations
11.1 Registration of audio/rtx 11.1 Registration of audio/rtx
MIME type: audio MIME type: audio
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
skipping to change at line 917 skipping to change at line 933
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the rtx-time: indicates the time in milliseconds, measured from the
time a packet was first sent until the time the server will time a packet was first sent until the time the server will
stop trying to retransmit the packet 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 12 of RFC XXXX Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
Rey/Leon/Miyazaki/Varsa/Hakenberg 18
Published specification: RFC XXXX 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 rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Author/Change controller:
Jose Rey Jose Rey
David Leon. David Leon
IETF AVT WG IETF AVT WG
11.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: Required parameters:
skipping to change at line 1023 skipping to change at line 1042
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:
rey@panasonic.de rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Rey/Leon/Miyazaki/Varsa/Hakenberg 20
Intended usage: COMMON Intended usage: COMMON
Rey/Leon/Miyazaki/Varsa/Hakenberg 20
Author/Change controller: Author/Change controller:
Jose Rey Jose Rey
David Leon David Leon
IETF AVT WG IETF AVT WG
11.4 Registration of application/rtx 11.4 Registration of application/rtx
MIME type: application MIME type: application
MIME subtype: rtx MIME subtype: rtx
skipping to change at line 1117 skipping to change at line 1136
Any other security considerations of the profile under which the Any other security considerations of the profile under which the
retransmission scheme is used should be applied. retransmission scheme is used should be applied.
13. Acknowledgements 13. Acknowledgements
We would like to express our gratitude to Carsten Burmeister for his We would like to express our gratitude to Carsten Burmeister for his
participation in the development of this document. Our thanks also participation in the development of this document. Our thanks also
go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund,
Go Hori and Rahul Agarwal for their helpful comments. Go Hori and Rahul Agarwal for their helpful comments.
Rey/Leon/Miyazaki/Varsa/Hakenberg 22
14. References 14. References
14.1 Normative References 14.1 Normative References
1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP
profile for RTCP-based feedback", RFC VVVV, September 2002. profile for RTCP-based feedback", RFC VVVV, September 2002.
2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC WWWW, May Transport Protocol for Real-Time Applications", RFC WWWW, May
2002. 2002.
Rey/Leon/Miyazaki/Varsa/Hakenberg 22
4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC ZZZZ, 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC ZZZZ,
May 2002. May 2002.
5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
2327, April 1998. 2327, April 1998.
6 G. Camarillo,J. Holler, G. AP. Eriksson, "Grouping of media lines 6 G. Camarillo,J. Holler, G. AP. Eriksson, "Grouping of media lines
in SDP", RFC YYYY, February 2002. in SDP", RFC YYYY, February 2002.
7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol
skipping to change at line 1159 skipping to change at line 1177
14.2 Non-normative References 14.2 Non-normative References
9 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 9 C. Perkins, O. Hodson, "Options for Repair of Streaming Media",
RFC 2354, June 1998. RFC 2354, June 1998.
10 J. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 10 J. Hellstrom, "RTP for conversational text", RFC 2793, May 2000
11 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 11 M. Handley, et al., "The Reliable Multicast Design Space for Bulk
Data Transfer", RFC 2887, August 2000. Data Transfer", RFC 2887, August 2000.
Rey/Leon/Miyazaki/Varsa/Hakenberg 23
Author's Addresses Author's Addresses
Jose Rey rey@panasonic.de Jose Rey rey@panasonic.de
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-134 Phone: +49-6103-766-134
Fax: +49-6103-766-166 Fax: +49-6103-766-166
David Leon david.leon@nokia.com David Leon david.leon@nokia.com
skipping to change at line 1186 skipping to change at line 1202
Akihiro Miyazaki akihiro@isl.mei.co.jp Akihiro Miyazaki akihiro@isl.mei.co.jp
Core Software Development Center Core Software Development Center
Corporate Software Development Division Corporate Software Development Division
Matsushita Electric Industrial Co., Ltd. Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
Phone: +81-6-6900-9192 Phone: +81-6-6900-9192
Fax: +81-6-6900-9193 Fax: +81-6-6900-9193
Viktor Varsa viktor.varsa@nokia.com Viktor Varsa viktor.varsa@nokia.com
Nokia Research Center Nokia Research Center
Rey/Leon/Miyazaki/Varsa/Hakenberg 23
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
Phone: 1-972-374-1861 Phone: 1-972-374-1861
Rolf Hakenberg hakenberg@panasonic.de Rolf Hakenberg hakenberg@panasonic.de
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-162 Phone: +49-6103-766-162
Fax: +49-6103-766-166 Fax: +49-6103-766-166
 End of changes. 

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