doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

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