draft-ietf-avt-rtp-retransmission-12.txt   rfc4588.txt 
Internet Draft Network Working Group J. Rey
draft-ietf-avt-rtp-retransmission- J. Rey/Panasonic Request for Comments: 4588 Panasonic
12.txt D. Leon/Nokia Category: Standards Track D. Leon
A. Miyazaki/Panasonic Consultant
V. Varsa/Nokia A. Miyazaki
R. Hakenberg/Panasonic Panasonic
V. Varsa
Expires: March 15, 2006 September 15, 2005 Nokia
R. Hakenberg
Panasonic
RTP Retransmission Payload Format RTP Retransmission Payload Format
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/1id-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
[Note to RFC Editor: This paragraph shall be deleted upon Copyright (C) The Internet Society (2006).
publication as an RFC. References in this draft to RFC 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
for real-time applications with relaxed delay bounds. This real-time applications with relaxed delay bounds. This document
document describes an RTP payload format for performing describes an RTP payload format for performing retransmissions.
retransmissions. Retransmitted RTP packets are sent in a separate Retransmitted RTP packets are sent in a separate stream from the
stream from the original RTP stream. It is assumed that feedback original RTP stream. It is assumed that feedback from receivers to
from receivers to senders is available. In particular, it is senders is available. In particular, it is assumed that Real-time
assumed that RTCP feedback as defined in the extended RTP profile Transport Control Protocol (RTCP) feedback as defined in the extended
for RTCP-based feedback (denoted RTP/AVPF), is available in this RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available
memo. 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
3.1 Multiplexing scheme choice..................................6 3.1. Multiplexing Scheme Choice .................................6
4. Retransmission payload format.................................7 4. Retransmission Payload Format ...................................7
5. Association of retransmission and original streams............9 5. Association of Retransmission and Original Streams ..............9
5.1 Retransmission session sharing..............................9 5.1. Retransmission Session Sharing .............................9
5.2 CNAME use...................................................9 5.2. CNAME Use ..................................................9
5.3 Association at the receiver.................................9 5.3. Association at the Receiver ................................9
6. Use with the extended RTP profile for RTCP-based feedback....10 6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1 RTCP at the sender.........................................11 6.1. RTCP at the Sender ........................................11
6.2 RTCP Receiver Reports......................................11 6.2. RTCP Receiver Reports .....................................11
6.3 Retransmission requests....................................11 6.3. Retransmission Requests ...................................12
6.4 Timing rules...............................................12 6.4. Timing Rules ..............................................13
7. Congestion control...........................................13 7. Congestion Control .............................................13
8. Retransmission Payload Format MIME type registration.........14 8. Retransmission Payload Format MIME Type Registration ...........15
8.1 Introduction...............................................14 8.1. Introduction ..............................................15
8.2 Registration of audio/rtx..................................15 8.2. Registration of audio/rtx .................................16
8.3 Registration of video/rtx..................................16 8.3. Registration of video/rtx .................................17
8.4 Registration of text/rtx...................................17 8.4. Registration of text/rtx ..................................18
8.5 Registration of application/rtx............................17 8.5. Registration of application/rtx ...........................19
8.6 Mapping to SDP.............................................18 8.6. Mapping to SDP ............................................20
8.7 SDP description with session-multiplexing..................19 8.7. SDP Description with Session-Multiplexing .................20
8.8 SDP description with SSRC-multiplexing.....................20 8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP considerations..........................................20 9. RTSP Considerations ............................................22
9.1 RTSP control with SSRC-multiplexing........................21 9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2 RTSP control with session-multiplexing.....................21 9.2. RTSP Control with Session-Multiplexing ....................22
9.3 RTSP control of the retransmission stream..................22 9.3. RTSP Control of the Retransmission Stream .................23
9.4 Cache control..............................................22 9.4. Cache Control .............................................23
10. Implementation examples.....................................22 10. Implementation Examples .......................................23
10.1 A minimal receiver implementation example.................22 10.1. A Minimal Receiver Implementation Example ................24
10.2 Retransmission of Layered Encoded Media in Multicast......23 10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA considerations.........................................24 11. IANA Considerations ...........................................26
12. Security considerations.....................................24 12. Security Considerations .......................................26
13. Acknowledgements............................................25 13. Acknowledgements ..............................................27
14. References..................................................25 14. References ....................................................27
14.1 Normative References......................................25 14.1. Normative References .....................................27
14.2 Informative References....................................26 14.2. Informative References ...................................28
15. Author's Addresses..........................................26 Appendix A. How to Control the Number of Rtxs. per Packet .........29
Appendix A. How to control the number of rtxs. per packet.......27
IPR Notices.....................................................31
Full Copyright Statement........................................32
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, degrade the quality of the received media. Several techniques, such
such as forward error correction (FEC), retransmissions or as forward error correction (FEC), retransmissions, or interleaving,
interleaving may be considered to increase packet loss resiliency. may be considered to increase packet loss resiliency. RFC 2354 [8]
RFC 2354 [8] discusses the different options. discusses the different options.
When choosing a repair technique for a particular application, the When choosing a repair technique for a particular application, the
tolerable latency of the application has to be taken into account. tolerable latency of the application has to be taken into account.
In the case of multimedia conferencing, the end-to-end delay has In the case of multimedia conferencing, the end-to-end delay has to
to be at most a few hundred milliseconds in order to guarantee be at most a few hundred milliseconds in order to guarantee
interactivity, which usually excludes the use of retransmission. interactivity, which usually excludes the use of retransmission.
With sufficient latency, the efficiency of the repair scheme can With sufficient latency, the efficiency of the repair scheme can be
be increased. The sender may use the receiver feedback in increased. The sender may use the receiver feedback in order to
order to react to losses before their playout time at the react to losses before their playout time at the receiver.
receiver.
In the case of multimedia streaming, the user can tolerate an In the case of multimedia streaming, the user can tolerate an initial
initial latency as part of the session set-up and thus an end-to- latency as part of the session set-up and thus an end-to-end delay of
end delay of several seconds may be acceptable. RTP several seconds may be acceptable. RTP retransmission as defined in
retransmission as defined in this document is targeted at such this document is targeted at such applications.
applications.
Furthermore, the RTP retransmission method defined herein is Furthermore, the RTP retransmission method defined herein is
applicable to unicast and (small) multicast groups. The present applicable to unicast and (small) multicast groups. The present
document defines a payload format for retransmitted RTP packets document defines a payload format for retransmitted RTP packets and
and provides protocol rules for the sender and the receiver provides protocol rules for the sender and the receiver involved in
involved in retransmissions. retransmissions.
This retransmission payload format was designed for use with the This retransmission payload format was designed for use with the
extended RTP profile for RTCP-based feedback, AVPF [1]. It may extended RTP profile for RTCP-based feedback, AVPF [1]. It may also
also be used with other RTP profiles defined in the future. 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 general-purpose feedback message, i.e. feedback. It defines a general-purpose feedback message, i.e., NACK,
NACK, as well as codec and application-specific feedback messages. as well as codec and application-specific feedback messages. See [1]
See [1] for details. 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 CSRC: contributing source. See [3].
sent for the first time by an RTP sender.
Original stream: refers to the RTP stream of original packets. Original packet: an RTP packet that carries user data sent for the
first time by an RTP sender.
Retransmission packet: refers to an RTP packet which is to be used Original stream: the RTP stream of original packets.
by the receiver instead of a lost original packet. Such a
retransmission packet is said to be associated with the original
RTP packet.
Retransmission request: a means by which an RTP receiver is able Retransmission packet: an RTP packet that is to be used by the
to request that the RTP sender should send a retransmission packet receiver instead of a lost original packet. Such a retransmission
for a given original packet. Usually, an RTCP NACK packet as packet is said to be associated with the original RTP packet.
specified in [1] is used as retransmission request for lost
packets. Retransmission request: a means by which an RTP receiver is able to
request that the RTP sender should send a retransmission packet for a
given original packet. Usually, an RTCP NACK packet as specified in
[1] is used as retransmission request for lost packets.
Retransmission stream: the stream of retransmission packets 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: synchronization source. See [3].
SSRC-multiplexing: scheme by which the original stream and the SSRC-multiplexing: scheme by which the original stream and the
retransmission stream are sent in the same RTP session with retransmission stream are sent in the same RTP session with different
different SSRC values. SSRC values.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
in this document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119 [2].
[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
and where full reliability is not a requirement. More where full reliability is not a requirement. More specifically, RTP
specifically, RTP retransmission allows to trade-off reliability retransmission allows one to trade off reliability vs. delay; i.e.,
vs. delay, i.e. the endpoints may give up retransmitting a lost the endpoints may give up retransmitting a lost packet after a given
packet after a given buffering time has elapsed. Unlike TCP there buffering time has elapsed. Unlike TCP, there is thus no head-of-
is thus no head-of-line blocking caused by RTP retransmissions. line blocking caused by RTP retransmissions. The implementer should
The implementer should be aware that in cases where full be aware that in cases where full reliability is required or higher
reliability is required or higher delay and jitter can be delay and jitter can be tolerated, TCP or other transport options
tolerated, TCP or other transport options should be considered. should be considered.
The RTP retransmission scheme defined in this document is designed The RTP retransmission scheme defined in this document is designed to
to fulfil the following set of requirements: fulfill 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
packets were lost as a result of a gap in received RTP sequence were lost as a result of a gap in received RTP sequence numbers.
numbers. This requirement is referred to as sequence number This requirement is referred to as sequence number preservation.
preservation. Without such a requirement, it would be Without such a requirement, it would be impossible to use
impossible to use retransmission with payload formats, such as retransmission with payload formats, such as conversational text
conversational text [9] or most audio/video streaming [9] or most audio/video streaming applications, that use the RTP
applications, that use the RTP sequence number to detect lost sequence number to detect lost packets.
packets.
When designing a solution for RTP retransmission, several When designing a solution for RTP retransmission, several approaches
approaches may be considered for the multiplexing of the original may be considered for the multiplexing of the original RTP packets
RTP packets and the retransmitted RTP packets. and the retransmitted RTP packets.
One approach may be to retransmit the RTP packet with its original One approach may be to retransmit the RTP packet with its original
sequence number and send original and retransmission packets in sequence number and send original and retransmission packets in the
the same RTP stream. The retransmission packet would then be same RTP stream. The retransmission packet would then be identical
identical to the original RTP packet, i.e. the same header (and to the original RTP packet, i.e., the same header (and thus same
thus same sequence number) and the same payload. However, such an sequence number) and the same payload. However, such an approach is
approach is not acceptable because it would corrupt the RTCP not acceptable because it would corrupt the RTCP statistics. As a
statistics. As a consequence, requirement 1 would not be met. consequence, requirement 1 would not be met. Correct RTCP statistics
Correct RTCP statistics require that for every RTP packet within require that for every RTP packet within the RTP stream, the sequence
the RTP stream, the sequence number be increased by one. 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
payload type values. With such an approach, the original packets type values. With such an approach, the original packets and the
and the retransmission packets would share the same sequence retransmission packets would share the same sequence number space.
number space. As a result, the RTP receiver would not be able to As a result, the RTP receiver would not be able to infer how many and
infer how many and which original packets (which sequence numbers) which original packets (which sequence numbers) were lost.
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 preservation requirement (requirement 6). This in turn implies that
that requirement 4 would not be met. Interoperability with mixers requirement 4 would not be met. Interoperability with mixers and
and translators would also be more difficult if they did not translators would also be more difficult if they did not understand
understand this new retransmission payload type in a sender RTP this new retransmission payload type in a sender RTP stream. For
stream. For these reasons, a solution based on payload type these reasons, a solution based on payload type multiplexing of
multiplexing of original packets and retransmission packets in the original packets and retransmission packets in the same RTP stream is
same RTP stream is excluded. excluded.
Finally, the original and retransmission packets may be sent in Finally, the original and retransmission packets may be sent in two
two separate streams. These two streams may be multiplexed either separate streams. These two streams may be multiplexed either by
by sending them in two different sessions , i.e., session- sending them in two different sessions , i.e., session-multiplexing,
multiplexing, or in the same session using different SSRC values, or in the same session using different SSRC values, i.e., SSRC-
i.e. SSRC-multiplexing. Since original and retransmission packets multiplexing. Since original and retransmission packets carry media
carry media of the same type, the objections in Section 5.2 of RTP of the same type, the objections in Section 5.2 of RTP [3] to RTP
[3] to RTP multiplexing do not apply in this case. multiplexing do not apply in this case.
Mixers and translators may process the original stream and simply Mixers and translators may process the original stream and simply
discard the retransmission stream if they are unable to utilise discard the retransmission stream if they are unable to utilise it.
it.
On the other hand, sending the original and retransmission packets On the other hand, sending the original and retransmission packets in
in two separate streams does not alone satisfy requirements 1 and two separate streams does not alone satisfy requirements 1 and 6.
6. For this purpose, this document includes the original sequence For this purpose, this document includes the original sequence number
number in the retransmitted packets. in the retransmitted packets.
In this manner, using two separate streams satisfies all the In this manner, using two separate streams satisfies all the
requirements listed in this section. requirements listed in this section.
3.1 Multiplexing scheme choice 3.1. Multiplexing Scheme Choice
Session-multiplexing and SSRC-multiplexing have different pros and Session-multiplexing and SSRC-multiplexing have different pros and
cons: cons:
Session-multiplexing is based on sending the retransmission stream Session-multiplexing is based on sending the retransmission stream in
in a different RTP session (as defined in RTP [3]) from that of a different RTP session (as defined in RTP [3]) from that of the
the original stream, i.e. the original and retransmission streams original stream; i.e., the original and retransmission streams are
are sent to different network addresses and/or port numbers. sent to different network addresses and/or port numbers. Having a
Having a separate session allows more flexibility. In multicast, separate session allows more flexibility. In multicast, using two
using two separate sessions for the original and the separate sessions for the original and the retransmission streams
retransmission streams allows a receiver to choose whether or not allows a receiver to choose whether or not to subscribe to the RTP
to subscribe to the RTP session carrying the retransmission session carrying the retransmission stream. The original session may
stream. The original session may also be single-source multicast also be single-source multicast while separate unicast sessions are
while separate unicast sessions are used to convey retransmissions used to convey retransmissions to each of the receivers, which as a
to each of the receivers, which as a result will receive only the result will receive only the retransmission packets they request.
retransmission packets they request.
The use of separate sessions also facilitates differential The use of separate sessions also facilitates differential treatment
treatment by the network and may simplify processing in mixers, by the network and may simplify processing in mixers, translators,
translators and packet caches. and packet caches.
With SSRC-multiplexing, a single session is needed for the With SSRC-multiplexing, a single session is needed for the original
original and the retransmission stream. This allows streaming and the retransmission streams. This allows streaming servers and
servers and middleware which are involved in a high number of middleware that are involved in a high number of concurrent sessions
concurrent sessions to minimise their port usage. to minimise their port usage.
This retransmission payload format allows both session- This retransmission payload format allows both session-multiplexing
multiplexing and SSRC-multiplexing for unicast sessions. From an and SSRC-multiplexing for unicast sessions. From an implementation
implementation point of view, there is little difference between point of view, there is little difference between the two approaches.
the two approaches. Hence, in order to maximise interoperability, Hence, in order to maximise interoperability, both multiplexing
both multiplexing approaches SHOULD be supported by senders and approaches SHOULD be supported by senders and receivers. For
receivers. For multicast sessions, session-multiplexing MUST be multicast sessions, session-multiplexing MUST be used because the
used because the association of the original stream and the association of the original stream and the retransmission stream is
retransmission stream is problematic if SSRC-multiplexing is used problematic if SSRC-multiplexing is used with multicast sessions(see
with multicast sessions(see Section 5.3 for motivation). 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
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 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
used for the original stream and the retransmission stream. In for the original stream and the retransmission stream. In the case
the case of an SSRC collision in either the original session or of an SSRC collision in either the original session or the
the retransmission session, the RTP specification requires that an retransmission session, the RTP specification requires that an RTCP
RTCP BYE packet MUST be sent in the session where the collision BYE packet MUST be sent in the session where the collision happened.
happened. In addition, an RTCP BYE packet MUST also be sent for In addition, an RTCP BYE packet MUST also be sent for the associated
the associated stream in its own session. After a new SSRC stream in its own session. After a new SSRC identifier is obtained,
identifier is obtained, the SSRC of both streams MUST be set to the SSRC of both streams MUST be set to this value.
this value.
In the case of SSRC-multiplexing, two different SSRC values MUST In the case of SSRC-multiplexing, two different SSRC values MUST be
be used for the original stream and the retransmission stream as used for the original stream and the retransmission stream as
required by RTP. If an SSRC collision is detected for either the required by RTP. If an SSRC collision is detected for either the
original stream or the retransmission stream, the RTP original stream or the retransmission stream, the RTP specification
specification requires that an RTCP BYE packet MUST be sent for requires that an RTCP BYE packet MUST be sent for this stream. An
this stream. An RTCP BYE packet MUST NOT be sent for the RTCP BYE packet MUST NOT be sent for the associated stream.
associated stream. Therefore, only the stream that experienced Therefore, only the stream that experienced SSRC collision MUST
SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 choose a new SSRC value. Refer to Section 5.3 for the implications
for the implications on the original and retransmission stream on the original stream and retransmission stream SSRC association at
SSRC association at the receiver. the receiver.
For either multiplexing scheme, the sequence number has the For either multiplexing scheme, the sequence number has the standard
standard definition, i.e. it MUST be one higher than the sequence definition; i.e., it MUST be one higher than the sequence number of
number of the preceding packet sent in the retransmission stream. the preceding packet sent in the retransmission stream.
The retransmission packet timestamp MUST be set to the original The retransmission packet timestamp MUST be set to the original
timestamp, i.e. to the timestamp of the original packet. As a timestamp, i.e., to the timestamp of the original packet. As a
consequence, the initial RTP timestamp for the first packet of the consequence, the initial RTP timestamp for the first packet of the
retransmission stream is not random but equal to the original retransmission stream is not random but equal to the original
timestamp of the first packet that is retransmitted. See the timestamp of the first packet that is retransmitted. See the
security considerations section in this document for security Security Considerations section in this document for security
implications. implications.
Implementers have to be aware that the RTCP jitter value for the Implementers have to be aware that the RTCP jitter value for the
retransmission stream does not reflect the actual network jitter retransmission stream does not reflect the actual network jitter
since there could be little correlation between the time a packet since there could be little correlation between the time a packet is
is retransmitted and its original timestamp. retransmitted and its original timestamp.
The payload type is dynamic. If multiple payload types using The payload type is dynamic. If multiple payload types using
retransmission are present in the original stream, then for each retransmission are present in the original stream, then for each of
of these, a dynamic payload type MUST be mapped to the these, a dynamic payload type MUST be mapped to the retransmission
retransmission payload format. See Section 8.1 for the payload format. See Section 8.1 for the specification of how the
specification of how the mapping between original and mapping between original and retransmission payload types is done
retransmission payload types is done with SDP. with Session Description Protocol (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
payload type MUST be the same as the one used by the associated type MUST be the same as the one used by the associated original
original payload type. Therefore, if an RTP stream carries payload type. Therefore, if an RTP stream carries payload types of
payload types of different clockrates, this will also be the case different clockrates, this will also be the case for the associated
for the associated retransmission stream. Note that an RTP stream retransmission stream. Note that an RTP stream does not usually
does not usually carry payload types of different clockrates. 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
original RTP packet. The length of the retransmission payload RTP packet. The length of the retransmission payload header is 2
header is 2 octets. This payload header contains only one field, octets. This payload header contains only one field, OSN (original
OSN (original sequence number), which MUST be set to the sequence sequence number), which MUST be set to the sequence number of the
number of the associated original RTP packet. The original RTP associated original RTP packet. The original RTP packet payload,
packet payload, including any possible payload headers specific to including any possible payload headers specific to the original
the original payload type, MUST be placed right after the payload type, MUST be placed right after the retransmission payload
retransmission payload header. header.
For payload formats that support encoding at multiple rates, For payload formats that support encoding at multiple rates, instead
instead of retransmitting the same payload as the original RTP of retransmitting the same payload as the original RTP packet the
packet the sender MAY retransmit the same data encoded at a lower sender MAY retransmit the same data encoded at a lower rate. This
rate. This aims at limiting the bandwidth usage of the aims at limiting the bandwidth usage of the retransmission stream.
retransmission stream. When doing so, the sender MUST ensure that When doing so, the sender MUST ensure that the receiver will still be
the receiver will still be able to decode the payload of the able to decode the payload of the already sent original packets that
already sent original packets that might have been encoded based might have been encoded based on the payload of the lost original
on the payload of the lost original packet. In addition, if the packet. In addition, if the sender chooses to retransmit at a lower
sender chooses to retransmit at a lower rate, the values in the rate, the values in the payload header of the original RTP packet may
payload header of the original RTP packet may not longer apply to no longer apply to the retransmission packet and may need to be
the retransmission packet and may need to be modified in the modified in the retransmission packet to reflect the change in rate.
retransmission packet to reflect the change in rate. The sender The sender SHOULD trade off the decrease in bandwidth usage with the
SHOULD trade-off the decrease in bandwidth usage with the decrease decrease in quality caused by resending at a lower rate.
in quality caused by resending at a lower rate.
If the original RTP header carried any profile-specific If the original RTP header carried any profile-specific extensions,
extensions, the retransmission packet SHOULD include the same the retransmission packet SHOULD include the same extensions
extensions immediately following the fixed RTP header as expected immediately following the fixed RTP header as expected by
by applications running under this profile. In this case, the applications running under this profile. In this case, the
retransmission payload header MUST be placed after the profile- retransmission payload header MUST be placed after the profile-
specific extensions. specific extensions.
If the original RTP header carried an RTP header extension, the If the original RTP header carried an RTP header extension, the
retransmission packet SHOULD carry the same header extension. retransmission packet SHOULD carry the same header extension. This
This header extension MUST be placed right after the fixed RTP header extension MUST be placed right after the fixed RTP header, as
header, as specified in RTP [3]. In this case, the retransmission specified in RTP [3]. In this case, the retransmission payload
payload header MUST be placed after the header extension. header MUST be placed after the header extension.
If the original RTP packet contained RTP padding, that padding If the original RTP packet contained RTP padding, that padding MUST
MUST be removed before constructing the retransmission packet. If be removed before constructing the retransmission packet. If padding
padding of the retransmission packet is needed, padding MUST be of the retransmission packet is needed, padding MUST be performed as
performed as with any RTP packets and the padding bit MUST be set. with any RTP packets and the padding bit MUST be set.
The marker bit (M), the CSRC count (CC) and the CSRC list of the The marker bit (M), the CSRC count (CC), and the CSRC list of the
original RTP header MUST be copied "as is" into the RTP header of original RTP header MUST be copied "as is" into the RTP header of the
the retransmission packet. retransmission packet.
5. Association of retransmission and original streams 5. Association of Retransmission and Original Streams
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
problem for receivers, since they would receive retransmissions for receivers, since they would receive retransmissions for original
for original sessions they might not have joined. For example, a sessions they might not have joined. For example, a receiver wishing
receiver wishing to receive only audio would receive also to receive only audio would receive also retransmitted video packets
retransmitted video packets if an audio and video session shared if an audio and video session shared the 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, In both the session-multiplexing and the SSRC-multiplexing cases, a
a sender MUST use the same CNAME [3] for an original stream and sender MUST use the same RTCP CNAME [3] for an original stream and
its associated retransmission stream. its 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 several media streams may have the same payload type value. The two
two sessions are themselves associated out-of-band. See Section 8 sessions are themselves associated out-of-band. See Section 8 for
for how the grouping of the two sessions is done with SDP. how the grouping of the two sessions is done with SDP.
If SSRC-multiplexing is used, the receiver should first of all If SSRC-multiplexing is used, the receiver should first of all look
look for two streams that have the same CNAME in the session. In for two streams that have the same CNAME in the session. In some
some cases, the CNAME may not be enough to determine the cases, the CNAME may not be enough to determine the association as
association as multiple original streams in the same session may multiple original streams in the same session may share the same
share the same CNAME. For example, there can be in the same video CNAME. For example, there can be in the same video session multiple
session multiple video streams mapping to different SSRCs and video streams mapping to different SSRCs and still using the same
still using the same CNAME and possibly the same PT values. Each CNAME and possibly the same payload type (PT) values. Each (or some)
(or some) of these streams may have an associated retransmission of these streams may have an associated retransmission stream.
stream.
In this case, in order to find out the association between In this case, in order to find out the association between original
original and retransmission streams having the same CNAME, the and retransmission streams having the same CNAME, the receiver SHOULD
receiver SHOULD behave as follows. behave as follows.
The association can generally be resolved when the receiver The association can generally be resolved when the receiver receives
receives a retransmission packet matching a retransmission request a retransmission packet matching a retransmission request that had
which had been sent earlier. Upon reception of a retransmission been sent earlier. Upon reception of a retransmission packet whose
packet whose original sequence number has been previously original sequence number has been previously requested, the receiver
requested, the receiver can derive that the SSRC of the can derive that the SSRC of the retransmission packet is associated
retransmission packet is associated to the sender SSRC from which to the sender SSRC from which the packet was requested.
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 original streams of the session. Note that since the initial packet
packet sequence numbers are random, the probability of having two 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
unicast case, the receiver MUST NOT have two outstanding requests case, the receiver MUST NOT have two outstanding requests for the
for the same packet sequence number in two different original same packet sequence number in two different original streams before
streams before the association is resolved. In multicast, this the association is resolved. In multicast, this ambiguity cannot be
ambiguity cannot be completely avoided, because another receiver completely avoided, because another receiver may have requested the
may have requested the same sequence number from another stream. same sequence number from another stream. Therefore, SSRC-
Therefore, SSRC-multiplexing MUST NOT be used in multicast multiplexing MUST NOT be used in multicast sessions.
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
or if it receives an RTCP BYE packet, it MUST stop requesting 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
format with the extended RTP profile for RTCP-based feedback, with the extended RTP profile for RTCP-based feedback, denoted AVPF
denoted AVPF [1]. Note that the general RTCP send and receive [1]. Note that the general RTCP send and receive rules and the RTCP
rules and the RTCP packet format as specified in RTP apply, except packet format as specified in RTP apply, except for the changes that
for the changes that the AVPF profile introduces. In short, the the AVPF profile introduces. In short, the AVPF profile relaxes the
AVPF profile relaxes the RTCP timing rules and specifies RTCP timing rules and specifies additional general-purpose RTCP
additional general-purpose RTCP feedback messages. See [1] for feedback messages. See [1] for details.
details.
6.1 RTCP at the sender 6.1. RTCP at the Sender
In the case of session-multiplexing, Sender Report (SR) packets In the case of session-multiplexing, Sender Report (SR) packets for
for the original stream are sent in the original session and SR the original stream are sent in the original session and SR packets
packets for the retransmission stream are sent in the for the retransmission stream are sent in the retransmission session
retransmission session according to the rules of RTP. 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 retransmission streams are sent in the same session according to the
the rules of RTP. The original and retransmission streams are rules of RTP. The original and retransmission streams are seen, as
seen, as far the RTCP bandwidth calculation is concerned, as far as the RTCP bandwidth calculation is concerned, as independent
independent senders belonging to the same RTP session and are thus senders belonging to the same RTP session and are thus equally
equally sharing the RTCP bandwidth assigned to senders. sharing the RTCP bandwidth assigned to senders.
Note that in both cases, session- and SSRC-multiplexing, BYE Note that in both cases, session- and SSRC-multiplexing, BYE packets
packets MUST still be sent for both streams as specified in RTP. MUST still be sent for both streams as specified in RTP. In other
In other words, it is not enough to send BYE packets for the words, it is not enough to send BYE packets for the original stream
original stream only. 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]). (e.g., 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
packet since there is a single session. since there is a single session.
6.3 Retransmission requests 6.3. Retransmission Requests
The NACK feedback message format defined in the AVPF profile The NACK feedback message format defined in the AVPF profile SHOULD
SHOULD be used by receivers to send retransmission requests. be used by receivers to send retransmission requests. Whether or not
Whether a receiver chooses to request a packet or not is an a receiver chooses to request a packet is an implementation issue.
implementation issue. An actual receiver implementation should An actual receiver implementation should take into account such
take into account such factors as the tolerable application delay, factors as the tolerable application delay, the network environment,
the network environment and the media type. and the media type.
The receiver should generally assess whether the retransmitted The receiver should generally assess whether the retransmitted packet
packet would still be useful at the time it is received. The would still be useful at the time it is received. The timestamp of
timestamp of the missing packet can be estimated from the the missing packet can be estimated from the timestamps of packets
timestamps of packets preceding and/or following the sequence preceding and/or following the sequence number gap caused by the
number gap caused by the missing packet in the original stream. missing packet in the original stream. In most cases, some form of
In most cases, some form of linear estimate of the timestamp is linear estimate of the timestamp is good enough.
good enough.
Furthermore, a receiver should compute an estimate of the round- Furthermore, a receiver should compute an estimate of the round-trip
trip time (RTT) to the sender. This can be done, for example, by 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
packet after a NACK has been sent for that packet. This estimate after a NACK has been sent for that packet. This estimate may also
may also be obtained from past observations, RTCP report round- be obtained from past observations, RTCP report round-trip time if
trip time if available or any other means. A standard mechanism available, or any other means. A standard mechanism for the receiver
for the receiver to estimate the RTT is specified in RTP Extended to estimate the RTT is specified in "RTP Control Protocol Extended
Reports [11]. Reports (RTCP XR)" [11].
The receiver should not send a retransmission request as soon as The receiver should not send a retransmission request as soon as it
it detects a missing sequence number but should add some extra detects a missing sequence number but should add some extra delay to
delay to compensate for packet reordering. This extra delay may, compensate for packet reordering. This extra delay may, for example,
for example, be based on past observations of the experienced be based on past observations of the experienced packet reordering.
packet reordering. It should be noted that, in environments where It should be noted that, in environments where packet reordering is
packet reordering is rare or does not take place, e.g., if the rare or does not take place, e.g., if the underlying datalink layer
underlying datalink layer affords ordered delivery, the delay may affords ordered delivery, the delay may be extremely low or even take
be extremely low or even take the value zero. In such cases, an the value zero. In such cases, an appropriate "reorder delay"
appropriate "reorder delay" algorithm may not actually be timer- algorithm may not actually be timer based, but packet based. For
based, but packet-based. E.g., if n number of packets are example, if n number of packets are received after a gap is detected,
received after a gap is detected, then it may be assumed that the then it may be assumed that the packet was truly lost rather than out
packet was truly lost rather than out of order. This may turn out of order. This may turn out to be far easier to code on some
to be far easier to code on some platforms as a very short fixed platforms as a very short fixed FIFO packet buffer as opposed to the
FIFO packet buffer as opposed to the timer-based mechanism. timer-based mechanism.
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 sending a new NACK for a missing packet, the receiver should rely on
on a timer to be reasonably sure that the previous retransmission a timer to be reasonably sure that the previous retransmission
attempt has failed and so avoid unnecessary retransmissions. The attempt has failed and so avoid unnecessary retransmissions. The
timer value shall be based on the observed round-trip time. Both, timer value shall be based on the observed round-trip time. A static
a static or an adaptive value MAY be used. E.g.: an adaptive timer or an adaptive value MAY be used. For example, an adaptive timer
could be one that changes its value with every new request for the could be one that changes its value with every new request for the
same packet. This document does not provide any guidelines as to same packet. This document does not provide any guidelines as to how
how this adaptive value should be calculated because no this adaptive value should be calculated because no experiments have
experiments have been done to find this out. been done to find this out.
NACKs MUST be sent only for the original RTP stream. Otherwise, NACKs MUST be sent only for the original RTP stream. Otherwise, if a
if a receiver wanted to perform multiple retransmissions by receiver wanted to perform multiple retransmissions by sending a NACK
sending a NACK in the retransmission stream, it would not be able in the retransmission stream, it would not be able to know the
to know the original sequence number and a timestamp estimation of original sequence number and a timestamp estimation of the packet it
the packet it requests. requests.
Appendix A gives some guidelines as to how to control the number Appendix A gives some guidelines as to how to control the number of
of retransmissions. retransmissions.
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
RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK
a NACK in an early packet allows to react more quickly to a given in an early packet allows reacting more quickly to a given packet
packet loss. However, in that case if a new packet loss occurs loss. However, in that case if a new packet loss occurs right after
right after the early RTCP packet was sent, the receiver will then the early RTCP packet was sent, the receiver will then have to wait
have to wait for the next regular RTCP compound packet after the for the next regular RTCP compound packet after the early packet.
early packet. Sending NACKs only in regular RTCP compound Sending NACKs only in regular RTCP compound decreases the maximum
decreases the maximum delay between detecting an original packet delay between detecting an original packet loss and being able to
loss and being able to send a NACK for that packet. Implementers send a NACK for that packet. Implementers should consider the
should consider the possible implications of this fact for the possible implications of this fact for the application being used.
application being used.
Furthermore, receivers may make use of the minimum interval Furthermore, receivers may make use of the minimum interval between
between regular RTCP compound packets. This interval can be used regular RTCP compound packets. This interval can be used to keep
to keep regular receiver reporting down to a minimum, while still regular receiver reporting down to a minimum, while still allowing
allowing receivers to send early RTCP packets during periods receivers to send early RTCP packets during periods requiring more
requiring more frequent feedback, e.g. times of higher packet loss frequent feedback, e.g., times of higher packet loss rate. Note that
rate. Note that although RTCP packets may be suppressed because although RTCP packets may be suppressed because they do not contain
they do not contain NACKs, the same RTCP bandwidth as if they were NACKs, the same RTCP bandwidth as if they were sent needs to be
sent needs to be available. See AVPF [1] for details on the use available. See AVPF [1] for details on the use of the minimum
of the minimum interval. 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
In a best-effort environment, packet loss is caused by congestion. a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmission of older data without Reacting to loss by retransmission of older data without decreasing
decreasing the rate of the original stream would thus further the rate of the original stream would thus further increase
increase congestion. Implementations SHOULD follow the congestion. Implementations SHOULD follow the recommendations below
recommendations below in order to use retransmission. in order to use retransmission.
The RTP profile under which the retransmission scheme is used The RTP profile under which the retransmission scheme is used defines
defines an appropriate congestion control mechanism in different 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 application can determine its acceptable bitrate and packet rate in
in order to be fair to other TCP or RTP flows. order to be fair to other TCP or RTP flows.
If an RTP application uses retransmission, the acceptable packet If an RTP application uses retransmission, the acceptable packet rate
rate and bitrate includes both the original and retransmitted and bitrate include both the original and retransmitted data. This
data. This guarantees that an application using retransmission guarantees that an application using retransmission achieves the same
achieves the same fairness as one that does not. Such a rule fairness as one that does not. Such a rule would translate in
would translate in practice into the following actions: 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 bitrate and packet rate do not exceed that of the requested service.
service. It should be further monitored that the requested It should be further monitored that the requested services are
services are actually delivered. In a best-effort environment, actually delivered. In a best-effort environment, the sender SHOULD
the sender SHOULD NOT send retransmission packets without reducing NOT send retransmission packets without reducing the packet rate and
the packet rate and bitrate of the original stream (for example by bitrate of the original stream (for example, by encoding the data at
encoding the data at a lower rate). a lower rate).
In addition, the sender MAY selectively retransmit only the In addition, the sender MAY selectively retransmit only the packets
packets that it deems important and ignore NACK messages for other that it deems important and ignore NACK messages for other packets in
packets in order to limit the bitrate. order to limit the bitrate.
These congestion control mechanisms should keep the packet loss These congestion control mechanisms should keep the packet loss rate
rate within acceptable parameters. In the context of congestion within acceptable parameters. In the context of congestion control,
control, packet loss is considered acceptable if a TCP flow across packet loss is considered acceptable if a TCP flow across the same
the same network path and experiencing the same network conditions network path and experiencing the same network conditions would
would achieve, on a reasonable timescale, an average throughput, achieve, on a reasonable timescale, an average throughput that is not
that is not less than the one the RTP flow achieves. If congestion less than the one the RTP flow achieves. If congestion is not kept
is not kept under control, then retransmission SHOULD NOT be used. under control, then retransmission SHOULD NOT be used.
Retransmissions MAY still be sent in some cases, e. g., in Retransmissions MAY still be sent in some cases, e.g., in wireless
wireless links where packet losses are not caused by congestion, links where packet losses are not caused by congestion, if the server
if the server (or the client that makes the retransmission (or the client that makes the retransmission request) estimates that
request) estimates that a particular packet or frame is important a particular packet or frame is important to continue play out, or if
to continue play out, or if an RTSP PAUSE has been issued to allow an RTSP PAUSE has been issued to allow the buffer to fill up (RTSP
the buffer to fill up (RTSP PAUSE does not affect the sending of PAUSE does not affect the sending of retransmissions).
retransmissions.)
Finally, it may further be necessary to adapt the transmission Finally, it may further be necessary to adapt the transmission rate
rate (or the number of layers subscribed for a layered multicast (or the number of layers subscribed for a layered multicast session),
session), or to arrange for the receiver to leave the session. or 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
this document: "rtx", "rtx-time" and "apt". document: "rtx", "rtx-time", and "apt".
The binding used for the retransmission stream to the payload type The binding used for the retransmission stream to the payload type
number is indicated by an rtpmap attribute. The MIME subtype name number is indicated by an rtpmap attribute. The MIME subtype name
used in the binding is "rtx". 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
the retransmission payload type to the associated original stream retransmission payload type to the associated original stream payload
payload type. If multiple original payload types are used, then type. If multiple original payload types are used, then multiple
multiple "apt" parameters MUST be included to map each original "apt" parameters MUST be included to map each original payload type
payload type to a different retransmission payload type. to a different retransmission payload type.
An OPTIONAL payload-format-specific parameter, "rtx-time", An OPTIONAL payload-format-specific parameter, "rtx-time", indicates
indicates the maximum time a sender will keep an original RTP the maximum time a sender will keep an original RTP packet in its
packet in its buffers available for retransmission. This time buffers available for retransmission. This time starts with the
starts with the first transmission of the packet. 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,
<number>: indicates the dynamic payload type number assigned where
to the retransmission payload format in an rtpmap attribute.
<apt-value>: the value of the original stream payload type to <number>: indicates the dynamic payload type number assigned to
the retransmission payload format in an rtpmap attribute.
<apt-value>: is 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>: specifies the time in milliseconds (measured <rtx-time-val>: specifies the time in milliseconds (measured from
from the time a packet was first sent) that a sender keeps an the time a packet was first sent) that a sender keeps an RTP
RTP packet in its buffers available for retransmission. The packet in its buffers available for retransmission. The absence
absence of the rtx-time parameter for a retransmission stream of the rtx-time parameter for a retransmission stream means that
means that the maximum retransmission time is not defined, the maximum retransmission time is not defined, but MAY be
but MAY be negotiated by other means. 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 rate: the RTP timestamp clockrate is equal to the RTP timestamp
timestamp clockrate of the media that is retransmitted. 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
the payload type of the associated original stream. payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds (measured from rtx-time: indicates the time in milliseconds (measured from the
the time a packet was first sent) that the sender keeps an time a packet was first sent) that the sender keeps an RTP packet
RTP packet in its buffers available for retransmission. in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer Encoding considerations: this type is only defined for transfer via
via RTP. RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC 4588
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:
jose.rey@eu.panasonic.com jose.rey@eu.panasonic.com
david.leon@nokia.com davidleon123@yahoo.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG delegated from the IESG IETF AVT WG delegated from the IESG
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 rate: the RTP timestamp clockrate is equal to the RTP timestamp
timestamp clockrate of the media that is retransmitted. 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
the payload type of the associated original stream. payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds (measured from rtx-time: indicates the time in milliseconds (measured from the
the time a packet was first sent) that the sender keeps an time a packet was first sent) that the sender keeps an RTP packet
RTP packet in its buffers available for retransmission. in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer Encoding considerations: this type is only defined for transfer via
via RTP. RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC 4588
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:
jose.rey@eu.panasonic.com jose.rey@eu.panasonic.com
david.leon@nokia.com davidleon123@yahoo.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG delegated from the IESG IETF AVT WG delegated from the IESG
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 rate: the RTP timestamp clockrate is equal to the RTP timestamp
timestamp clockrate of the media that is retransmitted. 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
the payload type of the associated original stream. payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds (measured from rtx-time: indicates the time in milliseconds (measured from the
the time a packet was first sent) that the sender keeps an time a packet was first sent) that the sender keeps an RTP packet
RTP packet in its buffers available for retransmission. in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer Encoding considerations: this type is only defined for transfer via
via RTP. RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC 4588
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:
jose.rey@eu.panasonic.com jose.rey@eu.panasonic.com
david.leon@nokia.com davidleon123@yahoo.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG delegated from the IESG IETF AVT WG delegated from the IESG
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 rate: the RTP timestamp clockrate is equal to the RTP timestamp
timestamp clockrate of the media that is retransmitted. 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
the payload type of the associated original stream. payload type of the associated original stream.
Optional parameters: Optional parameters:
rtx-time: indicates the time in milliseconds (measured from rtx-time: indicates the time in milliseconds (measured from the
the time a packet was first sent) that the sender keeps an time a packet was first sent) that the sender keeps an RTP packet
RTP packet in its buffers available for retransmission. in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer Encoding considerations: this type is only defined for transfer via
via RTP. RTP.
Security considerations: see Section 12 of RFC XXXX Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC XXXX Published specification: RFC 4588
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:
jose.rey@eu.panasonic.com jose.rey@eu.panasonic.com
david.leon@nokia.com davidleon123@yahoo.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Authors: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller: Change controller:
IETF AVT WG delegated from the IESG IETF AVT WG delegated from the IESG
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 describe RTP sessions. When SDP is used to specify retransmissions
retransmissions for an RTP stream, the mapping is done as for an RTP stream, the mapping is done as follows:
follows:
- The MIME types ("video"), ("audio"), ("text") and - The MIME types ("video"), ("audio"), ("text"), and ("application")
("application") go in the SDP "m=" as the media name. 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 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types
of 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 copying them directly from the MIME media type string as a
semicolon 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. In some of these examples, long lines are folded to presented. In some of these examples, long lines are folded to meet
meet the column width constraints of this document; the backslash the column width constraints of this document; the backslash ("\") at
("\") at the end of a line and the carriage return that follows it the end of a line and the carriage return that follows it should be
should be ignored. 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
one media specification "m" line per RTP session. The SDP MUST media specification "m" line per RTP session. The SDP MUST provide
provide the grouping of the original and associated retransmission the grouping of the original and associated retransmission sessions'
sessions' "m" lines, using the Flow Identification (FID) semantics "m" lines, using the Flow Identification (FID) semantics defined in
defined in RFC 3388 [6]. RFC 3388 [6].
The following example specifies two original, AMR and MPEG-4, The following example specifies two original, AMR and MPEG-4, streams
streams on ports 49170 and 49174 and their corresponding on ports 49170 and 49174 and their corresponding retransmission
retransmission streams on ports 49172 and 49176, respectively: streams on ports 49172 and 49176, respectively:
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
a=group:FID 1 2 a=group:FID 1 2
a=group:FID 3 4 a=group:FID 3 4
m=audio 49170 RTP/AVPF 96 m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000 a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1 a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
skipping to change at page 20, line 13 skipping to change at page 21, line 25
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=01010000012000884006682C209\ a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F 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 A special case of the SDP description is a description that contains
contains only one original session "m" line and one retransmission only one original session "m" line and one retransmission session "m"
session "m" line, the grouping is then obvious and FID semantics line, the grouping is then obvious and FID semantics MAY be omitted
MAY be omitted in this special case only. 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
corresponding retransmission session: 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=01010000012000884006682C209\ a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F 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=01010000012000884006682C209\ a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F 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
with real-time properties. This section looks at the issues real-time properties. This section looks at the issues involved in
involved in controlling RTP sessions that use retransmissions. 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
original and retransmission payload types and has a single RTSP and retransmission payload types and has a single RTSP "control"
"control" attribute. The receiver uses the "m" line to request attribute. The receiver uses the "m" line to request SETUP and
SETUP and TEARDOWN of the whole media session. The RTP profile TEARDOWN of the whole media session. The RTP profile contained in
contained in the Transport header MUST be the AVPF profile or the Transport header MUST be the AVPF profile or another suitable
another suitable profile allowing extended feedback. If the SSRC profile allowing extended feedback. If the SSRC value is included in
value is included in the SETUP response's Transport header, it the SETUP response's Transport header, it MUST be that of the
MUST be that of the original stream. 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,
stream, the receiver sends as usual PLAY and PAUSE requests to the the receiver sends as usual PLAY and PAUSE requests to the sender for
sender for the session. The RTP-info header that is used to set the session. The RTP-info header that is used to set RTP-specific
RTP-specific parameters in the PLAY response MUST be set according parameters in the PLAY response MUST be set according to the RTP
to the RTP information of the original stream. information of the original stream.
When the receiver starts receiving the original stream, it can When the receiver starts receiving the original stream, it can then
then request retransmission through RTCP NACKs without additional request retransmission through RTCP NACKs without additional RTSP
RTSP signalling. 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 attributes. The receiver can associate the original session and the
the retransmission session through the FID semantics as specified retransmission session through the FID semantics as specified in
in Section 8. Section 8.
The original and the retransmission streams are set up and torn The original and the retransmission streams are set up and torn down
down separately through their respective media "control" separately through their respective media "control" attribute. The
attribute. The RTP profile contained in the Transport header MUST RTP profile contained in the Transport header MUST be the AVPF
be the AVPF profile or another suitable profile allowing extended profile or another suitable profile allowing extended feedback for
feedback for both the original and the retransmission session. both the original and the retransmission sessions.
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 contain a session-level RTSP URL. The receiver SHOULD use aggregate
aggregate control for an original session and its associated control for an original session and its associated retransmission
retransmission session. Otherwise, there would need to be two session. Otherwise, there would need to be two different 'session-
different 'session-id' values, i.e. different values for the id' values, i.e., different values for the original and
original and retransmission sessions, and the sender would not retransmission sessions, and the sender would not know how to
know how to associate them. 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
starts receiving the original stream, it can then request receiving the original stream, it can then request retransmissions
retransmissions through RTCP without additional RTSP signalling. 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 and
and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect the
the retransmission stream. Retransmission packets are sent upon retransmission stream. Retransmission packets are sent upon receiver
receiver requests in the original RTCP stream, regardless of the requests in the original RTCP stream, regardless of the 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 caching for the retransmission stream, because there is a single "m"
"m" line in SDP. Therefore, the implementer should take this fact line in SDP. Therefore, the implementer should take this fact into
into account when deciding whether to cache an SSRC-multiplexed account when deciding whether or not to cache an SSRC-multiplexed
session or not. session.
10. Implementation examples 10. Implementation Examples
This document mandates only the sender and receiver behaviours This document mandates only the sender and receiver behaviours that
that are necessary for interoperability. In addition, certain are necessary for interoperability. In addition, certain algorithms,
algorithms, such as rate control or buffer management when such as rate control or buffer management when targeted at specific
targeted at specific environments, may enhance the retransmission environments, may enhance the retransmission efficiency.
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. The first example describes a minimal receiver implementation. With
With this implementation, it is possible to retransmit lost RTP this implementation, it is possible to retransmit lost RTP packets,
packets, detect efficiently the loss of retransmissions and detect efficiently the loss of retransmissions, and perform multiple
perform multiple retransmissions, if needed. Most of the retransmissions, if needed. Most of the necessary processing is done
necessary processing is done at the server. at the server.
The second example shows how retransmissions may be used in The second example shows how retransmissions may be used in (small)
(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 multiple retransmissions. The sender transmits the original data in
in RTP packets using the MPEG-4 video RTP payload format. RTP packets using the MPEG-4 video RTP payload format. It is assumed
It is assumed that NACK feedback messages are used, as per that NACK feedback messages are used, as per [1]. An SDP description
[1]. An SDP description example with SSRC-multiplexing is given 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 seconds, after which the packets are deleted from the retransmission
retransmission buffer and will never be sent again. buffer and will never be sent again.
In this implementation example, the required RTP receiver In this implementation example, the required RTP receiver processing
processing to handle retransmission is kept to a minimum. The to handle retransmission is kept to a minimum. The receiver detects
receiver detects packet loss from the gaps observed in the packet loss from the gaps observed in the received sequence numbers.
received sequence numbers. It signals lost packets to the sender It signals lost packets to the sender through NACKs as defined in the
through NACKs as defined in the AVPF profile [1]. The receiver AVPF profile [1]. The receiver should take into account the
should take into account the signalled sender retransmission signalled sender retransmission buffer length in order to dimension
buffer length in order to dimension its own reception buffer. It its own reception buffer. It should also derive from the buffer
should also derive from the buffer length the maximum number of length the maximum number of times the retransmission of a packet can
times the retransmission of a packet can be requested. be requested.
The sender should retransmit the packets selectively, i.e. it The sender should retransmit the packets selectively; i.e., it should
should choose whether to retransmit a requested packet depending choose whether to retransmit a requested packet depending on the
on the packet importance, the observed QoS and congestion state of packet importance, the observed Quality of Service (QoS), and
the network connection to the receiver. Obviously, the sender congestion state of the network connection to the receiver.
processing increases with the number of receivers as state Obviously, the sender processing increases with the number of
information and processing load must be allocated to each receivers as state information and processing load must be allocated
receiver. to each receiver.
10.2 Retransmission of Layered Encoded Media in Multicast 10.2. 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 offered only for small multicast applications. Refer to
multicast. Refer to RFC 2887 [10], for an overview of the RFC 2887 [10] for a discussion of the problems of NACK implosion,
problems related with reliable multicast transmission. severe congestion caused by feedback traffic, in large-group reliable
multicast applications.
Packets of different importance are sent in different RTP Packets of different importance are sent in different RTP sessions.
sessions. The retransmission streams corresponding to the The retransmission streams corresponding to the different layers can
different layers can themselves be seen as different themselves be seen as different retransmission layers. The relative
retransmission layers. The relative importance of the different importance of the different retransmission streams should reflect the
retransmission streams should reflect the relative importance of relative importance of the different original streams.
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 streams is not allowed as per Section 5.3 of this document. For this
this reason, the retransmission stream(s) MUST be sent in reason, the retransmission stream(s) MUST be sent in different RTP
different RTP session(s) using session-multiplexing. session(s) using session-multiplexing.
An SDP description example of multicast retransmissions for An SDP description example of multicast retransmissions for layered
layered encoded media is given below: encoded media is given below:
m=video 8000 RTP/AVPF 98 m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3 c=IN IP4 224.2.1.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 224.2.1.3/127/3 c=IN IP4 224.2.1.3/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 The server and the receiver may implement the retransmission methods
methods illustrated in the previous examples. In addition, they illustrated in the previous examples. In addition, they may choose
may choose to request and retransmit a lost packet depending on to request and retransmit a lost packet depending on the layer it
the layer it belongs to. 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
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in are subject to the general security considerations discussed in RTP
RTP, Section 9. [3], Section 9.
In common streaming scenarios message authentication, data In common streaming scenarios message authentication, data integrity,
integrity, replay protection and confidentiality are desired. replay protection, and confidentiality are desired.
The absence of authentication may enable man-in-the-middle and The absence of authentication may enable man-in-the-middle and replay
replay attacks, which can be very harmful for RTP retransmission. attacks, which can be very harmful for RTP retransmission. For
For example: tampered RTCP packets may trigger inappropriate example: tampered RTCP packets may trigger inappropriate
retransmissions that effectively reduce the actual bitrate share retransmissions that effectively reduce the actual bitrate share
allocated to the original data stream, tampered RTP retransmission allocated to the original data stream, tampered RTP retransmission
packets could cause the client's decoder to crash, tampered packets could cause the client's decoder to crash, and tampered
retransmission requests may invalidate the SSRC association retransmission requests may invalidate the SSRC association mechanism
mechanism described in Section 5 of this document. On the other described in Section 5 of this document. On the other hand, replayed
hand, replayed packets could lead to false re-ordering and RTT packets could lead to false reordering and RTT measurements (required
measurements (required for the retransmission request strategy) for the retransmission request strategy) and may cause the receiver
and may cause the receiver buffer to overflow. buffer to overflow.
Further, in order to ensure confidentiality of the data, the Furthermore, in order to ensure confidentiality of the data, the
original payload data needs to be encrypted. There is actually no original payload data needs to be encrypted. There is actually no
need to encrypt the 2-byte retransmission payload header since it need to encrypt the 2-byte retransmission payload header since it
does not provide any hints about the data content. does not provide any hints about the data content.
Furthermore, it is RECOMMENDED that the cryptography mechanisms Furthermore, it is RECOMMENDED that the cryptography mechanisms used
used for this payload format provide protection against known for this payload format provide protection against known plaintext
plaintext attacks. RTP recommends that the initial RTP timestamp attacks. RTP recommends that the initial RTP timestamp SHOULD be
SHOULD be random to secure the stream against known plaintext random to secure the stream against known plaintext attacks. This
attacks. This payload format does not follow this recommendation payload format does not follow this recommendation as the initial
as the initial timestamp will be the media timestamp of the first timestamp will be the media timestamp of the first retransmitted
retransmitted packet. However, since the initial timestamp of the packet. However, since the initial timestamp of the original stream
original stream is itself random, if the original stream is is itself random, if the original stream is encrypted, the first
encrypted, the first retransmitted packet timestamp would also be retransmitted packet timestamp would also be random to an attacker.
random to an attacker. Therefore, confidentiality would not be Therefore, confidentiality would not be compromised.
compromised.
If cryptography is used to provide security services on the If cryptography is used to provide security services on the original
original stream, then the same services, with equivalent stream, then the same services, with equivalent cryptographic
cryptographic strength, MUST be provided on the retransmission strength, MUST be provided on the retransmission stream. The use of
stream. The use of the same key for the retransmitted stream and the same key for the retransmitted stream and the original stream may
the original stream may lead to security problems, e. g., two-time lead to security problems, e.g., two-time pads. Refer to Section 9.1
pads. Refer to Section 9.1 of the Secure Real-Time Transport of the Secure Real-Time Transport Protocol (SRTP) [12] for a
Protocol (SRTP)[12] for a discussion the implications of two-time discussion the implications of two-time pads and how to avoid them.
pads and how to avoid them.
At the time of writing this document, SRTP does not provide all At the time of writing this document, SRTP does not provide all the
the security services mentioned. There are, at least, two reasons security services mentioned. There are, at least, two reasons for
for this: 1) the occurrence of two-time pads and 2) the fact that this: 1) the occurrence of two-time pads and 2) the fact that this
this payload format typically works under the RTP/AVPF profile payload format typically works under the RTP/AVPF profile whereas
while SRTP only supports RTP/AVP. An adapted variant of SRTP SRTP only supports RTP/AVP. An adapted variant of SRTP shall solve
shall solve these shortcomings in the future. these shortcomings in the future.
Congestion control considerations with the use of retransmission Congestion control considerations with the use of retransmission are
are dealt with in Section 7 of this document. dealt with in Section 7 of this document.
13. Acknowledgements 13. Acknowledgements
We would like to express our gratitude to Carsten Burmeister for We would like to express our gratitude to Carsten Burmeister for his
his participation in the development of this document. Our thanks participation in the development of this document. Our thanks also
also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund,
Westerlund, Go Hori and Rahul Agarwal for their helpful comments. 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
profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback-
11.txt, August 2004.
2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, July
2003.
4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC
3556, July 2003.
5 M. Handley, V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media
lines in the Session Description Protocol (SDP)", RFC 3388,
December 2002.
7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming [1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
Protocol (RTSP)", RFC 2326, April 1998. "Extended RTP profile for Real-time Transport Control Protocol
(RTCP)-Based feedback", RFC 4585, July 2006.
14.2 Informative References [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
RFC 2354, June 1998. "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
10 M. Handley, et al., "The Reliable Multicast Design Space for [4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Bulk Data Transfer", RFC 2887, August 2000. Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
11 Friedman, et. al., "RTP Extended Reports", Work in Progress. [5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. [6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", "Grouping of Media Lines in the Session Description Protocol
RFC 3711, March 2004. (SDP)", RFC 3388, December 2002.
13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF [7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Standards Process," BCP 11, RFC 2028, IETF, October 1996. Protocol (RTSP)", RFC 2326, April 1998.
15. Author's Addresses 14.2. Informative References
Jose Rey jose.rey@eu.panasonic.com [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Panasonic R&D Center Germany GmbH Media", RFC 2354, June 1998.
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
David Leon david.leon@nokia.com [9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
Nokia Research Center RFC 4103, June 2005.
6000 Connection Drive
Irving, TX. USA
Phone: 1-972-374-1860
Akihiro Miyazaki miyazaki.akihiro@jp.panasonic.com [10] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L.,
CE Architecture Development Center and M. Luby, "The Reliable Multicast Design Space for Bulk Data
Matsushita Electric Industrial Co., Ltd. Transfer", RFC 2887, August 2000.
1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
Viktor Varsa viktor.varsa@nokia.com [11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Nokia Research Center Extended Reports (RTCP XR)", RFC 3611, November 2003.
6000 Connection Drive
Irving, TX. USA
Phone: 1-972-374-1861
Rolf Hakenberg rolf.hakenberg@eu.panasonic.com [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Panasonic R&D Center Germany GmbH Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
Monzastr. 4c 3711, March 2004.
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
Appendix A. How to control the number of rtxs. per packet Appendix A. How to Control the Number of Rtxs. per Packet
Finding out the number of retransmissions (rtxs.) per packet for Finding out the number of retransmissions (rtxs.) per packet for
achieving the best possible transmission is a difficult task. Of achieving the best possible transmission is a difficult task. Of
course, the absolute minimum should be one (1) - otherwise, do not course, the absolute minimum should be one (1); otherwise, do not use
use this payload format. Moreover, as of date of publication, the this payload format. Moreover, as of date of publication, the
authors were not aware of any studies on the number of authors were not aware of any studies on the number of
retransmissions per packet that should be used for best retransmissions per packet that should be used for best performance.
performance. To help implementers and researchers on this item, To help implementers and researchers on this item, this section
this section describes an estimate of the buffering time required describes an estimate of the buffering time required for achieving a
for achieving a given number of retransmissions. Once this time given number of retransmissions. Once this time has been calculated,
has been calculated, it can be communicated to the client via SDP it can be communicated to the client via SDP parameter "rtx-time", as
parameter "rtx-time", as defined in this document. defined in this document.
A.1. Scenario and Assumptions
Scenario and Assumptions
========================
* Streaming scenario with relaxed delay bounds. Client and server * Streaming scenario with relaxed delay bounds. Client and server
are provided with buffering space as indicated by the parameter are provided with buffering space as indicated by the parameter
"rtx-time" in SDP. "rtx-time" in SDP.
* RTP AVPF profile used with SSRC-multiplexing retransmission * RTP AVPF profile used with SSRC-multiplexing retransmission scheme:
scheme: 1 SSRC for original packets, 1 for retransmission packets. 1 SSRC for original packets, 1 for retransmission packets.
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR=0.05. * Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR=0.05.
We have senders (2) and receivers (1). Receivers and senders get We have senders (2) and receivers (1). Receivers and senders get
equally 1/3 of the RTCP bandwidth share because the proportion of equally 1/3 of the RTCP bandwidth share because the proportion of
senders is greater than 1/4 of session members. senders is greater than 1/4 of session members.
* avg-rtcp-size is approximated by 120 bytes. This is a rounded- * avg-rtcp-size is approximated by 120 bytes. This is a rounded-up
up average of 2 SRs, one for each SSRC, containing 40/8/28/32 average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes
bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a
and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.
bytes. Since senders and receivers share the RTCP bandwidth Since senders and receivers share the RTCP bandwidth equally, then
equally, then avg-rtcp-size=(157+105+105)/3=117,3~=120 bytes. The avg-rtcp-size = (157+105+105)/3 = 117.3 ~= 120 bytes. The
important characteristic of this value is that it is something important characteristic of this value is that it is something over
over 100 bytes, which seems to be a representative figure for 100 bytes, which seems to be a representative figure for typical
typical configurations. configurations.
* The profile used is AVPF [1] and Generic NACKs are used for * The profile used is AVPF [1] and Generic NACKs are used for
requesting retransmissions. This adds 16 bytes of overhead for 1 requesting retransmissions. This adds 16 bytes of overhead for 1
NACK and 4 bytes more for every additional NACK FCI field. NACK and 4 bytes more for every additional NACK Feedback Control
Information (FCI) field.
* We assume a worst-case scenario in which each packet exhausts * We assume a worst-case scenario in which each packet exhausts its
its corresponding number of available retransmissions, N, before corresponding number of available retransmissions, N, before it is
it is received. This means that if a packet may be requested for received. This means that if a packet is requested for
retransmission a maximum of 2 times, the corresponding generic retransmission a maximum of 2 times, the corresponding generic NACK
NACK report block requesting that particular packet is sent in two report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times. retransmission 10 times, then the generic NACK is sent 10 times.
This assumption makes the RTCP packet size approx. constant after This assumption makes the RTCP packet size approximately constant
N*RTCP intervals (seconds), namely to avg-rtcp-size= 120 + after N*RTCP intervals (seconds), namely, to avg-rtcp-size = 120 +
(receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver (receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver
RTCP bandwidth share is 1/3, thus avg-rtcp-size = 124 + 4*N/3. RTCP bandwidth share is 1/3; thus, avg-rtcp-size = 124 + 4*N/3.
* Two delay parameters are difficult to approximate and may be * Two delay parameters are difficult to approximate and may be
implementation-dependent. Therefore, we list them here explicitly implementation dependent. Therefore, we list them here explicitly
without assigning them a particular value: one is the packet loss without assigning them a particular value: one is the packet loss
detection time (T2) and the other feedback processing and queuing detection time (T2), and the other is feedback processing and
time for retransmissions (T5). Implementers shall assign queuing time for retransmissions (T5). Implementers shall assign
appropriate values to these two parameters . appropriate values to these two parameters .
Graphically, we have: Graphically, we have the following:
Sender Sender
+-+---------------------------------^-----\----------------- +-+---------------------------------^-----\-----------------
\ \ / \ \ \ / \
\ \ | | \ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0) SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \ \ \ / \
X \ / \ X \ / \
`. / \ `. / \
\ / \ \ / \
skipping to change at page 28, line 51 skipping to change at page 30, line 41
\ / \ \ / \
-------------V----D--------/-----------------------V-------- -------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........ T1 T2 T3 T4 T5 T1 ........
Receiver Receiver
Legend: Legend:
======= =======
DL : downlink (client->server) DL : downlink (client->server)
UL : uplink (server->client) UL : uplink (server->client)
Time unit is seconds, s. Time unit is seconds, s.
Bitrate unit is bit per second, bps. Bitrate unit is bits per second, bps.
DL transmission time : T1= physical-delay-DL + DL transmission time : T1= physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Time to detect packet loss : T2= pkt-loss-detect-time Time to detect packet loss : T2= pkt-loss-detect-time
Time to report packet loss : T3= time-to-next-rtcp-report Time to report packet loss : T3= time-to-next-rtcp-report
UL transmission time : T4= physical-delay-UL + UL transmission time : T4= physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter transmission-delay-UL + interarrival-delay-jitter
Retransmissions processing time : T5= feedback-processing-time + Retransmissions processing time : T5= feedback-processing-time +
rtx-queuing-time rtx-queuing-time
Goal A.2. Goal
====
To find an estimate of the buffering time, T(), that a streaming To find an estimate of the buffering time, T(), that a streaming
server shall use in order to enable a given number of server shall use in order to enable a given number of retransmissions
retransmissions for each packet, N. This time is approximately for each packet, N. This time is approximately equal at the server
equal at the server and at the client, if one considers that the and at the client, if one considers that the client starts buffering
client starts buffering T1 seconds later. T1 seconds later.
Solution A.3. Solution
========
First we find the value of the estimate for 1 retransmission, First, we find the value of the estimate for 1 retransmission,
T(1)=T: T(1)=T:
T = T1 + T2 + T3 + T4 + T5 T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT, Since T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5 T = RTT + T2 + T3 + T5
The worst case for T3 would be that we assume that reporting has The worst case for T3 would be that we assume that reporting has to
to wait a whole RTCP interval and that the maximum randomization wait a whole RTCP interval and that the maximum randomization factor
factor of 1.5 is applied. Therefore, after applying the of 1.5 is applied. Therefore, after applying the subsequent
subsequent compensation to avoid traffic bursts (see RTP Section compensation to avoid traffic bursts (see Appendix A.7 of RTP [3]),
A.7 [3]), we have that T3 = 1.5/1.21828*RTCP-Interval. Thus, we have that T3 = 1.5/1.21828*RTCP-Interval. Thus,
T = RTT + 1.2312*RTCP-Interval + T2 + T5 T = RTT + 1.2312*RTCP-Interval + T2 + T5
On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders + On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders +
receivers)/(RR+RS). In this scenario: sender + receivers = 3; receivers)/(RR+RS). In this scenario: sender + receivers = 3; RR+RS
RR+RS is the receiver report plus sender report bandwidth share, is the receiver report plus sender report bandwidth share, in this
in this case, equal to the default 5% of session bandwidth, bw. case, equal to the default 5% of session bandwidth, bw. We assume an
We assume an average RTCP packet size, avg-rtcp-size=120 bytes. average RTCP packet size, avg-rtcp-size = 120 bytes. Thus:
This includes Thus:
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5 T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
for 1 retransmission. for 1 retransmission.
For enabling N retransmissions, the available buffering time in a For enabling N retransmissions, the available buffering time in a
streaming server or client is streaming server or client is approximately:
approximately:
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5) T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
where, as per above, where, as per above,
avg-rtcp-size = 120 + (receiver-RTCP-bw-share=1/3)*(12 + 4*N) = avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3. = 124 + 4*N/3.
Numbers A.4. Numbers
========
If we ignore the effect of T2 and T5, i.e., assume all losses are If we ignore the effect of T2 and T5, i.e., assume that all losses
detected immediately and that there is no additional delay due to are detected immediately and that there is no additional delay due to
feedback processing or retransmission queuing, we have the feedback processing or retransmission queuing, we have the following
following buffering times for different values of N: buffering times for different values of N:
RTCP w/ several Generic NACKs; variable packet size= 124 + 4*N/3 RTCP w/ several Generic NACKs; variable packet size= 124 + 4*N/3
bytes bytes
|============|=====|======================================| |============|=====|======================================|
| RTP BW | RTT | N value | | RTP BW | RTT | N value |
|============|=====|======================================| |============|=====| 1 2 5 7 10 |
|======================================|
1,00 2,00 5,00 7,00 10,00
64000 0,05 1,21 2,44 6,28 8,97 13,18 64000 0,05 1,21 2,44 6,28 8,97 13,18
128000 0,05 0,63 1,27 3,27 4,66 6,84 128000 0,05 0,63 1,27 3,27 4,66 6,84
256000 0,05 0,34 0,68 1,76 2,50 3,67 256000 0,05 0,34 0,68 1,76 2,50 3,67
512000 0,05 0,19 0,39 1,00 1,43 2,09 512000 0,05 0,19 0,39 1,00 1,43 2,09
1024000 0,05 0,12 0,25 0,63 0,89 1,29 1024000 0,05 0,12 0,25 0,63 0,89 1,29
5000000 0,05 0,06 0,13 0,33 0,46 0,66 5000000 0,05 0,06 0,13 0,33 0,46 0,66
10000000 0,05 0,06 0,11 0,29 0,41 0,58 10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68 64000 0,2 1,36 2,74 7,03 10,02 14,68
128000 0,2 0,78 1,57 4,02 5,71 8,34 128000 0,2 0,78 1,57 4,02 5,71 8,34
skipping to change at page 30, line 47 skipping to change at page 33, line 4
5000000 0,2 0,21 0,43 1,08 1,51 2,16 5000000 0,2 0,21 0,43 1,08 1,51 2,16
10000000 0,2 0,21 0,41 1,04 1,46 2,08 10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68 64000 1 2,16 4,34 11,03 15,62 22,68
128000 1 1,58 3,17 8,02 11,31 16,34 128000 1 1,58 3,17 8,02 11,31 16,34
256000 1 1,29 2,58 6,51 9,15 13,17 256000 1 1,29 2,58 6,51 9,15 13,17
512000 1 1,14 2,29 5,75 8,08 11,59 512000 1 1,14 2,29 5,75 8,08 11,59
1024000 1 1,07 2,15 5,38 7,54 10,79 1024000 1 1,07 2,15 5,38 7,54 10,79
5000000 1 1,01 2,03 5,08 7,11 10,16 5000000 1 1,01 2,03 5,08 7,11 10,16
10000000 1 1,01 2,01 5,04 7,06 10,08 10000000 1 1,01 2,01 5,04 7,06 10,08
To quantify the error of not taking the Generic NACKS into account,
To quantify the error of not taking the Generic NACKS into we can do the same numbers, but ignoring the Generic NACK
account, we can do the same numbers, but ignoring the Generic NACK contribution, avg-rtcp-size ~= 120 bytes. As we see from below, this
contribution, avg-rtcp-size ~= 120 bytes. As we see from below, may result in a buffer estimation error of 1-1.5 seconds (5-10%) for
this may result in a buffer estimation error of 1-1.5 seconds (5- lower bandwidth values and higher number of retransmissions. This
10%) for lower bandwidth values and higher number of effect is low in this case. Nevertheless, it should be carefully
retransmissions. This effect is low in this case. Nevertheless, evaluated for the particular scenario; that is why the formula
it should be carefully evaluated for the particular scenario; that includes it.
is why the formula includes it.
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================| |============|=====|======================================|
| RTP BW | RTT | N value | | RTP BW | RTT | N value |
|============|=====|======================================| |============|=====| 1 2 5 7 10 |
1,00 2,00 5,00 7,00 10,00 |======================================|
64000 0,05 1,16 2,32 5,79 8,11 11,58 64000 0,05 1,16 2,32 5,79 8,11 11,58
128000 0,05 0,60 1,21 3,02 4,23 6,04 128000 0,05 0,60 1,21 3,02 4,23 6,04
256000 0,05 0,33 0,65 1,64 2,29 3,27 256000 0,05 0,33 0,65 1,64 2,29 3,27
512000 0,05 0,19 0,38 0,94 1,32 1,89 512000 0,05 0,19 0,38 0,94 1,32 1,89
1024000 0,05 0,12 0,24 0,60 0,83 1,19 1024000 0,05 0,12 0,24 0,60 0,83 1,19
5000000 0,05 0,06 0,13 0,32 0,45 0,64 5000000 0,05 0,06 0,13 0,32 0,45 0,64
10000000 0,05 0,06 0,11 0,29 0,40 0,57 10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08 64000 0,2 1,31 2,62 6,54 9,16 13,08
128000 0,2 0,75 1,51 3,77 5,28 7,54 128000 0,2 0,75 1,51 3,77 5,28 7,54
skipping to change at page 31, line 37 skipping to change at page 34, line 5
10000000 0,2 0,21 0,41 1,04 1,45 2,07 10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08 64000 1 2,11 4,22 10,54 14,76 21,08
128000 1 1,55 3,11 7,77 10,88 15,54 128000 1 1,55 3,11 7,77 10,88 15,54
256000 1 1,28 2,55 6,39 8,94 12,77 256000 1 1,28 2,55 6,39 8,94 12,77
512000 1 1,14 2,28 5,69 7,97 11,39 512000 1 1,14 2,28 5,69 7,97 11,39
1024000 1 1,07 2,14 5,35 7,48 10,69 1024000 1 1,07 2,14 5,35 7,48 10,69
5000000 1 1,01 2,03 5,07 7,10 10,14 5000000 1 1,01 2,03 5,07 7,10 10,14
10000000 1 1,01 2,01 5,04 7,05 10,07 10000000 1 1,01 2,01 5,04 7,05 10,07
IPR Notices Authors' Addresses
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
David Leon
Consultant
EMail: davidleon123@yahoo.com
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: miyazaki.akihiro@jp.panasonic.com
Viktor Varsa
Nokia Research Center
6000 Connection Drive
Irving, TX. USA
Phone: 1-972-374-1861
EMail: viktor.varsa@nokia.com
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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 Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this document or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to rights on the procedures with respect to rights in RFC documents can be
in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Full Copyright Statement The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Copyright (C) The Internet Society (2005). This document is Acknowledgement
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on Funding for the RFC Editor function is provided by the IETF
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Administrative Support Activity (IASA).
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
 End of changes. 245 change blocks. 
894 lines changed or deleted 879 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/