draft-ietf-avt-rtp-retransmission-09.txt   draft-ietf-avt-rtp-retransmission-10.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita
09.txt D. Leon/Nokia 10.txt D. Leon/Nokia
A. Miyazaki/Matsushita A. Miyazaki/Matsushita
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Matsushita R. Hakenberg/Matsushita
Expires: February 2004 August 2003 Expires: July 2004 January 2004
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 RFC 2026. with all provisions of Section 10 of RFC 2026.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
[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 draft is published as an RFC. References in this draft to RFC
XXXX should be replaced with the RFC number assigned to this XXXX should be replaced with the RFC number assigned to this
document.] document.]
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. This for real-time applications with relaxed delay bounds. This
document describes an RTP payload format for performing document describes an RTP payload format for performing
retransmissions. Retransmitted RTP packets are sent in a separate retransmissions. Retransmitted RTP packets are sent in a separate
stream from the original RTP stream. It is assumed that feedback stream from the original RTP stream. It is assumed that feedback
from receivers to senders is available. In particular, it is from receivers to senders is available. In particular, it is
assumed that RTCP feedback as defined in the extended RTP profile assumed that RTCP feedback as defined in the extended RTP profile
for RTCP-based feedback (denoted RTP/AVPF), is available in this for RTCP-based feedback (denoted RTP/AVPF), is available in this
memo. memo.
Table of Contents Table of Contents
1. Introduction..................................................3 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.................................6 4. Retransmission payload format.................................6
5. Asocciation of a retransmission stream to its original stream.8 5. Asocciation of a retransmission stream to its original stream.8
6. Use with the extended RTP profile for RTCP-based feedback....10 6. Use with the extended RTP profile for RTCP-based feedback....10
7. Congestion control...........................................12 7. Congestion control...........................................12
8. Retransmission Payload Format MIME type registration.........13 8. Retransmission Payload Format MIME type registration.........13
9. RTSP considerations..........................................19 9. RTSP considerations..........................................19
10. Implementation examples.....................................21 10. Implementation examples.....................................21
11. IANA considerations.........................................23 11. IANA considerations.........................................23
skipping to change at page 3, line 19 skipping to change at page 2, line 43
such as forward error correction (FEC), retransmissions or such as forward error correction (FEC), retransmissions or
interleaving may be considered to increase packet loss resiliency. interleaving may be considered to increase packet loss resiliency.
RFC 2354 [8] discusses the different options. RFC 2354 [8] 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.
In the case of multimedia conferencing, the end-to-end delay has In the case of multimedia conferencing, the end-to-end delay has
to be at most a few hundred milliseconds in order to guarantee to 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 With sufficient latency, the efficiency of the repair scheme can
tolerate an initial latency as part of the session set-up and thus be increased. The sender may use the receiver feedback in
an end-to-end delay of several seconds may be acceptable. order to react to losses before their playout time at the
Retransmission may thus be considered for such applications. receiver.
This document specifies a retransmission method for RTP applicable In the case of multimedia streaming, the user can tolerate an
to unicast and (small) multicast groups: it defines a payload initial latency as part of the session set-up and thus an end-to-
format for retransmitted RTP packets and provides protocol rules end delay of several seconds may be acceptable. RTP
for the sender and the receiver involved in retransmissions. retransmission as defined in this document is targeted at such
applications.
Furthermore, this retransmission payload format was designed for At this point, the attention of the reader is called to the fact
use with the extended RTP profile for RTCP-based feedback, AVPF that the retransmission mechanism for RTP described in this
[1]. It may also be used with other RTP profiles defined in the document may be encumbered by patent applications filed from
future. Matsushita. Please refer to the IPR Notices section for details.
Furthermore, the RTP retransmission method defined herein is
applicable to unicast and (small) multicast groups. The present
document defines a payload format for retransmitted RTP packets
and provides protocol rules for the sender and the receiver
involved in retransmissions.
This retransmission payload format was designed for use with the
extended RTP profile for RTCP-based feedback, AVPF [1]. It may
also be used with other RTP profiles defined in the future.
The AVPF profile allows for more frequent feedback and for early The AVPF profile allows for more frequent feedback and for early
feedback. It defines a small number of general-purpose feedback feedback. It defines a small number of general-purpose feedback
messages, e.g. ACKs and NACKs, as well as codec and application- messages, e.g. ACKs and NACKs, as well as codec and application-
specific feedback 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:
skipping to change at page 5, line 46 skipping to change at page 5, line 36
Finally, the original and retransmission packets may be sent in Finally, the original and retransmission packets may be sent in
two separate streams. These two streams may be multiplexed either two separate streams. These two streams may be multiplexed either
by sending them in two different sessions , i.e. session- by sending them in two different sessions , i.e. session-
multiplexing, or in the same session using different SSRC values, multiplexing, or in the same session using different SSRC values,
i.e. SSRC-multiplexing. Since original and retransmission packets i.e. SSRC-multiplexing. Since original and retransmission packets
carry media of the same type, the objections in Section 5.2 of RTP carry media of the same type, the objections in Section 5.2 of RTP
[3] to RTP multiplexing do not apply in this case. [3] to RTP multiplexing do not apply in this case.
Mixers and translators may process the original stream and simply Mixers and translators may process the original stream and simply
discard the retransmission stream if they are unable to utilise discard the retransmission stream if they are unable to utilise
it. Using two separate streams thus satisfies all the it.
On the other hand, sending the original and retransmission packets
in two separate streams does not alone satisfy requirements 1 and
6. For this purpose, this document includes the original sequence
number in the retransmitted packets.
In this manner, using two separate streams satisfies all the
requirements listed in this section. requirements listed in this section.
3.1 Multiplexing scheme choice 3.1 Multiplexing scheme choice
Session-multiplexing and SSRC-multiplexing have different pros and Session-multiplexing and SSRC-multiplexing have different pros and
cons: cons:
Session-multiplexing is based on sending the retransmission stream Session-multiplexing is based on sending the retransmission stream
in a different RTP session (as defined in RTP [3]) from that of in a different RTP session (as defined in RTP [3]) from that of
the original stream, i.e. the original and retransmission streams the original stream, i.e. the original and retransmission streams
skipping to change at page 7, line 15 skipping to change at page 7, line 14
identifier is obtained, the SSRC of both streams MUST be set to identifier is obtained, the SSRC of both streams MUST be set to
this value. this value.
In the case of SSRC-multiplexing, two different SSRC values MUST In the case of SSRC-multiplexing, two different SSRC values MUST
be used for the original stream and the retransmission stream as be used for the original stream and the retransmission stream as
required by RTP. If an SSRC collision is detected for either the required by RTP. If an SSRC collision is detected for either the
original stream or the retransmission stream, the RTP original stream or the retransmission stream, the RTP
specification requires that an RTCP BYE packet MUST be sent for specification requires that an RTCP BYE packet MUST be sent for
this stream. An RTCP BYE packet MUST NOT be sent for the this stream. An RTCP BYE packet MUST NOT be sent for the
associated stream. Therefore, only the stream that experienced associated stream. Therefore, only the stream that experienced
SSRC collision will choose a new SSRC value. Refer to Section 5.3 SSRC collision MUST choose a new SSRC value. Refer to Section 5.3
for the implications on the original and retransmission stream for the implications on the original and retransmission stream
SSRC association at the receiver. SSRC association at the receiver.
For either multiplexing scheme, the sequence number has the For either multiplexing scheme, the sequence number has the
standard definition, i.e. it MUST be one higher than the sequence standard definition, i.e. it MUST be one higher than the sequence
number of the preceding packet sent in the retransmission stream. number of the preceding packet sent in the retransmission stream.
The retransmission packet timestamp is set to the original The retransmission packet timestamp MUST be set to the original
timestamp, i.e. to the timestamp of the original packet. As a timestamp, i.e. to the timestamp of the original packet. As a
consequence, the initial RTP timestamp for the first packet of the consequence, the initial RTP timestamp for the first packet of the
retransmission stream is not random but equal to the original retransmission stream is not random but equal to the original
timestamp of the first packet that is retransmitted. See the timestamp of the first packet that is retransmitted. See the
security considerations section in this document for security security considerations section in this document for security
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 since there could be little correlation between the time a packet
is retransmitted and its original timestamp. is retransmitted and its original timestamp.
The payload type is dynamic. Each payload type of the original The payload type is dynamic. If multiple payload types using
stream MUST map to a different payload type value in the retransmission are present in the original stream, then for each
retransmission stream. Therefore, when multiple payload types are of these, a dynamic payload type MUST be mapped to the
used in the original stream, multiple dynamic payload types will retransmission payload format. See Section 8.1 for the
be mapped to the retransmission payload format. See Section 8.1 specification of how the mapping between original and
for the specification of how the mapping between original and
retransmission payload types is done with SDP. retransmission payload types is done with SDP.
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 associated payload type MUST be the same as the one used by the associated
original payload type. Therefore, if an RTP stream carries original payload type. Therefore, if an RTP stream carries
payload types of different clockrates, this will also be the case payload types of different clockrates, this will also be the case
for the associated retransmission stream. Note that an RTP stream for the associated retransmission stream. Note that an RTP stream
does not usually carry payload types of different clockrates. does not usually carry payload types of different clockrates.
The payload of the RTP retransmission packet comprises the The payload of the RTP retransmission packet comprises the
retransmission payload header followed by the payload of the retransmission payload header followed by the payload of the
original RTP packet. The length of the retransmission payload original RTP packet. The length of the retransmission payload
header is 2 octets. This payload header contains only one field, header is 2 octets. This payload header contains only one field,
OSN (original sequence number), which MUST be set to the sequence OSN (original sequence number), which MUST be set to the sequence
number of the associated original RTP packet. The original RTP number of the associated original RTP packet. The original RTP
packet payload, including any possible payload headers specific to packet payload, including any possible payload headers specific to
the original payload type, is placed right after the the original payload type, MUST be placed right after the
retransmission payload header. retransmission payload header.
For payload formats that support encoding at multiple rates, For payload formats that support encoding at multiple rates,
instead of retransmitting the same payload as the original RTP instead of retransmitting the same payload as the original RTP
packet the sender MAY retransmit the same data encoded at a lower packet the sender MAY retransmit the same data encoded at a lower
rate. This aims at limiting the bandwidth usage of the rate. This aims at limiting the bandwidth usage of the
retransmission stream. When doing so, the sender MUST ensure that retransmission stream. When doing so, the sender MUST ensure that
the receiver will still be able to decode the payload of the the receiver will still be able to decode the payload of the
already sent original packets that might have been encoded based already sent original packets that might have been encoded based
on the payload of the lost original packet. In addition, if the on the payload of the lost original packet. In addition, if the
sender chooses to retransmit at a lower rate, the values in the sender chooses to retransmit at a lower rate, the values in the
payload header of the original RTP packet may not longer apply to payload header of the original RTP packet may not longer apply to
the retransmission packet and may need to be modified in the the retransmission packet and may need to be modified in the
retransmission packet to reflect the change in rate. The sender retransmission packet to reflect the change in rate. The sender
should trade-off the decrease in bandwidth usage with the decrease SHOULD trade-off the decrease in bandwidth usage with the decrease
in quality caused by resending at a lower rate. in quality caused by resending at a lower rate.
If the original RTP header carried any profile-specific If the original RTP header carried any profile-specific
extensions, the retransmission packet SHOULD include the same extensions, the retransmission packet SHOULD include the same
extensions immediately following the fixed RTP header as expected extensions immediately following the fixed RTP header as expected
by applications running under this profile. In this case, the by applications running under this profile. In this case, the
retransmission payload header is thus placed after the profile- retransmission payload header MUST be placed after the profile-
specific extensions. specific extensions.
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.
This header extension MUST be placed right after the fixed RTP This header extension MUST be placed right after the fixed RTP
header, as specified in RTP [3]. In this case, the retransmission header, as specified in RTP [3]. In this case, the retransmission
payload header is thus placed after the header extension. payload header MUST be placed after the header extension.
If the original RTP packet contained RTP padding, that padding If the original RTP packet contained RTP padding, that padding
MUST be removed before constructing the retransmission packet. If MUST be removed before constructing the retransmission packet. If
padding of the retransmission packet is needed, padding is padding of the retransmission packet is needed, padding MUST be
performed as with any RTP packets and the padding bit is set. performed as with any RTP packets and the padding bit MUST be set.
The marker bit (M), the CSRC count (CC) and the CSRC list of the The marker bit (M), the CSRC count (CC) and the CSRC list of the
original RTP header MUST be copied "as is" into the RTP header of original RTP header MUST be copied "as is" into the RTP header of
the retransmission packet. the retransmission packet.
5. Association of a retransmission stream to its original stream 5. Association of a retransmission stream to its original stream
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
skipping to change at page 26, line 40 skipping to change at page 26, line 40
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
IPR Notices IPR Notices
The IETF has been notified of intellectual property rights claimed The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For details on the IPR statement, please visit the IETF
rights. IPR web page, http://www.ietf.org/ietf/IPR.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; neither does it represent rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found standards-track and standards-related documentation can be found
in BCP 11 [13]. Copies of claims of rights made available for in BCP 11 [13]. Copies of claims of rights made available for
skipping to change at page 27, line 15 skipping to change at page 27, line 15
Secretariat. Secretariat.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required proprietary rights which may cover technology that may be required
to practice this standard. Please address the information to the to practice this standard. Please address the information to the
IETF Executive Director. IETF Executive Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
 End of changes. 

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