draft-ietf-avt-rtp-retransmission-06.txt   draft-ietf-avt-rtp-retransmission-07.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission-06.txt J. Rey/Matsushita draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita
D. Leon/Nokia 07.txt D. Leon/Nokia
A. Miyazaki/Matsushita A. Miyazaki/Matsushita
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Matsushita R. Hakenberg/Matsushita
Expires: August 2003 February 2003 Expires: November 2003 April 2003
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
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
at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts
reference material or to cite them other than as "work in progress." as 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 XXXX draft is published as an RFC. References in this draft to RFC
should be replaced with the RFC number assigned to this document.] XXXX should be replaced with the RFC number assigned to this
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 document for real-time applications with relaxed delay bounds. This
describes an RTP payload format for performing retransmissions. document describes an RTP payload format for performing
Retransmitted RTP packets are sent in a separate stream from the retransmissions. Retransmitted RTP packets are sent in a separate
original RTP stream. It is assumed that feedback from receivers to stream from the original RTP stream. It is assumed that feedback
senders is available. In particular, it is assumed that RTCP from receivers to senders is available. In particular, it is
feedback as defined in the extended RTP profile for RTCP-based assumed that RTCP feedback as defined in the extended RTP profile
feedback (denoted RTP/AVPF), is available in this memo. for RTCP-based feedback (denoted RTP/AVPF), is available in this
memo.
Table of Contents Table of Contents
1. Introduction....................................................3 1. Introduction..................................................3
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. Association of a retransmission stream with 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.......................................20 10. Implementation examples.....................................21
11. IANA considerations...........................................23 11. IANA considerations.........................................24
12. Security considerations.......................................23 12. Security considerations.....................................24
13. Acknowledgements..............................................24 13. Acknowledgements............................................24
14. References....................................................24 14. References..................................................25
Author's Addresses................................................25 15. Author's Addresses..........................................26
15. IPR Notices...................................................26 IPR Notices.....................................................26
16. Full Copyright Statement......................................26 Full Copyright Statement........................................27
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,
as forward error correction (FEC), retransmissions or interleaving such as forward error correction (FEC), retransmissions or
may be considered to increase packet loss resiliency. RFC 2354 [8] interleaving may be considered to increase packet loss resiliency.
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 to In the case of multimedia conferencing, the end-to-end delay has
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 tolerate However, in the case of multimedia streaming, the user can
an initial latency as part of the session set-up and thus an end-to- tolerate an initial latency as part of the session set-up and thus
end delay of several seconds may be acceptable. Retransmission may an end-to-end delay of several seconds may be acceptable.
thus be considered for such applications. Retransmission may thus be considered for such applications.
This document specifies a retransmission method for RTP applicable This document specifies a retransmission method for RTP applicable
to unicast and (small) multicast groups: it defines a payload format to unicast and (small) multicast groups: it defines a payload
for retransmitted RTP packets and provides protocol rules for the format for retransmitted RTP packets and provides protocol rules
sender and the receiver involved in retransmissions. for the sender and the receiver involved in retransmissions.
Furthermore, this retransmission payload format was designed for use Furthermore, this retransmission payload format was designed for
with the extended RTP profile for RTCP-based feedback, AVPF [1]. It use with the extended RTP profile for RTCP-based feedback, AVPF
may also be used with other RTP profiles defined in the future. [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:
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 which is to be used Retransmission packet: refers to an RTP packet which is to be used
by the receiver instead of a lost original packet. Such a by the receiver instead of a lost original packet. Such a
retransmission packet is said to be associated with the original RTP retransmission packet is said to be associated with the original
packet. RTP packet.
Retransmission request: a means by which an RTP receiver is able to Retransmission request: a means by which an RTP receiver is able
request that the RTP sender should send a retransmission packet for to request that the RTP sender should send a retransmission packet
a given original packet. Usually, an RTCP NACK packet as specified for a given original packet. Usually, an RTCP NACK packet as
in [1] is used as retransmission request for lost packets. specified in [1] is used as retransmission request for lost
packets.
Retransmission stream: the stream of retransmission packets Retransmission stream: the stream of retransmission packets
associated 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.
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
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in RFC 2119 [2]. in this 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 use of retransmissions in RTP as a repair method for streaming The use of retransmissions in RTP as a repair method for streaming
media is appropriate in those scenarios with relaxed delay bounds media is appropriate in those scenarios with relaxed delay bounds
and where full reliability is not a requirement. More specifically, and where full reliability is not a requirement. More
RTP retransmission allows to trade-off reliability vs. delay, i.e. specifically, RTP retransmission allows to trade-off reliability
the endpoints may give up retransmitting a lost packet after a given vs. delay, i.e. the endpoints may give up retransmitting a lost
buffering time has elapsed. Unlike TCP there is thus no head-of- packet after a given buffering time has elapsed. Unlike TCP
line blocking caused by RTP retransmissions. The implementer should there is thus no head-of-line blocking caused by RTP
be aware that in cases where full reliability is required or higher retransmissions. The implementer should be aware that in cases
delay and jitter can be tolerated, TCP or other transport options where full reliability is required or higher delay and jitter can
should be considered. be tolerated, TCP or other transport options should be considered.
The RTP retransmission scheme defined in this document is designed The RTP retransmission scheme defined in this document is designed
to fulfil the following set of requirements: to fulfil the following set of 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 of multiple payload types in a 5. It must not prevent the use of multiple payload types in a
session. session.
6. In order to support the largest variety of payload formats, the 6. In order to support the largest variety of payload formats, the
RTP receiver must be able to derive how many and which RTP RTP receiver must be able to derive how many and which RTP
packets were lost as a result of a gap in received RTP sequence packets were lost as a result of a gap in received RTP sequence
numbers. This requirement is referred to as sequence number numbers. This requirement is referred to as sequence number
preservation. Without such a requirement, it would be impossible preservation. Without such a requirement, it would be
to use retransmission with payload formats, such as impossible to use retransmission with payload formats, such as
conversational text [9] or most audio/video streaming conversational text [9] or most audio/video streaming
applications, that use the RTP sequence number to detect lost applications, that use the RTP sequence number to detect lost
packets. packets.
When designing a solution for RTP retransmission, several approaches When designing a solution for RTP retransmission, several
may be considered for the multiplexing of the original RTP packets approaches may be considered for the multiplexing of the original
and the retransmitted RTP packets. 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
same RTP stream. The retransmission packet would then be identical the same RTP stream. The retransmission packet would then be
to the original RTP packet, i.e. the same header (and thus same identical to the original RTP packet, i.e. the same header (and
sequence number) and the same payload. However, such an approach is thus same sequence number) and the same payload. However, such an
not acceptable because it would corrupt the RTCP statistics. As a approach is not acceptable because it would corrupt the RTCP
consequence, requirement 1 would not be met. Correct RTCP statistics. As a consequence, requirement 1 would not be met.
statistics require that for every RTP packet within the RTP stream, Correct RTCP statistics require that for every RTP packet within
the sequence number be increased by one. the RTP stream, the 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 RTP stream using different retransmission packets in the same RTP stream using different
payload type values. With such an approach, the original packets payload type values. With such an approach, the original packets
and the retransmission packets would share the same sequence number and the retransmission packets would share the same sequence
space. As a result, the RTP receiver would not be able to infer how number space. As a result, the RTP receiver would not be able to
many and which original packets (which sequence numbers) were lost. infer how many and which original packets (which sequence numbers)
were lost.
In other words, this approach does not satisfy the sequence number In other words, this approach does not satisfy the sequence number
preservation requirement (requirement 6). This in turn implies that preservation requirement (requirement 6). This in turn implies
requirement 4 would not be met. Interoperability with mixers and that requirement 4 would not be met. Interoperability with mixers
translators would also be more difficult if they did not understand and translators would also be more difficult if they did not
this new retransmission payload type in a sender RTP stream. For understand this new retransmission payload type in a sender RTP
these reasons, a solution based on payload type multiplexing of stream. For these reasons, a solution based on payload type
original packets and retransmission packets in the same RTP stream multiplexing of original packets and retransmission packets in the
is excluded. same RTP stream is excluded.
Finally, the original and retransmission packets may be sent in two Finally, the original and retransmission packets may be sent in
separate streams. These two streams may be multiplexed either by two separate streams. These two streams may be multiplexed either
sending them in two different sessions , i.e. session-multiplexing, by sending them in two different sessions , i.e. session-
or in the same session using different SSRC values, i.e. SSRC- multiplexing, or in the same session using different SSRC values,
multiplexing. Since original and retransmission packets carry media i.e. SSRC-multiplexing. Since original and retransmission packets
of the same type, the objections in Section 5.2 of RTP [3] to RTP carry media of the same type, the objections in Section 5.2 of 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 it. discard the retransmission stream if they are unable to utilise
Using two separate streams thus satisfies all the requirements it. Using two separate streams thus satisfies all the
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 the in a different RTP session (as defined in RTP [3]) from that of
original stream, i.e. the original and retransmission streams are the original stream, i.e. the original and retransmission streams
sent to different network addresses and/or port numbers. Having a are sent to different network addresses and/or port numbers.
separate session allows more flexibility. In multicast, using two
separate sessions for the original and the retransmission streams
allows a receiver to choose whether or not to subscribe to the RTP
session carrying the retransmission stream. The original session
may also be single-source multicast while separate unicast sessions
are used to convey retransmissions to each of the receivers, which
as a result will receive only the retransmission packets they
request.
The use of separate sessions also facilitates differential treatment Having a separate session allows more flexibility. In multicast,
by the network and may simplify processing in mixers, translators using two separate sessions for the original and the
and packet caches. retransmission streams allows a receiver to choose whether or not
to subscribe to the RTP session carrying the retransmission
stream. The original session may also be single-source multicast
while separate unicast sessions are used to convey retransmissions
to each of the receivers, which as a result will receive only the
retransmission packets they request.
With SSRC-multiplexing, a single session is needed for the original The use of separate sessions also facilitates differential
and the retransmission stream. This allows streaming servers and treatment by the network and may simplify processing in mixers,
middleware which are involved in a high number of concurrent translators and packet caches.
sessions to minimise their port usage.
This retransmission payload format allows both session-multiplexing With SSRC-multiplexing, a single session is needed for the
and SSRC-multiplexing for unicast sessions. From an implementation original and the retransmission stream. This allows streaming
point of view, there is little difference between the two servers and middleware which are involved in a high number of
approaches. Hence, in order to maximise interoperability, both concurrent sessions to minimise their port usage.
multiplexing approaches SHOULD be supported by senders and
This retransmission payload format allows both session-
multiplexing and SSRC-multiplexing for unicast sessions. From an
implementation point of view, there is little difference between
the two approaches. Hence, in order to maximise interoperability,
both multiplexing approaches SHOULD be supported by senders and
receivers. For multicast sessions, session-multiplexing MUST be receivers. For multicast sessions, session-multiplexing MUST be
used because the association of the original stream and the used because the association of the original stream and the
retransmission stream is problematic if SSRC-multiplexing is used retransmission stream is problematic if SSRC-multiplexing is used
with multicast sessions(see Section 5.3 for motivation). with multicast sessions(see Section 5.3 for motivation).
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:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | 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:
In the case of session-multiplexing, the same SSRC value MUST be In the case of session-multiplexing, the same SSRC value MUST be
used for the original stream and the retransmission stream. In the used for the original stream and the retransmission stream. In
case of an SSRC collision in either the original session or the the case of an SSRC collision in either the original session or
retransmission session, the RTP specification requires that an RTCP the retransmission session, the RTP specification requires that an
BYE packet MUST be sent in the session where the collision happened. RTCP BYE packet MUST be sent in the session where the collision
In addition, an RTCP BYE packet MUST also be sent for the associated happened. In addition, an RTCP BYE packet MUST also be sent for
stream in its own session. After a new SSRC identifier is obtained, the associated stream in its own session. After a new SSRC
the SSRC of both streams MUST be set to this value. identifier is obtained, the SSRC of both streams MUST be set to
this value.
In the case of SSRC-multiplexing, two different SSRC values MUST be In the case of SSRC-multiplexing, two different SSRC values MUST
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 specification original stream or the retransmission stream, the RTP
requires that an RTCP BYE packet MUST be sent for this stream. No specification requires that an RTCP BYE packet MUST be sent for
RTCP BYE packet MUST be sent for the associated stream. Therefore, this stream. No RTCP BYE packet MUST be sent for the associated
only the stream that experienced SSRC collision will choose a new stream. Therefore, only the stream that experienced SSRC
SSRC value. Refer to Section 5.3 for the implications on the collision will choose a new SSRC value. Refer to Section 5.3 for
original and retransmission stream SSRC association at the receiver. the implications on the original and retransmission stream SSRC
association at the receiver.
For either multiplexing scheme, the sequence number has the standard For either multiplexing scheme, the sequence number has the
definition, i.e. it MUST be one higher than the sequence number of standard definition, i.e. it MUST be one higher than the sequence
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 is 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 is since there could be little correlation between the time a packet
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. 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 used in the original stream, multiple dynamic payload types will
mapped to the retransmission payload format. See Section 8.1 for be mapped to the retransmission payload format. See Section 8.1
the 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 original payload type is the same as the one used by the associated
payload type. It is thus possible to send retransmission packets original payload type. It is thus possible to send retransmission
whose original payload types have different timestamp clockrates in packets whose original payload types have different timestamp
the same retransmission stream. Note that an RTP stream does not clockrates in the same retransmission stream. Note that an RTP
usually carry payload types of different clockrates. stream 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, which MUST be set to the sequence number of the associated OSN (original sequence number), which MUST be set to the sequence
original RTP packet. The original RTP packet payload, including any number of the associated original RTP packet. The original RTP
possible payload headers specific to the original payload type, is packet payload, including any possible payload headers specific to
placed right after the retransmission payload header. the original payload type, is placed right after the
retransmission payload header.
For payload types that support encoding at multiple rates, instead For payload types that support encoding at multiple rates, instead
of retransmitting the same payload as the original RTP packet the of retransmitting the same payload as the original RTP packet the
sender MAY retransmit the same data encoded at a lower rate. This sender MAY retransmit the same data encoded at a lower rate. This
aims at limiting the bandwidth usage of the retransmission stream. aims at limiting the bandwidth usage of the retransmission stream.
When doing so, the sender MUST ensure that the receiver will still When doing so, the sender MUST ensure that the receiver will still
be able to decode the payload of the already sent original packets be able to decode the payload of the already sent original packets
that might have been encoded based on the payload of the lost that might have been encoded based on the payload of the lost
original packet. In addition, if the sender chooses to retransmit original packet. In addition, if the sender chooses to retransmit
at a lower rate, the values in the payload header of the original at a lower rate, the values in the payload header of the original
RTP packet may not longer apply to the retransmission packet and may RTP packet may not longer apply to the retransmission packet and
need to be modified in the retransmission packet to reflect the may need to be modified in the retransmission packet to reflect
change in rate. The sender should trade-off the decrease in the change in rate. The sender should trade-off the decrease in
bandwidth usage with the decrease in quality caused by resending at bandwidth usage with the decrease in quality caused by resending
a lower rate. at a lower rate.
If the original RTP header carried any profile-specific extensions, If the original RTP header carried any profile-specific
the retransmission packet SHOULD include the same extensions extensions, the retransmission packet SHOULD include the same
immediately following the fixed RTP header as expected by extensions immediately following the fixed RTP header as expected
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 is thus 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. This retransmission packet SHOULD carry the same header extension.
header extension MUST be placed right after the fixed RTP header, as This header extension MUST be placed right after the fixed RTP
specified in RTP [3]. In this case, the retransmission payload header, as specified in RTP [3]. In this case, the retransmission
header is thus placed after the header extension. payload header is thus placed after the header extension.
If the original RTP packet contained RTP padding, that padding MUST If the original RTP packet contained RTP padding, that padding
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 performed padding of the retransmission packet is needed, padding is
as with any RTP packets and the padding bit is set. performed as with any RTP packets and the padding bit is set.
The M, CC and CSRC bit of the original RTP header MUST be copied "as The marker bit (M), the CSRC count (CC) and the CSRC list of the
is" into the RTP header of the retransmission packet. original RTP header MUST be copied "as is" into the RTP header of
the retransmission packet.
5. Association of a retransmission stream with 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
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, it would be a If retransmission session sharing were allowed, it would be a
problem for receivers, since they would receive retransmissions for problem for receivers, since they would receive retransmissions
original sessions they might not have joined. For example, a for original sessions they might not have joined. For example, a
receiver wishing to receive only audio would receive also receiver wishing to receive only audio would receive also
retransmitted video packets if an audio and video session shared the retransmitted video packets if an audio and video session shared
same retransmission session. the same retransmission session.
5.2 CNAME use 5.2 CNAME use
In both the session-multiplexing and the SSRC-multiplexing cases, a In both the session-multiplexing and the SSRC-multiplexing cases,
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.
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.
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 perform the association as payload type field cannot be used to perform the association as
several media streams may have the same payload type value. The two several media streams may have the same payload type value. The
sessions are themselves associated out-of-band. See Section 8 for two sessions are themselves associated out-of-band. See Section 8
how the grouping of the two sessions is done with SDP. for 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
for two streams that have the same CNAME in the session. In some look for two streams that have the same CNAME in the session. In
cases, the CNAME may not be enough to determine the association as some cases, the CNAME may not be enough to determine the
multiple original streams in the same session may share the same association as multiple original streams in the same session may
CNAME. For example, there can be in the same video session multiple share the same CNAME. For example, there can be in the same video
video streams mapping to different SSRCs and still using the same session multiple video streams mapping to different SSRCs and
CNAME and possibly the same PT values. Each (or some) of these still using the same CNAME and possibly the same PT values. Each
streams may have an associated retransmission stream. (or some) of these streams may have an associated retransmission
stream.
In this case, in order to find out the association between original In this case, in order to find out the association between
and retransmission streams having the same CNAME, the receiver original and retransmission streams having the same CNAME, the
SHOULD behave as follows. receiver SHOULD behave as follows.
The association can generally be resolved when the receiver receives The association can generally be resolved when the receiver
a retransmission packet matching a retransmission request which had receives a retransmission packet matching a retransmission request
been sent earlier. Upon reception of a retransmission packet whose which had been sent earlier. Upon reception of a retransmission
original sequence number has been previously requested, the receiver packet whose original sequence number has been previously
can derive that the SSRC of the retransmission packet is associated requested, the receiver can derive that the SSRC of the
to the sender SSRC from which the packet was requested. retransmission packet is associated to the sender SSRC from which
the packet was requested.
However, this mechanism might fail if there are two outstanding However, this mechanism might fail if there are two outstanding
requests for the same packet sequence number in two different requests for the same packet sequence number in two different
original streams of the session. Note that since the initial packet original streams of the session. Note that since the initial
sequence numbers are random, the probability of having two packet sequence numbers 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. Nevertheless, in order to avoid ambiguity in the very small. Nevertheless, in order to avoid ambiguity in the
unicast case, the receiver MUST NOT have two outstanding requests unicast case, 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. In multicast, this streams before the association is resolved. In multicast, this
ambiguity cannot be completely avoided, because another receiver may ambiguity cannot be completely avoided, because another receiver
have requested the same sequence number from another stream. may have requested the same sequence number from another stream.
Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. Therefore, SSRC-multiplexing MUST NOT be used in multicast
sessions.
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 if it 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, format with the extended RTP profile for RTCP-based feedback,
denoted AVPF [1]. Note that the general RTCP send and receive rules denoted AVPF [1]. Note that the general RTCP send and receive
and the RTCP packet format as specified in RTP apply, except for the rules and the RTCP packet format as specified in RTP apply, except
changes that the AVPF profile introduces. In short, the AVPF for the changes that the AVPF profile introduces. In short, the
profile relaxes the RTCP timing rules and specifies additional AVPF profile relaxes the RTCP timing rules and specifies
general-purpose RTCP feedback messages. See [1] for details. additional general-purpose RTCP feedback messages. See [1] for
details.
6.1 RTCP at the sender 6.1 RTCP at the sender
In the case of session-multiplexing, Sender Report (SR) packets for In the case of session-multiplexing, Sender Report (SR) packets
the original stream are sent in the original session and SR packets for the original stream are sent in the original session and SR
for the retransmission stream are sent in the retransmission session packets for the retransmission stream are sent in the
according to the rules of RTP. retransmission session according to the rules of RTP.
In the case of SSRC-multiplexing, SR packets for both original and In the case of SSRC-multiplexing, SR packets for both original and
retransmission streams are sent in the same session according to the retransmission streams are sent in the same session according to
rules of RTP. The original and retransmission streams are seen, as the rules of RTP. The original and retransmission streams are
far the RTCP bandwidth calculation is concerned, as independent seen, as far the RTCP bandwidth calculation is concerned, as
senders belonging to the same RTP session and are thus equally independent senders belonging to the same RTP session and are thus
sharing the RTCP bandwidth assigned to senders. equally sharing the RTCP bandwidth assigned to senders.
Note that in both cases, session- and SSRC-multiplexing, BYE packets Note that in both cases, session- and SSRC-multiplexing, BYE
MUST still be sent for both streams as specified in RTP. In other packets MUST still be sent for both streams as specified in RTP.
words, it is not enough to send BYE packets for the original stream In other words, it is not enough to send BYE packets for the
only. original stream only.
6.2 RTCP Receiver Reports 6.2 RTCP Receiver Reports
In the case of session-multiplexing, the receiver will send report In the case of session-multiplexing, the receiver will send report
blocks for the original stream and the retransmission stream in blocks for the original stream and the retransmission stream in
separate Receiver Report (RR) packets belonging to separate RTP separate Receiver Report (RR) packets belonging to separate RTP
sessions. RR packets reporting on the original stream are sent in sessions. RR packets reporting on the original stream are sent in
the original RTP session while RR packets reporting on the the original RTP session while RR 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 [4]). (for example through RTCP bandwidth modifiers [4]).
In the case of SSRC-multiplexing, the receiver sends report blocks In the case of SSRC-multiplexing, the receiver sends report blocks
for the original and the retransmission streams in the same RR for the original and the retransmission streams in the same RR
packet since there is a single session. packet since there is a single session.
6.3 Retransmission requests 6.3 Retransmission requests
The NACK feedback message format defined in the AVPF profile SHOULD The NACK feedback message format defined in the AVPF profile
be used by receivers to send retransmission requests. Whether a SHOULD be used by receivers to send retransmission requests.
receiver chooses to request a packet or not is an implementation Whether a receiver chooses to request a packet or not is an
issue. An actual receiver implementation should take into account implementation issue. An actual receiver implementation should
such factors as the tolerable application delay, the network take into account such factors as the tolerable application delay,
environment and the media type. the 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
of packets preceding and/or following the sequence number gap caused timestamps of packets preceding and/or following the sequence
by the missing packet in the original stream. In most cases, some number gap caused by the missing packet in the original stream.
form of linear estimate of the timestamp is good enough. In most cases, some form of linear estimate of the timestamp is
good enough.
Furthermore, a receiver should compute an estimate of the round-trip Furthermore, a receiver should compute an estimate of the round-
time (RTT) to the sender. This can be done, for example, by trip time (RTT) to the sender. This can be done, for example, by
measuring the retransmission delay to receive a retransmission measuring the retransmission delay to receive a retransmission
packet after a NACK has been sent for that packet. This estimate packet after a NACK has been sent for that packet. This estimate
may also be obtained from past observations, RTCP report round-trip may also be obtained from past observations, RTCP report round-
time if available or any other means. A standard mechanism for the trip time if available or any other means. A standard mechanism
receiver to estimate the RTT is specified in RTP Extended Reports for the receiver to estimate the RTT is specified in RTP Extended
[11]. Reports [11].
The receiver should not send a retransmission request as soon as it The receiver should not send a retransmission request as soon as
detects a missing sequence number but should add some extra delay to it detects a missing sequence number but should add some extra
compensate for packet reordering. This extra delay may, for delay to compensate for packet reordering. This extra delay may,
example, be based on past observations of the experienced packet for example, be based on past observations of the experienced
reordering. packet reordering.
To increase the robustness to the loss of a NACK or of a To increase the robustness to the loss of a NACK or of a
retransmission packet, a receiver may send a new NACK for the same retransmission packet, a receiver may send a new NACK for the same
packet. This is referred to as multiple retransmissions. Before packet. This is referred to as multiple retransmissions. Before
sending a new NACK for a missing packet, the receiver should rely on sending a new NACK for a missing packet, the receiver should rely
a timer to be reasonably sure that the previous retransmission on a timer to be reasonably sure that the previous retransmission
attempt has failed in order to avoid unnecessary retransmissions. attempt has failed in order to avoid unnecessary retransmissions.
NACKs MUST be sent only for the original RTP stream. Otherwise, if NACKs MUST be sent only for the original RTP stream. Otherwise,
a receiver wanted to perform multiple retransmissions by sending a if a receiver wanted to perform multiple retransmissions by
NACK in the retransmission stream, it would not be able to know the sending a NACK in the retransmission stream, it would not be able
original sequence number and a timestamp estimation of the packet it to know the original sequence number and a timestamp estimation of
requests. the packet it requests.
6.4 Timing rules 6.4 Timing rules
The NACK feedback message may be sent in a regular full compound The NACK feedback message may be sent in a regular full compound
RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending
NACK in an early packet allows to react more quickly to a given a NACK in an early packet allows to react more quickly to a given
packet loss. However, in that case if a new packet loss occurs packet loss. However, in that case if a new packet loss occurs
right after the early RTCP packet was sent, the receiver will then right after the early RTCP packet was sent, the receiver will then
have to wait for the next regular RTCP compound packet after the have to wait for the next regular RTCP compound packet after the
early packet. Sending NACKs only in regular RTCP compound decreases early packet. Sending NACKs only in regular RTCP compound
the maximum delay between detecting an original packet loss and decreases the maximum delay between detecting an original packet
being able to send a NACK for that packet. Implementers should loss and being able to send a NACK for that packet. Implementers
consider the possible implications of this fact for the application should consider the possible implications of this fact for the
being used. application being used.
Furthermore, receivers may make use of the minimum interval between Furthermore, receivers may make use of the minimum interval
regular RTCP compound packets. This interval can be used to keep between regular RTCP compound packets. This interval can be used
regular receiver reporting down to a minimum, while still allowing to keep regular receiver reporting down to a minimum, while still
receivers to send early RTCP packets during periods requiring more allowing receivers to send early RTCP packets during periods
frequent feedback, e.g. times of higher packet loss rate.. Note requiring more frequent feedback, e.g. times of higher packet loss
that although RTCP packets may be suppressed because they do not rate.. Note that although RTCP packets may be suppressed because
contain NACKs, the same RTCP bandwidth as if they were sent needs to they do not contain NACKs, the same RTCP bandwidth as if they were
be available. See AVPF [1] for details on the use of the minimum sent needs to be available. See AVPF [1] for details on the use
interval. of the minimum interval.
7. Congestion control 7. Congestion control
RTP retransmission poses a risk of increasing network congestion. RTP retransmission poses a risk of increasing network congestion.
In a best-effort environment, packet loss is caused by congestion. In 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
the rate of the original stream would thus further increase decreasing the rate of the original stream would thus further
congestion. Implementations SHOULD follow the recommendations below increase congestion. Implementations SHOULD follow the
in order to use retransmission. recommendations below 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
order to be fair to other TCP or RTP flows. in 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
This guarantees that an application using retransmission achieves data. This guarantees that an application using retransmission
the same fairness as one that does not. Such a rule would translate achieves the same fairness as one that does not. Such a rule
in practice into the following actions: would translate in practice into the following actions:
If enhanced service is used, it should be made sure that the total If enhanced service is used, it should be made sure that the total
bitrate and packet rate do not exceed that of the requested service. bitrate and packet rate do not exceed that of the requested
It should be further monitored that the requested services are service. It should be further monitored that the requested
actually delivered. In a best-effort environment, the sender SHOULD services are actually delivered. In a best-effort environment,
NOT send retransmission packets without reducing the packet rate and the sender SHOULD NOT send retransmission packets without reducing
bitrate of the original stream (for example by encoding the data at the packet rate and bitrate of the original stream (for example by
a lower rate). encoding the data at a lower rate).
In addition, the sender MAY selectively retransmit only the packets In addition, the sender MAY selectively retransmit only the
that it deems important and ignore NACK messages for other packets packets that it deems important and ignore NACK messages for other
in order to limit the bitrate. packets 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
within acceptable parameters. Packet loss is considered acceptable rate within acceptable parameters. Packet loss is considered
if a TCP flow across the same network path and experiencing the same acceptable if a TCP flow across the same network path and
network conditions would achieve, on a reasonable timescale, an experiencing the same network conditions would achieve, on a
average throughput, that is not less than the one the RTP flow reasonable timescale, an average throughput, that is not less than
achieves. If the packet loss rate exceeds an acceptable level, it the one the RTP flow achieves. If the packet loss rate exceeds an
should be concluded that congestion is not kept under control and acceptable level, it should be concluded that congestion is not
retransmission should then not be used. It may further be necessary kept under control and retransmission should then not be used. It
to adapt the transmission rate (or the number of layers subscribed may further be necessary to adapt the transmission rate (or the
for a layered multicast session), or to arrange for the receiver to number of layers subscribed for a layered multicast session), or
leave the session. to arrange for the receiver to leave the session.
8. Retransmission Payload Format MIME type registration 8. Retransmission Payload Format MIME type registration
8.1 Introduction 8.1 Introduction
The following MIME subtype name and parameters are introduced in The following MIME subtype name and parameters are introduced in
this document: "rtx", "rtx-time" and "apt". this 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". used in the binding is "rtx".
The "apt" (associated payload type) parameter MUST be used to map The "apt" (associated payload type) parameter MUST be used to map
the retransmission payload type to the associated original stream the retransmission payload type to the associated original stream
payload type. If multiple payload types are used for the original payload type. If multiple original payload types are used, then
streams, then multiple "apt" parameters MUST be included to map each multiple "apt" parameters MUST be included to map each original
original stream payload type to a different retransmission payload payload type to a different retransmission payload type.
type.
An OPTIONAL payload-format-specific parameter, "rtx-time," indicates An OPTIONAL payload-format-specific parameter, "rtx-time",
the maximum time a server will try to retransmit a packet. indicates the maximum time a sender will keep an original RTP
packet in its buffers available for retransmission. This time
starts with the first transmission of the packet.
The syntax is as follows: The syntax is as follows:
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val> a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
where, where,
<number>: indicates the dynamic payload type number assigned to <number>: indicates the dynamic payload type number assigned
the retransmission payload format in an rtpmap attribute. to the retransmission payload format in an rtpmap attribute.
<apt-value>: the value of the original stream payload type to <apt-value>: the value of the original stream payload type to
which this retransmission stream payload type is associated. which this retransmission stream payload type is associated.
<rtx-time-val>: indicates the time in milliseconds, measured <rtx-time-val>: specifies 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) that a sender keeps an
will stop trying to retransmit the packet. The absence of the RTP packet in its buffers available for retransmission. The
rtx-time parameter for a retransmission stream means that the absence of the rtx-time parameter for a retransmission stream
maximum retransmission time is not defined, but MAY be means that the maximum retransmission time is not defined,
negotiated by other means. but MAY be negotiated by other means.
8.2 Registration of audio/rtx 8.2 Registration of audio/rtx
MIME type: audio MIME type: audio
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp rate: the RTP timestamp clockrate is equal to the RTP
clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is apt: associated payload type. The value of this parameter is
the payload type of the associated original stream. the payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the rtx-time: indicates the time in milliseconds (measured from
time a packet was first sent until the time the server will the time a packet was first sent) that the sender keeps an
stop trying to retransmit the packet. RTP packet in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer
RTP. via RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
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
skipping to change at page 14, line 51 skipping to change at page 15, line 14
IETF AVT WG IETF AVT WG
8.3 Registration of video/rtx 8.3 Registration of video/rtx
MIME type: video MIME type: video
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp rate: the RTP timestamp clockrate is equal to the RTP
clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is apt: associated payload type. The value of this parameter is
the payload type of the associated original stream. the payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the rtx-time: indicates the time in milliseconds (measured from
time a packet was first sent until the time the server will the time a packet was first sent) that the sender keeps an
stop trying to retransmit the packet. RTP packet in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer
RTP. via RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
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
skipping to change at page 15, line 42 skipping to change at page 16, line 4
Author/Change controller: Author/Change controller:
Jose Rey Jose Rey
David Leon David Leon
IETF AVT WG IETF AVT WG
8.4 Registration of text/rtx 8.4 Registration of text/rtx
MIME type: text MIME type: text
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp rate: the RTP timestamp clockrate is equal to the RTP
clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is apt: associated payload type. The value of this parameter is
the payload type of the associated original stream. the payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the rtx-time: indicates the time in milliseconds (measured from
time a packet was first sent until the time the server will the time a packet was first sent) that the sender keeps an
stop trying to retransmit the packet. RTP packet in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer
RTP. via RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
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
skipping to change at page 16, line 39 skipping to change at page 16, line 52
IETF AVT WG IETF AVT WG
8.5 Registration of application/rtx 8.5 Registration of application/rtx
MIME type: application MIME type: application
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp rate: the RTP timestamp clockrate is equal to the RTP
clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is apt: associated payload type. The value of this parameter is
the payload type of the associated original stream. the payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds, measured from the rtx-time: indicates the time in milliseconds (measured from
time a packet was first sent until the time the server will the time a packet was first sent) that the sender keeps an
stop trying to retransmit the packet. RTP packet in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via Encoding considerations: this type is only defined for transfer
RTP. via RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC XXXX
Interoperability considerations: none Interoperability considerations: none
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
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
skipping to change at page 17, line 27 skipping to change at page 17, line 44
Author/Change controller: Author/Change controller:
Jose Rey Jose Rey
David Leon David Leon
IETF AVT WG IETF AVT WG
8.6 Mapping to SDP 8.6 Mapping to 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 used to specify retransmissions describe RTP sessions. When SDP is used to specify
for an RTP stream, the mapping is done as follows: retransmissions for an RTP stream, the mapping is done as
follows:
- The MIME types ("video"), ("audio"), ("text") and ("application") - The MIME types ("video"), ("audio"), ("text") and
go in the SDP "m=" as the media name. ("application") go in the SDP "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 on this. retransmission payload type. See Section 4 for details 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" are used for several types of "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types
feedback. See the AVPF profile [1] for details. of 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 of "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list 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 semicolon copying them directly from the MIME media type string as a
separated list of parameter=value pairs. semicolon separated list of parameter=value pairs.
In the following sections some example SDP descriptions are In the following sections some example SDP descriptions are
presented. presented. In some of these examples, long lines are folded to
meet the column width constraints of this document; the backslash
("\") at the end of a line and the carriage return that follows it
should be ignored.
8.7 SDP description with session-multiplexing 8.7 SDP description with session-multiplexing
In the case of session-multiplexing, the SDP description contains In the case of session-multiplexing, the SDP description contains
one media specification "m" line per RTP session. The SDP MUST one media specification "m" line per RTP session. The SDP MUST
provide the grouping of the original and associated retransmission provide the grouping of the original and associated retransmission
sessions' "m" lines, using the Flow Identification (FID) semantics sessions' "m" lines, using the Flow Identification (FID) semantics
defined in RFC 3388 [6]. defined in RFC 3388 [6].
The following example specifies two original, AMR and MPEG-4, The following example specifies two original, AMR and MPEG-4,
skipping to change at page 18, line 29 skipping to change at page 18, line 52
a=fmtp:96 octet-align=1 a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=mid:1 a=mid:1
m=audio 49172 RTP/AVPF 97 m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000 a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
a=mid:2 a=mid:2
m=video 49174 RTP/AVPF 98 m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=mid:3 a=mid:3
m=video 49176 RTP/AVPF 99 m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000 a=fmtp:99 apt=98;rtx-time=3000
a=mid:4 a=mid:4
A special case of the SDP description is a description that contains A special case of the SDP description is a description that
only one original session "m" line and one retransmission session contains only one original session "m" line and one retransmission
"m" line, the grouping is then obvious and FID semantics MAY be session "m" line, the grouping is then obvious and FID semantics
omitted in this special case only. MAY be 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:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0 c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
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=01010000012000884006682C209\
0A21F
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.8 SDP description with SSRC-multiplexing 8.8 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
session using SSRC-multiplexing with similar parameters as in the session using SSRC-multiplexing with similar parameters as in the
single-session example above: single-session example above:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0 c=IN IP4 192.0.2.0
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=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
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 with real-time properties. This section looks at the issues
involved in controlling RTP sessions that use retransmissions. involved in controlling RTP sessions that use retransmissions.
9.1 RTSP control with SSRC-multiplexing 9.1 RTSP control with SSRC-multiplexing
In the case of SSRC-multiplexing, the "m" line includes both In the case of SSRC-multiplexing, the "m" line includes both
original and retransmission payload types and has a single RTSP original and retransmission payload types and has a single RTSP
"control" attribute. The receiver uses the "m" line to request "control" attribute. The receiver uses the "m" line to request
SETUP and TEARDOWN of the whole media session. The RTP profile SETUP and TEARDOWN of the whole media session. The RTP profile
contained in the transport header MUST be the AVPF profile or contained in the Transport header MUST be the AVPF profile or
another suitable profile allowing extended feedback. another suitable profile allowing extended feedback. If the SSRC
value is included in the SETUP response's Transport header, it
MUST be that of the original stream.
In order to control the sending of the session original media In order to control the sending of the session original media
stream, the receiver sends as usual PLAY and PAUSE requests to the stream, the receiver sends as usual PLAY and PAUSE requests to the
sender for the session. The RTP-info header that is used to set sender for the session. The RTP-info header that is used to set
RTP-specific parameters in the PLAY response MUST be set according RTP-specific parameters in the PLAY response MUST be set according
to the RTP information of the original stream. to the RTP information of the original stream.
When the receiver starts receiving the original stream, it can then When the receiver starts receiving the original stream, it can
request retransmission through RTCP NACKs without additional RTSP then request retransmission through RTCP NACKs without additional
signalling. 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 has an RTSP In the case of session-multiplexing, each SDP "m" line has an RTSP
"control" attribute. Hence, when retransmission is used, both the "control" attribute. Hence, when retransmission is used, both the
original session and the retransmission have their own "control" original session and the retransmission have their own "control"
attributes. The receiver can associate the original session and the attributes. The receiver can associate the original session and
retransmission session through the FID semantics as specified in the retransmission session through the FID semantics as specified
Section 8. in Section 8.
The original and the retransmission streams are set up and torn down The original and the retransmission streams are set up and torn
separately through their respective media "control" attribute. The down separately through their respective media "control"
RTP profile contained in the transport header MUST be the AVPF attribute. The RTP profile contained in the Transport header MUST
profile or another suitable profile allowing extended feedback for be the AVPF profile or another suitable profile allowing extended
both the original and the retransmission session. feedback for both the original and the retransmission session.
The RTSP presentation SHOULD support aggregate control and SHOULD The RTSP presentation SHOULD support aggregate control and SHOULD
contain a session level RTSP URL. The receiver SHOULD use aggregate contain a session level RTSP URL. The receiver SHOULD use
control for an original session and its associated retransmission aggregate control for an original session and its associated
session. Otherwise, there would need to be two different 'session- retransmission session. Otherwise, there would need to be two
id' values, i.e. different values for the original and different 'session-id' values, i.e. different values for the
retransmission sessions, and the sender would not know how to original and retransmission sessions, and the sender would not
associate them. know how to associate them.
The session-level "control" attribute is then used as usual to The session-level "control" attribute is then used as usual to
control the playing of the original stream. When the receiver control the playing of the original stream. When the receiver
starts receiving the original stream, it can then request starts receiving the original stream, it can then request
retransmissions through RTCP without additional RTSP signalling. retransmissions through RTCP without additional RTSP signalling.
9.3 RTSP control of the retransmission stream 9.3 RTSP control of the retransmission stream
Because of the nature of retransmissions, the sending of Because of the nature of retransmissions, the sending of
retransmission packets SHOULD NOT be controlled through RTSP PLAY retransmission packets SHOULD NOT be controlled through RTSP PLAY
skipping to change at page 20, line 41 skipping to change at page 21, line 13
state. state.
9.4 Cache control 9.4 Cache control
Retransmission streams SHOULD NOT be cached. Retransmission streams SHOULD NOT be cached.
In the case of session-multiplexing, the "Cache-Control" header In the case of session-multiplexing, the "Cache-Control" header
SHOULD be set to "no-cache" for the retransmission stream. SHOULD be set to "no-cache" for the retransmission stream.
In the case of SSRC-multiplexing, RTSP cannot specify independent In the case of SSRC-multiplexing, RTSP cannot specify independent
caching for the retransmission stream, because there is a single "m" caching for the retransmission stream, because there is a single
line in SDP. Therefore, the implementer should take this fact into "m" line in SDP. Therefore, the implementer should take this fact
account when deciding whether to cache an SSRC-multiplexed session into account when deciding whether to cache an SSRC-multiplexed
or not. session or not.
10. Implementation examples 10. Implementation examples
This document mandates only the sender and receiver behaviours that This document mandates only the sender and receiver behaviours
are necessary for interoperability. In addition, certain algorithms, that are necessary for interoperability. In addition, certain
such as rate control or buffer management when targeted at specific algorithms, such as rate control or buffer management when
environments, may enhance the retransmission efficiency. 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 describes a minimal receiver implementation. With The first example describes a minimal receiver implementation.
this implementation, it is possible to retransmit lost RTP packets, With this implementation, it is possible to retransmit lost RTP
detect efficiently the loss of retransmissions and perform multiple packets, detect efficiently the loss of retransmissions and
retransmissions, if needed. Most of the necessary processing is done perform multiple retransmissions, if needed. Most of the
at the server. necessary processing is done at the server.
The second example shows how a receiver may implement additional The second example shows how a receiver may implement additional
enhancements that might help reduce sender buffer requirements and enhancements that might help reduce sender buffer requirements and
optimise the retransmission efficiency optimise the retransmission efficiency
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 that retransmissions and layered encoding may be illustrates that retransmissions and layered encoding may be
complementary techniques. complementary techniques.
10.1 A minimal receiver implementation example 10.1 A minimal receiver implementation example
This section gives an example of an implementation supporting This section gives an example of an implementation supporting
multiple retransmissions. The sender transmits the original data in multiple retransmissions. The sender transmits the original data
RTP packets using the MPEG-4 video RTP payload format. in RTP packets using the MPEG-4 video RTP payload format.
It is assumed that NACK feedback messages are used, as per It is assumed that 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:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0 c=IN IP4 192.0.2.0
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=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" indicates that the server The format-specific parameter "rtx-time" indicates that the server
will buffer the sent packets in a retransmission buffer for 3.0 will buffer the sent packets in a retransmission buffer for 3.0
seconds, after which the packets are deleted from the retransmission seconds, after which the packets are deleted from the
buffer and will never be sent again. 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
to handle retransmission is kept to a minimum. The receiver detects processing to handle retransmission is kept to a minimum. The
packet loss from the gaps observed in the received sequence numbers. receiver detects packet loss from the gaps observed in the
It signals lost packets to the sender through NACKs as defined in the received sequence numbers. It signals lost packets to the sender
AVPF profile [1]. The receiver should take into account the through NACKs as defined in the AVPF profile [1]. The receiver
signalled sender retransmission buffer length in order to dimension should take into account the signalled sender retransmission
its own reception buffer. It should also derive from the buffer buffer length in order to dimension its own reception buffer. It
length the maximum number of times the retransmission of a packet can should also derive from the buffer length the maximum number of
be requested. times the 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
choose whether to retransmit a requested packet depending on the should choose whether to retransmit a requested packet depending
packet importance, the observed QoS and congestion state of the on the packet importance, the observed QoS and congestion state of
network connection to the receiver. Obviously, the sender processing the network connection to the receiver. Obviously, the sender
increases with the number of receivers as state information and processing increases with the number of receivers as state
processing load must be allocated to each receiver. information and processing load must be allocated to each
receiver.
10.2 An enhanced receiver implementation example 10.2 An enhanced receiver implementation example
The receiver may have more accurate information than the sender about The receiver may have more accurate information than the sender
the current network QoS such as available bandwidth, packet loss about the current network QoS such as available bandwidth, packet
rate, delay and jitter. In addition, other receiver-specific loss rate, delay and jitter. In addition, other receiver-specific
parameters such as buffer level, estimated importance of the lost parameters such as buffer level, estimated importance of the lost
packet and application level QoS may be used by the receiver to make packet and application level QoS may be used by the receiver to
a more efficient use of RTP retransmission by selectively sending make a more efficient use of RTP retransmission by selectively
NACKs for important lost packets and not for others. For example, a sending NACKs for important lost packets and not for others. For
receiver may decide to suppress a request for a packet loss that example, a receiver may decide to suppress a request for a packet
could be concealed locally, or for a retransmission that would arrive loss that could be concealed locally, or for a retransmission that
late. would arrive late.
Furthermore, a receiver may acknowledge the received packets. This Furthermore, a receiver may acknowledge the received packets.
can be done by sending ACKs, as per [1]. Upon receiving an ACK, the This can be done by sending ACKs, as per [1]. Upon receiving an
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 increase in the required RTCP bandwidth as long as ACK limited increase in the required RTCP bandwidth as long as ACK
packets are sent seldom enough. packets are sent seldom enough.
This implementation may help reduce buffer requirements at the sender This implementation may help reduce buffer requirements at the
and optimise the performance of the implementation by using selective sender and optimise the performance of the implementation by using
requests. selective requests.
Note that these receiver enhancements do not need to be negotiated as Note that these receiver enhancements do not need to be negotiated
they do not affect the sender implementation. However, in order to as they do not affect the sender implementation. However, in
allow the receiver to acknowledge packets, it is needed to allow the order to allow the receiver to acknowledge packets, it is needed
use of ACKs in the SDP description, by means of an additional SDP to allow the use of ACKs in the SDP description, by means of an
"a=rtcp-fb" line, as follows: additional SDP "a=rtcp-fb" line, as follows:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0 c=IN IP4 192.0.2.0
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 Retransmission of Layered Encoded Media in Multicast 10.3 Retransmission of Layered Encoded Media in Multicast
This section shows how to combine retransmissions with layered This section shows how to combine retransmissions with layered
encoding in multicast sessions. Note that the retransmission encoding in multicast sessions. Note that the retransmission
framework is not intended as a complete solution to reliable framework is not intended as a complete solution to reliable
multicast. Refer to RFC 2887 [10], for an overview of the problems multicast. Refer to RFC 2887 [10], for an overview of the
related with reliable multicast transmission. problems related with reliable multicast transmission.
Packets of different importance are sent in different RTP sessions. Packets of different importance are sent in different RTP
The retransmission streams corresponding to the different layers can sessions. The retransmission streams corresponding to the
themselves be seen as different retransmission layers. The relative different layers can themselves be seen as different
importance of the different retransmission streams should reflect the retransmission layers. The relative importance of the different
relative importance of the different original streams. retransmission streams should reflect the relative importance of
the different original streams.
In multicast, SSRC-multiplexing of the original and retransmission In multicast, SSRC-multiplexing of the original and retransmission
streams is not allowed as per Section 5.3 of this document. For this streams is not allowed as per Section 5.3 of this document. For
reason, the retransmission stream(s) MUST be sent in different RTP this reason, the retransmission stream(s) MUST be sent in
session(s) using session-multiplexing. different RTP session(s) using session-multiplexing.
An SDP description example of multicast retransmissions for layered An SDP description example of multicast retransmissions for
encoded media is given below: layered encoded media is given below:
m=video 8000 RTP/AVPF 98 m=video 8000 RTP/AVPF 98
c=IN IP4 192.0.2.0/127/3 c=IN IP4 192.0.2.0/127/3
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99 m=video 8000 RTP/AVPF 99
c=IN IP4 192.0.2.4/127/3 c=IN IP4 192.0.2.4/127/3
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000 a=fmtp:99 apt=98;rtx-time=3000
The server and the receiver may implement the retransmission methods The server and the receiver may implement the retransmission
illustrated in the previous examples. In addition, they may choose methods illustrated in the previous examples. In addition, they
to request and retransmit a lost packet depending on the layer it may choose to request and retransmit a lost packet depending on
belongs to. the layer it belongs to.
11. IANA considerations 11. IANA considerations
A new MIME subtype name, "rtx", has been registered for four A new MIME subtype name, "rtx", has been registered for four
different media types, as follows: "video", "audio", "text" and different media types, as follows: "video", "audio", "text" and
"application". An additional REQUIRED parameter, "apt", and an "application". An additional REQUIRED parameter, "apt", and an
OPTIONAL parameter, "rtx-time", are defined. See Section 8 for OPTIONAL parameter, "rtx-time", are defined. See Section 8 for
details. details.
12. Security considerations 12. Security considerations
If cryptography is used to provide security services on the original If cryptography is used to provide security services on the
stream, then the same services, with equivalent cryptographic original stream, then the same services, with equivalent
strength, MUST be provided on the retransmission stream. Old keys cryptographic strength, MUST be provided on the retransmission
will likely need to be cached so that when the keys change for the stream. Old keys will likely need to be cached so that when the
original stream, the old key is used until it is determined that the keys change for the original stream, the old key is used until it
key has changed on the retransmission packets as well. is determined that the key has changed on the retransmission
packets as well.
The use of the same key for the retransmitted stream and the The use of the same key for the retransmitted stream and the
original stream may lead to security problems, e.g. two-time pads. original stream may lead to security problems, e.g. two-time pads.
This sharing has to be evaluated towards the chosen security This sharing has to be evaluated towards the chosen security
protocol and security algorithms. protocol and security algorithms.
RTP recommends that the initial RTP timestamp SHOULD be random to Furthermore, it is RECOMMENDED that the cryptography mechanisms
secure the stream against known plain text attacks. This payload used for this payload format provide protection against known
format does not follow this recommendation as the initial timestamp plaintext attacks. RTP recommends that the initial RTP timestamp
will be the media timestamp of the first retransmitted packet. SHOULD be random to secure the stream against known plaintext
attacks. This payload format does not follow this recommendation
However, since the initial timestamp of the original stream is as the initial timestamp will be the media timestamp of the first
itself random, if the original stream is encrypted, the first retransmitted packet. However, since the initial timestamp of the
retransmitted packet timestamp would also be random to an attacker. original stream is itself random, if the original stream is
Therefore, confidentiality would not be compromised. encrypted, the first retransmitted packet timestamp would also be
random to an attacker. Therefore, confidentiality would not be
compromised.
Congestion control considerations with the use of retransmission are Congestion control considerations with the use of retransmission
dealt with in Section 7 of this document. are dealt with in Section 7 of this document.
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. The retransmission retransmission scheme is used should be applied. The
payload format MUST NOT be used under the SAVP profile defined by retransmission payload format MUST NOT be used under the SAVP
the Secure Real-Time Transport Protocol (SRTP)[12] but instead an profile defined by the Secure Real-Time Transport Protocol
extension of SRTP should be defined to secure the AVPF profile. The (SRTP)[12] but instead an extension of SRTP should be defined to
definition of such a profile is out of the scope of this document. secure the AVPF profile. The definition of such a profile is out
of the scope of this document.
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
participation in the development of this document. Our thanks also his participation in the development of this document. Our thanks
go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus
Go Hori and Rahul Agarwal for their helpful comments. Westerlund, Go Hori and Rahul Agarwal for their helpful comments.
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", draft-ietf-avt-rtcp-feedback- profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback-
04.txt, September 2002. 04.txt, 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", draft-ietf-avt- Transport Protocol for Real-Time Applications", draft-ietf-avt-
rtp-new-11.txt, May 2002. rtp-new-12.txt, March 2003.
4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft-
ietf-avt-rtcp-bw-05.txt, May 2002. ietf-avt-rtcp-bw-05.txt, May 2002.
5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol",
2327, April 1998. RFC 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
in the Session Description Protocol (SDP)", RFC 3388, December lines in the Session Description Protocol (SDP)", RFC 3388,
2002. December 2002.
7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
(RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
14.2 Informative References 14.2 Informative References
8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media",
RFC 2354, June 1998. RFC 2354, June 1998.
9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000
10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 10 M. Handley, et al., "The Reliable Multicast Design Space for
Data Transfer", RFC 2887, August 2000. Bulk Data Transfer", RFC 2887, August 2000.
11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 11 Friedman, et. al., "RTP Extended Reports", Work in Progress.
12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
draft-ietf-avt-srtp-05.txt, June 2002. draft-ietf-avt-srtp-05.txt, June 2002.
13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," BCP 11, RFC 2028, IETF, October 1996. Standards Process," BCP 11, RFC 2028, IETF, October 1996.
Author's Addresses 15. 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
Nokia Research Center Nokia Research Center
skipping to change at page 26, line 14 skipping to change at page 26, line 45
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 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 in pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; neither does it represent
has made any effort to identify any such rights. Information on the that it has made any effort to identify any such rights.
IETF's procedures with respect to rights in standards-track and Information on the IETF's procedures with respect to rights in
standards-related documentation can be found in BCP 11 [13]. Copies standards-track and standards-related documentation can be found
of claims of rights made available for publication and any assurances in BCP 11 [13]. Copies of claims of rights made available for
of licenses to be made available, or the result of an attempt made to publication and any assurances of licenses to be made available,
obtain a general license or permission for the use of such or the result of an attempt made to obtain a general license or
proprietary rights by implementers or users of this specification can permission for the use of such proprietary rights by implementers
be obtained from the IETF Secretariat. or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights which may cover technology that may be required to practice proprietary rights which may cover technology that may be required
this standard. Please address the information to the IETF Executive to practice this standard. Please address the information to the
Director. IETF Executive Director.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved. "Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain it to others, and derivative works that comment on or otherwise
or assist in its implementation may be prepared, copied, published explain it or assist in its implementation may be prepared,
and distributed, in whole or in part, without restriction of any copied, published and distributed, in whole or in part, without
kind, provided that the above copyright notice and this paragraph are restriction of any kind, provided that the above copyright notice
included on all such copies and derivative works. However, this and this paragraph are included on all such copies and derivative
document itself may not be modified in any way, such as by removing works. However, this document itself may not be modified in any
the copyright notice or references to the Internet Society or other way, such as by removing the copyright notice or references to the
Internet organizations, except as needed for the purpose of Internet Society or other Internet organizations, except as needed
developing Internet standards in which case the procedures for for the purpose of developing Internet standards in which case
copyrights defined in the Internet Standards process must be the procedures for copyrights defined in the Internet Standards
followed, or as required to translate it into languages other than process must be followed, or as required to translate it into
English. languages other than English.
The limited permissions granted above are perpetual and will The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or not be revoked by the Internet Society or its successors or
assigns. assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."
 End of changes. 

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