David Leon
   Internet Draft
   draft-ietf-avt-rtp-retransmission-                 Jose Rey/Matsushita
   03.txt                                                David Leon/Nokia
                                              Akihiro Miyazaki/Matsushita
                                                       Viktor Varsa
   Document:                                                      Nokia
   draft-ietf-avt-rtp-retransmission-02.txt Varsa/Nokia
                                                Rolf Hakenberg/Matsushita

   Expires: December 2002                                     June April 2003                                      November 2002

                     RTP retransmission framework Retransmission Payload Format

   Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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." progress".

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

   [Note to RFC Editor:  This paragraph is to be deleted when this
   draft is published as an RFC.  References in this draft to RFC XXXX
   should be replaced with the RFC number assigned to this document.
   References in this draft to RFC YYYY should be replaced with the RFC
   number assigned the draft-ietf-mmusic-fid when published as RFC.
   References in this draft to RFC ZZZZ should be replaced with the RFC
   number assigned the draft-ietf-avt-rtcp-bw when published as RFC.
     References in this draft to RFC UUUU should be replaced with the
   RFC number assigned the draft-ietf-avt-srtp when published as RFC.
   References in this draft to RFC VVVV should be replaced with the RFC
   number assigned the draft-ietf-avt-rtcp-feedback when published as
   RFC.  References in this draft to RFC WWWW should be replaced with
   the RFC number of the revision of RFC 1889 being drafted as draft-
   ietf-avt-rtp-new.]

                   IETF draft - Expires April 2003                  1

Abstract

   RTP retransmission is an effective packet loss recovery scheme technique
   for real-time applications with relaxed delay bounds.
   This document describes an RTP retransmission framework. It defines
   a payload format for retransmitted packets and recommends rules for
   sending these packets. 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 indicating the occurred packet
   losses it is available by some means not available. In particular,
   availability of enhanced RTCP feedback as defined here. in the extended
   RTP profile for RTCP-based feedback [1] ( denoted AVPF ) is assumed
   in this memo.

Main changes

   *since draft-ietf-avt-rtp-retransmission-01.txt
   IANA considerations section added
   New appendix on RTP retransmission and multiplexing. It results from
   a discussion on mailing list.

   *since draft-ietf-avt-rtp-retransmission-00.txt:
   An applicability statement was added.
   The security considerations section was expanded.

   Leon, Varsa   IETF draft - Expires September 2002                1
                     RTP retransmission framework            June 2002

   *since draft-leon-rtp-retransmission-02.txt:

   The previous version of the draft described

   This document is the use result of the
   redundancy payload format (RFC 2198) in order to send retransmission
   data merging of draft-ietf-avt-selret-
   05.txt and original data in the same stream. At IETF #53, it was
   concluded that RFC 2198 was not intended to such a use. Piggybacking
   retransmitted packets was thus removed from the draft. draft-ietf-avt-rtp-retransmission-02.txt.

Table of Contents

   Abstract...........................................................1

   Abstract...........................................................2
   Main changes.......................................................1 changes.......................................................2
   1. Introduction....................................................2
   2. Terminology.....................................................3
   3. Applicability statement.........................................3 Requirements and design rationale for a retransmission scheme...4
   4. Retransmission framework basic principles.......................4
   5. Retransmission payload format...................................5
   6. Use
   5. Association of a retransmission stream with its original stream.7
   6. Use with the Extended extended RTP profile for RTCP-based feedback.......6 feedback.......8
   7. Congestion control..............................................8 control.............................................10
   8. Example scenario of unicast streaming...........................9
   9. SDP usage.......................................................9 usage......................................................11
   9. RTSP considerations............................................14
   10. IANA considerations............................................9 Implementation examples.......................................15
   11. IANA considerations...........................................18
   12. Security consideration........................................11
   Appendix A: Retransmission and SSRC multiplexing..................12
   Appendix B: FEC for retransmission................................13
   References........................................................14 considerations.......................................22
   13. Acknowledgements..............................................22
   14. References....................................................23
   Author's Addresses................................................15 Addresses................................................24

1. Introduction

   Packet losses between an RTP sender and receiver may significantly
   degrade the quality of the received signal. media. Several techniques, such
   as forward error correction (FEC), retransmissions or application
   layer (e.g. video) error resilience adaptation based on back-channel
   messages interleaving
   may be considered to increase the robustness to packet
   loss. RFC-2354 [1] loss resiliency. RFC 2354 [9]
   discusses the different options.

   When choosing a repair technique for a particular system, application, the
   tolerable latency of the application has to be taken into account.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 2
   In the case of multimedia conferencing, the end-to-end delay has to
   be at most a few hundred milliseconds in order to guarantee
   interactivity, which usually excludes the use of retransmission. On the other hand,

   However, in the case of multimedia streaming, the user can tolerate
   an initial latency as part of the session setup set-up and thus an end-to-end end-to-
   end delay of several seconds is possible. may be acceptable. Retransmission may
   thus be considered for such applications.

   Leon, Varsa          - Expires December 2002                      2
                     RTP retransmission framework            June 2002

   This document proposes specifies a retransmission framework. It method for RTP for unicast
   and (small) multicast groups: it defines a payload format for
   retransmitted RTP packets and retransmission
   rules. This RTP retransmission scheme requires frequent packet loss
   indication feedback to provides protocol rules for the RTP entity performing retransmission. The
   AV profile [2] does not provide this feature sender
   and could therefore not
   be used. However, the receiver involved in retransmissions.

   Furthermore, this retransmission scheme could be run under payload format was designed for use
   with the extended RTP profile for RTCP-based feedback[3] which feedback, AVPF [1]. It
   may also be used together with other RTP profiles defined in the
   future.

   The AVPF profile allows for frequent feedback, early feedback and
   defines a NACK
   message that can be sent as part small number of a compound RTCP packet. general-purpose feedback messages, e.g.
   ACKs and NACKs, as well as codec and application-specific feedback
   messages. See [1] for details.

2. Terminology

   The following terms are used in this document:

   Original packet: refers to an RTP packet which carries user data
   sent for the first time by an RTP sender.

   Original stream: refers to the RTP stream of original packets.

   Retransmission packet: refers to an RTP packet whose payload
   includes the payload and possible header extension of an already
   sent original packet. Such a retransmission packet is said to be
   associated with the original RTP
   packet whose payload is included in the retransmission packet.

   Retransmission request: a means by which an RTP receiver is able to
   request that the RTP sender should send a retransmission packet associated
   with for
   a given original packet. In [3], a retransmission request is
   sent Usually, an RTCP NACK message as a packet loss indication specified
   in a NACK message. [1] is used as retransmission request for lost packets.

   Retransmission stream: the stream of retransmission packets
   associated to with an original stream.

   Session-multiplexing: scheme by which the original stream and the
   associated retransmission stream are sent into two different RTP
   sessions.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 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 [4]. RFC 2119 [2].

3. Applicability statement

   There are two proposals for RTP retransmissions (this proposal
   draft-ietf-avt-rtp-retransmission-01.txt Requirements and draft-ietf-avt-rtp-
   selret-05.txt). Both proposals may be optimum under design rationale for a different retransmission scheme

   The retransmission scheme is designed to fulfil the following set of constraints.

   This draft enables the receiver to perform reliable loss detection
   of user data, i.e. the receiver can differentiate between lost
   packets sent for first time
   requirements:

   1. It must not break general RTP and lost retransmissions.
   Reliable user data loss detection is required RTCP mechanisms
   2. It must be suitable for example in RTP
   conversational text (RFC 2793) 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 multiple payload types in a session.
   6. In order to indicate missing text to support the user. For some applications, reliable loss detection largest variety of user
   data may not be strictly required but may enhance a
      payload formats the RTP receiver
   performance.

   Leon, Varsa          - Expires December 2002                      3 must be able to indicate how
      many and which RTP retransmission framework            June 2002 packets were lost. This retransmission algorithm allows receivers requirement is
      referred to trade-off the
   playout delay versus the as sequence number of retransmissions for preservation. Without such a given
   packet. This delay does not need to
      requirement, it would be signalled impossible to use retransmission with
      payload formats, such as conversational text [10] or most
      audio/video streaming applications, that use the sender and
   can be changed dynamically during the session in order to adapt to
   varying network conditions. Receivers should choose whether RTP sequence
      number to
   request detect lost packets.

   When designing a missing packet based on an estimation solution for RTP retransmission, several approaches
   may be considered for the multiplexing of its timestamp
   which is usually obtained from the observed correlation between original RTP packets
   and the retransmitted RTP packets.

   One approach may be to retransmit the RTP packet with its original
   sequence number and timestamp. Implementers should carefully
   design their decision send original and retransmission request algorithm packets in order to
   limit the risk of unnecessary retransmission.

   This
   same stream. The retransmission scheme requires a separate RTP session packet would then be identical to send
   retransmitted packets. As a consequence, two additional ports are
   needed: one port for
   the original RTP retransmission stream packet, i.e. the same header (and thus same
   sequence number) and one port for the associated RTCP. While this same payload. However, such an approach is generally
   not a problem, the
   implementers should assess the implications in acceptable because it would corrupt the targeted
   environment.

   This scheme may be used in RTCP statistics. As a multicast
   consequence, requirement 1 would not be met. Correct RTCP statistics
   require that for every RTP session in order to
   perform unicast retransmission to each participant.

   If a separate session is used, mixers, translators and packet caches within the RTP stream, the
   sequence number be increased by one.

   Another approach may be able to separate retransmission packets from multiplex original packets
   at an RTP session level based only on the port being used packets and
   process them differently if necessary.

4. Retransmission framework basic principles

   Retransmission
   retransmission packets MUST NOT share the RTP Sequence Number (SN)
   space with in the original stream. The retransmission same stream SHOULD use
   a different RTP session (as defined in RTP [5]) from that of using the
   original stream. Since a separate session is used, payload type
   field. With such an approach the original stream and
   retransmission streams are sent to different multicast group/unicast
   addresses and/or port numbers.

   There are several reasons why the SN space must not be shared:

   Since
   retransmission packets do not stream would share the SN space with the
   original packets, same sequence number space. As
   a result, the RTP receiver is would not be able to distinguish between the
   loss of infer how many and
   which original packets and retransmission packets. Otherwise,
   reliable loss detection of user data (i.e. with which sequence number) were lost.

   In other words, this feature does not satisfy the sequence number
   preservation requirement (requirement 6). This in turn implies that
   requirement 4 would not be possible. Reliable
   data loss detection of user data is mandated for example in RTP
   conversational text [6].

   RTP Timestamp (TS) estimation of missing original packets is
   necessary at the receiver met. Interoperability with mixers and

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 4
   translators would also be more difficult if they do not understand
   this new payload type in order to decide whether a
   retransmission is useful or not. A retransmission is useful if the
   retransmission packet sent as sender RTP stream.
   For these reasons, a response to the retransmission
   request may still be used when it arrives at the receiver. The
   missing original packet timestamp can be estimated from timestamp solution based on payload type multiplexing of

   Leon, Varsa          - Expires December 2002                      4
                     RTP
   original packets and retransmission framework            June 2002 packets preceding and/or following the sequence number gap caused by
   the missing packet in the original stream.

   The fact that same RTP streams for stream
   is excluded.

   Finally, the original and retransmission packets do
   not share 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 SN space guarantees that the RTP timestamp
   estimation method is reliable. Reliability would be sacrificed if session using different SSRCs, i.e. SSRC-multi-
   plexing. Since original and retransmission packets were sent in carry media of
   the same type, the objections in Section 5.2 of RTP, RFC WWWW [3] to
   RTP multiplexing do not apply.

   Using two separate streams satisfies all the requirements listed in
   this section. Mixers and translators may process the original stream
   as
   and simply discard the timestamp estimate for a lost retransmission packet would
   then be incorrect. This stream if they are unable to
   utilise it.

3.1 Multiplexing scheme choice

   Session-multiplexing and SSRC-multiplexing have different pros and
   cons:

   Session-multiplexing is because based on sending the retransmission packet usually
   has stream
   in a smaller "out-of-order" timestamp than the timestamp different RTP session (as defined in RTP [3]) from that of the
   consecutive
   original packets.

   When stream, i.e. the original and retransmission stream is streams are
   sent to different network addresses and/or port numbers. Having a multicast RTP session,
   receivers may choose whether to subscribe or not to the RTP
   separate session
   carrying the allows more flexibility. In multicast, using two
   sessions for retransmission stream. Therefore, allows a multicast streaming
   application can use retransmission and still be backwards compatible
   as receivers which do receiver to choose whether to
   subscribe or not implement the retransmission payload
   format only join to the RTP session carrying the original retransmission
   stream. A
   scenario where It is also possible for the original session is to be single-
   source multicast and have separate unicast sessions carry the retransmission stream to convey
   retransmissions to each
   participant, is also possible. In this scenario, a receiver receives
   only of the retransmission packets it has itself requested and not receivers, which will then receive
   only the retransmission packets that are requested they requested.

   The use of separate sessions also allows differential treatment by other receivers.

   Mixers, translators
   the network and packet caches may be able to separate
   retransmission packets from original packets at an RTP session level simplify processing in mixers, translators and process them differently if necessary.

   As
   packet caches.

   With SSRC-multiplexing, a consequence of having separate RTP sessions single session is needed for the original
   and the retransmission streams, there are also separate RTCP streams stream. This allows streaming servers and
   statistics for these two sessions. There is thus no corruption
   middleware which are involved in a high number of
   the original stream RTCP statistics. The RTP sender is able concurrent
   sessions to know
   the packet loss minimise their port usage.

   This retransmission payload format allows for both session-
   multiplexing and jitter of the original stream. It can thus
   estimate what the quality SSRC-multiplexing. From an implementation point of
   view there is little difference between the received signal would two approaches.
   Hence, in order to maximise interoperability, both multiplexing
   approaches SHOULD be without
   the use of retransmission.

5. supported.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 5

4. Retransmission payload format

   The payload format of a retransmission packet is shown below. below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|   OPT
   |            OSN                |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Leon, Varsa          - Expires December 2002                      5

   The RTP header usage is as follows:

   If the original and the retransmission framework            June 2002 streams are sent in separate
   RTP header usage:
   The sessions, the same SSRC value SHOULD MUST be used for the original
   stream and the retransmission stream.

   In the RTP header, SN case of an SSRC collision, an RTCP BYE packet MUST be sent for
   the original RTP session. After a new SSRC identifier is obtained,
   the SSRC of the retransmission session MUST be set to this value.

   If the original stream and the retransmission stream are sent in the
   same RTP session, two different SSRC values MUST be used for the
   original stream and the retransmission stream as required by RTP.

   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 packet. stream.

   The payload type retransmission packet timestamp is dynamic and
   indicates set to the use 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 payload format. All other
   fields stream is not random but equal to the original
   timestamp of the RTP header first packet requested for retransmission. See the
   security considerations section in this document for security
   implications.

   Implementers have to be aware that the same RTCP jitter value as in for the original RTP
   packet.

   The
   retransmission stream does not reflect the actual network jitter
   since there could be little correlation between the time a packet payload carries an E bit, an OPT field (7
   bits) is
   retransmitted and an OSN field (2 bytes) followed by the its original RTP packet
   payload. timestamp.

   The E bit payload type is an extension bit for future-proofing. It dynamic. Each payload type of the original
   stream MUST
   be set map to zero. The OPT field is the a different payload type of value in the
   retransmission stream. Therefore, when multiple payload types are
   used in the original
   packet stream, multiple dynamic payload that is being retransmitted. The OSN field is types will be
   mapped to this payload format. See Section 8 for the
   sequence number specification
   of how the mapping between original packet that originally carried and retransmission payload types
   is done.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 6
   As the
   same payload.

6. Use with retransmission packet timestamp carries the Extended RTP profile for RTCP-based feedback

6.1 Sending rules for RTCP-based feedback

   When original media
   timestamp, the Extended RTP profile for RTCP-based feedback [4] timestamp clockrate used by the retransmission
   payload type is used,
   it the same as the one used by the original payload
   type. It is RECOMMENDED that receivers send retransmission requests
   according thus possible to the rules retransmit RTP packets whose payload
   types have different timestamp clockrates in the same retransmission
   stream if the original payload types have different clock rates, but
   this section. The rules described
   hereafter aim at limiting is usually not the case.

   If the original RTP header carried any profile-specific payload
   header, the maximum delay before a retransmission
   request can packet MUST include this payload header.

   If the original RTP header carried an RTP header extension, the
   retransmission packet SHOULD carry the same header extension.

   The retransmission payload carries a payload header followed by the
   original RTP packet payload. The length of payload header is 2
   octets. The payload header contains only one field, OSN, which MUST
   be sent and are compliant set to the more general rules
   described in sequence number of the profile itself.

   The NACK message format defined in associated original RTP packet.

   If the profile should original RTP packet contained RTP padding, that padding must
   be used. Early
   RTCP removed before constructing the retransmission packet. If padding
   of the retransmission packet is needed, padding is performed as with
   any RTP packets should not be used and the NACK message should always
   be appended to a regularly scheduled compound RTCP packet that padding bit is
   sent at every RTCP report interval.

   Any set.

   All other rules to send feedback may be used as long fields of the RTP header MUST have the same value as they are
   compliant with in
   the profile. In particular, associated original RTP packet

5. Association of a receiver may send NACK
   messages in early RTCP packets. However, in that case the time when retransmission stream with its original stream

5.1 Retransmission session sharing

   In the next RTCP packet following this early RTCP packet can be sent
   could be too late to report case of session-multiplexing, a loss occurring right after the early
   RTCP packet was sent. Sending RTCP packets at regular intervals
   guarantees that the delay between detecting an original packet loss
   and being able retransmission session MUST
   map to send a NACK message for that packet is no longer
   than exactly one original session, i.e. the RTCP interval.

6.2 Receiver algorithm same retransmission
   session cannot be used for generating different original sessions.

   If retransmission requests

   This section gives some general guidelines on how session sharing were allowed, a receiver should
   decide whether or not joining
   the retransmission session would also receive the retransmissions
   belonging to request a packet retransmission. An actual all other original sessions which the receiver implementation should take into account such factors as may have
   not joined. There might also be SSRC identifier conflicts between
   the
   network environment and different original sessions.

5.2 CNAME use

   A sender MUST use the media type.

   Leon, Varsa          - Expires December 2002                      6
                     RTP same CNAME for an original stream and its
   associated retransmission framework            June 2002 stream.

5.3 Association at the receiver

   A receiver should compute an estimate of the receiving multiple original and retransmission delay streams
   needs to
   receive a associate each retransmission packet after a NACK message has been sent.
   This estimate may be obtained from past observations, RTCP report
   round-trip time if available or any other means. stream with its original
   stream. The minimum receiver buffering delay (i.e. the time between a packet association is received and its payload done differently depending on whether
   session-multiplexing or SSRC-multiplexing is used at the receiver) used.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 7
   If session-multiplexing is used, the RTCP
   reporting interval added to receiver associates the retransmission delay estimate. This
   delay guarantees two
   streams having the same SSRC in the two sessions. Note that a retransmission packet sent as a response to
   a retransmission request can be received before its the
   payload is used.

   It can type field cannot be seen that used to do this coupling as several
   media streams may have the needed receiver buffering delay is dependent
   on same payload type value. The two sessions
   are themselves associated out-of-band. See the amount SDP section to see
   how the grouping of RTCP traffic allowed in the session. It is
   illustrated in Section 8 that moderate RTCP feedback traffic two sessions is
   enough to perform retransmission done with reasonable receiver buffering
   delay.

   A SDP.

   If SSRC multiplexing is used, the receiver should maintain a list first of missing original packet
   sequence numbers. A receiver needs also to store all look
   for each missing
   original packet an estimated RTP timestamp as described in Section
   4. At two streams that have the next scheduled RTCP packet sending time, same CNAME in the receiver
   estimates which of session. In some
   cases, the missing packets should CNAME may not be requested in enough to determine the
   NACK message (see usage of association as
   multiple original streams in the PID and BLP fields of same session may share the NACK
   message format same
   CNAME. For example, there can be in [4]) of the RTCP compound packet. A missing packet
   should be requested if it is estimated same video session multiple
   video streams mapping to different SSRCs and still use the same
   CNAME and possibly the same PT values. Each (or some of) these
   streams may have an associated retransmission
   packet could still be used at stream.

   In order to find out the time it arrives at association between original and
   retransmission streams having the same CNAME, the receiver.
   The receiver should remove from its list of missing packets, the
   packets which were deemed too old to be requested.

   If SHOULD
   behave as follows.

   The association can generally be resolved when the receiver receives
   a retransmission stream is sent to packet matching a multicast session, the
   receiver should listen to NACK messages from other receivers. If retransmission request which had
   been sent earlier. Upon reception of a
   NACK message for the retransmission whose original
   sequence number of a missing packet has had been
   sent by another receiver, previously requested, the receiver should ignore can
   derive that sequence
   number in its list the SSRC of missing packets and refrain from sending a
   retransmission request for that sequence number.

   The same the retransmission request may be resent in packet is associated to
   the original RTP
   session if sender SSRC from which the requested packet was not received after an estimated
   retransmission reception time. This increases the robustness requested. In order to
   avoid ambiguity, the
   loss of a NACK message or of a retransmission packet. The receiver MUST NOT have two outstanding requests
   for the same packet sequence number in two different original
   streams before the association is resolved. Note that since the
   initial packet timestamps are random, the probability of
   retransmission having two
   outstanding requests that may be sent for a given missing
   original the same packet sequence number depends on would be
   very small.

   If the receiver buffering
   delay.

   The receiver should upon discovers that two senders are using the same SSRC
   or receives an RTCP BYE packet, it MUST stop requesting
   retransmissions for that SSRC. Upon reception of original RTP
   packets with a retransmission packet remove new SSRC, the corresponding original packet sequence number(OSN receiver MUST perform the SSRC
   association again as described in this section.

6. Use with the
   retransmission payload format) from extended RTP profile for RTCP-based feedback

   This section gives general hints for the list usage of missing sequence
   numbers.

6.3 RTCP sending rules in this payload
   format with the retransmission RTP session

   Leon, Varsa          - Expires December 2002                      7 extended RTP retransmission framework            June 2002

   Since profile for RTCP-based feedback [1],
   denoted AVPF.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 8

6.1 RTCP Receiver reports

   If the original RTP stream and the retransmission stream are carried
   in sent to
   separate RTP sessions, the retransmission stream has its own RTCP
   stream as well. The amount of RTCP sent receiver will then send report blocks for
   the retransmission original stream is computed as a fraction of and the retransmission streams in separate RTCP
   receiver reports (RR) packets belonging to separate RTP session
   bandwidth. Since the retransmission traffic is limited, the overhead
   caused by the additional sessions.
   RTCP packets reporting on the original stream are sent in the retransmission RTP
   session is moderate. For example, assuming a 64 kbps
   original RTP session and on average 3% packet loss and all lost original while RTCP packets
   retransmitted once, the bandwidth of reporting on the
   retransmission RTP session
   would be about 2 kbps. In this case stream are sent in the recommended retransmission session. The
   RTCP traffic bandwidth for these two sessions may be chosen independently
   (for example through RTCP bandwidth modifiers RFC ZZZZ [4]).

   If the retransmission original RTP stream and the retransmission stream are sent in
   the same session would be 0.1 kbps.

   Early RTCP packets (SSRC multiplexing), the receiver sends report
   blocks for the original and the retransmission streams in the same
   RTCP feedback messages RR packet.

6.2 Retransmission requests

   The NACK message format defined in the AVPF profile SHOULD NOT be used in
   the retransmission RTP session.

7. Congestion control

   RTP
   by receivers to send retransmission poses requests.
   Whether a risk of increased network congestion. In receiver chooses to request a best-effort environment, packet loss or not is caused by congestion.
   Reacting to loss by retransmission of older packets in addition to an
   implementation issue. An actual receiver implementation should take
   into account such factors as the current data would thus further increase congestion.
   Implementations SHOULD follow tolerable application delay, the recommendations below in order to
   use retransmission.
   network environment and the media type.

   The RTP profile under which receiver should generally assess whether the retransmission scheme retransmitted
   packet would still be useful at the time it is used
   defines an appropriate congestion control mechanism in different
   environments. Following the rules under received. The
   timestamp of the profile, an RTP
   application can determine its acceptable bitrate and missing packet rate in
   order to can be fair to other applications such as TCP flows and other
   RTP flows.

   If an RTP application uses retransmission, estimated from the acceptable timestamps
   of packets preceding and/or following the sequence number gap caused
   by the missing packet
   rate and bitrate SHOULD include both in the original and retransmitted
   data. This guarantees that an application using retransmission
   should be fair to any other RTP or TCP flows. Such a rule would
   translate in practice into stream. In most cases, some
   form of linear estimate of the following actions:

   If enhanced service timestamp is used, it good enough.

   Furthermore, a receiver should be made sure that the total
   bitrate and packet rate do not exceed that compute an estimate of RTT to the requested service.
   It should
   sender. This can be further monitored that done, for example, by measuring the requested services are
   actually delivered. In
   retransmission delay to receive 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 after a lower rate).

   In addition, the sender MAY retransmit only the packets that it
   deems important and ignore NACK messages
   message 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 packets in order
   to limit the bitrate

   These congestion control mechanisms should keep means.

   To increase the congestion level
   under an acceptable limit. This would in turn guarantee that robustness to the
   packet loss should be moderate. Too high of a NACK message or of a packet loss would mean

   Leon, Varsa          - Expires December 2002                      8
                     RTP
   retransmission framework            June 2002

   that congestion packet, a receiver may send a new NACK message. This
   is not kept under control and retransmission should
   then not referred to as multiple retransmissions.

   NACK packets MUST be used.

8. Example scenario of unicast streaming

   Let us assume that sent only for the original RTP session bandwidth is 64 kbps and the stream. If a
   receiver buffering delay is 3 seconds. The network round trip time
   is 500 ms and Receiver RTCP packets (including wanted to perform multiple-retransmissions by sending a
   NACK messages ) are
   sent at 2-second intervals. With these time limitations, when in the
   receiver algorithm for generating retransmission requests described
   in Section 6.2 is followed, only one request per packet loss can stream, it would not be
   sent. Let us assume an able to know the
   original packet rate sequence number and a timestamp estimation of 50 packets per second
   (1 packet every 20 ms). At this packet rate, with the packet loss
   distribution worst case scenario where every 17th original it
   requests.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                 9

6.3 Timing rules

   The RTCP NACK packet is
   lost (i.e. 5.88% uniform may be sent in a regular full compound RTCP
   packet loss), or in an early RTCP packet, as per AVPF [1]. Sending a maximum of 6 NACK messages
   need
   in an early packet allows to be appended react more quickly to the RTCP compound a given packet
   loss. However, in that is sent every 2
   seconds. The 6 NACK messages can report any case if a new packet losses in an SN
   range of 6*17=102, thus loss occurs right after
   the number of required NACK messages would
   not increase with higher early RTCP packet loss rates. The overhead required
   per was sent, the receiver will then have to wait
   for the next regular RTCP compound packet for after the 6 early packet.
   Sending NACK messages is 36 bytes which
   carries 6 PID and 6 BLP fields packets only in addition to the feedback message
   headers.

   The total compound regular RTCP packets size is thus: IPv4 (20) + UDP (8)+
   RR(header 8 + report 24)+ CNAME(12)+ compound decreases the
   maximum delay between detecting an original packet loss and being
   able to send a NACK (36) = 108 bytes. The
   needed receiver message 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 bandwidth would then be 0.432 kbps. compound packets. This can be used, for example, to
   keep reception reporting down to a given minimum, while still
   allowing receivers to react to periods requiring more frequent
   feedback, e.g. times of higher packet loss rate. In this way,
   receivers will try to keep the amount of sent RTCP
   bandwidth is well below packets as low as
   specified by the recommended minimum interval, but are still able to react to
   events requiring timely feedback, e.g. packet losses. Note that
   although RTCP bandwidth. The receiver packets may be suppressed because they do not contain
   NACK packets, the reserved RTCP recommended bandwidth in an RTP session with 64 kbps is about
   0.25*64 = 1.6 kbps.

9. SDP usage

   The binding to the payload type number is indicated by an rtpmap
   attribute. The name used in the binding is "rtx".

   An SDP example is shown below:

   c=IN IP4 113.3.12.11
   m=video 49170 RTP/AVPF 96
   a=rtpmap:96 H263-1998/90000
   a=fmtp:96 rtcp-fb nack
   m=video 49172 RTP/AVPF 97
   a=rtpmap:97 rtx/90000

10. IANA considerations

10.1 Registration of audio/rtx

   MIME type: audio

   Leon, Varsa          - Expires December 2002                      9 same as if they
   were sent. See AVPF [1] for details.

7. Congestion control

   RTP retransmission framework            June 2002

   MIME subtype: rtx

   Required parameters: rate
   The RTP timestamp clockrate poses a risk of increasing network congestion. In
   a best-effort environment, packet loss is equal caused by congestion.
   Reacting to loss by retransmission of older data without decreasing
   the RTP timestamp clockrate rate of the media that is retransmitted.
   Optional parameters: none

   Encoding considerations: this type is only defined for transfer via
   RTP.

   Security considerations: see original stream would thus further increase
   congestion. Implementations SHOULD follow the recommendations below
   in order to use retransmission.

   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 includes both the original and retransmitted data.
   This guarantees that an application using retransmission achieves
   the same fairness as one that doesn't. 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

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                10
   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. Packet loss is considered acceptable
   if a TCP flow across the same network path and experiencing the same
   network conditions would achieve an average throughput, measured on
   a reasonable timescale, that is not less than the RTP flow is
   achieving. If the packet loss rate exceed acceptable parameters,
   this would mean that congestion is not kept under control and
   retransmission should then not be used.  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 if the loss rate is unacceptably high.

8. SDP usage

8.1 Introduction

   This section specifies how to describe the retransmission delivery
   method using the Session Description Protocol (SDP), RFC 2327 [5].
   As specified in this document, the retransmission stream may be
   conveyed in separate RTP sessions, i.e. through session-
   multiplexing, or in the same RTP session as the original stream
   through SSRC-multiplexing.

   The following attributes 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", as specified in Section 11.

   An OPTIONAL payload format-specific parameter indicates the maximum
   time a server will try to retransmit a packet.
   The syntax is as follows:

        a=fmtp <number>: rtx-time=<rtx-time-val>
   where,
        <number> indicates the dynamic payload type number assigned to
        the retransmission payload format in an rtpmap attribute.
        <rtx-time-val> indicates the time in milliseconds, measured
        from the time a packet was first sent until the time the server
        will stop trying to retransmit the packet. No rtx-time
        parameter present for a retransmission stream means that the
        maximum retransmission time is not defined, but MAY be
        negotiated by other means.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                11
   Additionally, a new SDP payload-format-specific parameter "apt" MUST
   be used to map the RTX payload type to the associated original
   stream payload type as seen in the SDP description examples below.
   If multiple payload types are used in the original stream, then
   multiple "apt" parameters MUST be included to map each original
   stream payload type to a different RTX payload type. The syntax of
   this parameter is as follows:

        a=fmtp <number>: apt=<apt-value>
   where,
        <number> indicates the dynamic payload type number assigned to
        the retransmission payload format.
        <apt-value> indicates the original stream payload type to which
        this retransmission stream payload type is associated.

   Some SDP description examples are presented in the following
   subsections.

8.2 Mapping MIME Parameters into 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") and ("text") go in the SDP
      "m=" as the media name.

   -  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
      retransmission payload type. See Section 11

   Interoperability considerations: none

   Published specification: 4 for details
      on this.

   -  The AVPF profile-specific parameters "ack" and "nack" go in SDP
      "a=rtcp-fb". Several SDP "a=rtcp-fb" MUST be 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.

   Note that some example SDP session descriptions utilizing AMR and
   MPEG-4 encodings follow.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                12

8.3 SDP description with session-multiplexing

   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 xxx

   Applications which use YYYY [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 at.home.ru
   c=IN IP4 125.25.5.1
   a=group:FID 1 2
   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=01010000012000884006682C2090A21F
   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 media type: multimedia streaming
   applications

   Additional information: none

   Person & email address to contact special case only.

   This is illustrated in the following example, which is an SDP
   description for further information:
   david.leon@nokia.com

   Intended usage: COMMON

   Author/Change controller: David Leon

10.2 Registration a single original MPEG-4 stream and its
   corresponding retransmission session:

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                13
   v=0
   o=mascha 2980675221 2980675778 IN IP4 at.home.ru
   c=IN IP4 125.25.5.1
   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=01010000012000884006682C2090A21F
   m=video 49172 RTP/AVPF 97
   a=rtpmap:97 rtx/90000
   a=fmtp:97 apt=96;rtx-time=3000

8.4 SDP description with SSRC-multiplexing

   The following is an example of video/rtx

   MIME type: an SDP description for an RTP video

   MIME subtype: rtx

   Required parameters: rate
   session using SSRC-multiplexing with similar parameters as in the
   single-session example above:

   v=0
   o=mascha 2980675221 2980675778 IN IP4 at.home.ru
   c=IN IP4 125.25.5.1
   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=01010000012000884006682C2090A21F
   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.

   Because of the nature of retransmissions, the sending of
   retransmission packets should not be controlled through RTSP PLAY
   and PAUSE requests from the server. Instead, retransmission packets
   should be sent upon receiver requests in the original RTCP stream.
   It is described hereafter how the retransmission stream should be
   controlled in the SSRC-multiplexing and session-multiplexing case.

9.1 RTSP control with SSRC-multiplexing

   In the case of SSRC-multiplexing, there is a single RTSP "control"
   attribute for the media session. The receiver controls the original
   stream through the session RTSP control URL. As the receiver
   receives the original stream it can request retransmission through
   RTCP requests without additional RTSP signalling.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                14
   The RTP-info header that is used to set RTP-specific parameters in
   the PLAY response can describe only a single RTP timestamp clockrate is equal to stream in the
   session. The RTP-info header returned in the PLAY response MUST be
   the RTP timestamp clockrate
   of information for the media that is retransmitted.
   Optional parameters: none

   Encoding considerations: this type original stream.

9.2 RTSP control with session-multiplexing

   In the case of Session-multiplexing, each SDP "m" line must have an
   RTSP "control" attribute. Hence, when retransmission is only defined for transfer via
   RTP.

   Security considerations: see used, both
   the original session and the retransmission have their own "control"
   attribute. The original session and the retransmission session are
   associated through the FID semantics as specified in Section 11

   Interoperability considerations: none

   Published specification: RFC xxx

   Applications which use this media type: multimedia streaming
   applications

   Additional information: none

   Leon, Varsa          - Expires December 2002                     10
                     RTP 8.
   Both the original and the retransmission framework            June 2002

   Person & email address stream need to contact be setup
   through their respective "control" attribute.

   If the presentation supports aggregate control, the session-level
   "control" attribute is used as usual to control the whole
   presentation. As the receiver receives the presentation original
   streams, it can request retransmission through RTCP without
   additional RTSP signalling.

   If the presentation does not support aggregate control, the receiver
   should control each original stream as usual through its "control"
   attribute. However, the receiver SHOULD NOT send PLAY or PAUSE
   requests for further information:
   David.leon@nokia.com

   Intended usage: COMMON

   Author/Change controller: David Leon

10.3 Registration the retransmission streams. As the receiver receives
   the presentation original streams, it can request retransmission
   through RTCP requests without additional RTSP signalling.

   If an original stream is paused (independently of text/rtx

   MIME type: text

   MIME subtype: rtx

   Required parameters: rate
   The RTP timestamp clockrate whether aggregate
   or non-aggregate control is equal to used), a receiver may still send
   retransmission requests through RTCP.

10. Implementation examples

   This specification 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 RTP timestamp clockrate retransmission efficiency.

   This section gives an overview of the media that is retransmitted.
   Optional parameters: none

   Encoding considerations: different implementation options
   allowed within this type specification.

   The first example is only defined for transfer via
   RTP.

   Security considerations: see Section 11

   Interoperability considerations: none

   Published specification: RFC xxx

   Applications which use a server-driven retransmission implementation.
   With this media type: multimedia streaming
   applications

   Additional information: none

   Person & email address implementation, it is possible to contact for further information:
   David.leon@nokia.com

   Intended usage: COMMON

   Author/Change controller: David Leon

11. Security consideration

   Retransmission and FEC [7] have similar security conditions as far
   as encryption and congestion control are concerned.
   Applications utilizing encryption SHOULD encrypt both retransmit lost RTP
   packets, detect efficiently the original loss of retransmissions and perform
   multiple retransmissions, if needed. Most of the necessary
   processing is done at the server.

   The second example shows a receiver-driven implementation. It
   illustrates how a receiver may increase the retransmission stream. Old keys will likely need to be
   cached so that when

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                15
   efficiency. This implementation also increases the keys change for sender
   scalability by reducing the original stream, work required of the old
   key is sender.

   The third example shows how retransmissions may be used until it is determined in (small)
   multicast groups in conjunction with layered encoding. It
   illustrates that the key has changed on the retransmissions and layered encoding may be
   complementary techniques.

10.1  A sender-driven retransmission example

   This section gives an implementation example of multiple
   retransmissions. The sender transmits the original data in RTP
   packets as well.
   Congestion control considerations with using the use of retransmission MPEG-4 video RTP payload format.
   It is assumed that Generic NACK feedback messages are
   dealt used, as per
   [1]. An SDP description example with SSRC-multiplexing is given
   below:

   v=0
   o=mascha 2980675221 2980675778 IN IP4 at.home.ru
   c=IN IP4 125.25.5.1
   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" would indicate that the
   server will buffer the sent packets in Section 7 of this document.

   Leon, Varsa          - Expires December 2002                     11
                     RTP a retransmission framework            June 2002

   Any other security considerations of the profile under
   buffer for 3.0 seconds, after which the packets are deleted from
   the retransmission scheme is used should be applied.

Appendix A: Retransmission buffer and SSRC multiplexing will never be sent again.

   In this document, it is implementation example, the required that two separate RTP streams with
   their own receiver processing
   to handle retransmission is very limited. The receiver detects
   packet loss from the gaps observed in the received sequence number space be used for numbers.
   It signals lost packets to the original stream and sender through RTCP NACK messages as
   defined in the retransmission stream. This AVPF profile [1]. The receiver should be achieved by sending take into
   account the
   RTP stream and its associated signalled sender retransmission stream buffer length in order
   to different
   ports.

   Another way dimension its own reception buffer. It should also derive from
   the original and buffer length the maximum number of times retransmission stream could of a
   packet can be
   multiplexed is through requested.

   The sender should retransmit the use packets selectively, i.e. it should
   choose whether to retransmit a requested packet depending on the
   packet importance, the observed QoS and congestion state of different SSRCs if these streams
   are sent the
   network connection to the same port.
   In general, SSRC multiplexing is not feasible receiver. Obviously, the sender processing
   increases with the number of receivers as in a multicast
   group it would not state information and
   processing load must be possible allocated to associate an original stream and
   its each receiver.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                16

10.2 A receiver-driven retransmission stream since example

   The receiver may have more accurate information than the SSRC is a random number chosen
   by sender
   about the RTP sender.
   However, in unicast this should not current network QoS such as available bandwidth, packet
   loss rate, delay and jitter.
   In addition, other receiver-specific parameters like buffer level,
   estimated importance of the lost packet and application level QoS
   may be an issue if exactly one used by the receiver to make a more efficient use of RTP
   stream and its
   retransmission stream are multiplexed based on their
   SSRC. Since the through selective requests.

   Furthermore, a receiver knows may acknowledge the payload types used received packets. This
   can be done by sending ACK messages, as per [1]. Upon receiving an
   ACK, the
   original stream and sender may delete all the acknowledged packets from its
   retransmission stream, it  buffer.  Note  that  this  would be able to
   derive which SSRC maps to  also  require  only
   limited increase in the original data and which SSRC maps to
   retransmissions.

   SSRC multiplexing should generally be avoided required RTCP bandwidth as discussed in
   Section 5.2 of RTP [5]. One of long as ACK
   packets  are  sent  seldom  enough.  With  the advantage of multiplexing  receiver-driven
   retransmission   implementation,   processing   load   and   buffer
   requirements at the
   transport layer (i.e. based on sender are decreased, allowing greater sender
   scalability.

   Note that choosing between the IP address or port number) is sender-driven implementation and the
   use of different network paths or resources for different streams.
   However,
   receiver-driven implementation does not imply any changes in the case of unicast retransmission, it is the same media
   sent in both SDP
   description, except for the original and need to signal the retransmission.

   It also has use of ACK RTCP
   packets, by means of an additional SDP "a=rtcp-fb" line, as follows:

   v=0
   o=mascha 2980675221 2980675778 IN IP4 at.home.ru
   c=IN IP4 125.25.5.1
   m=video 49170 RTP/AVPF 96 97
   a=rtpmap:96 MP4V-ES/90000
   a=rtcp-fb:96 nack
   a=rtcp-fb:96 ack
   a=rtpmap:97 rtx/90000
   a=fmtp:97 apt=96;rtx-time=3000

10.3 Retransmissions with Layered Transmissions

   This section shows how to be noted combine retransmissions with layered
   encoding. Note that the SSRC-multiplexing approach retransmission framework is
   allowed in FEC [7]. Section 3 of FEC states "This document does not
   prescribe intended as
   a complete solution to reliable multicast. Refer to RFC 2887 [11],
   for an overview of the definition problems related with reliable multicast
   transmission.

   Packets of "separate streams", but leaves this to
   applications and higher level protocols different importance are sent in different RTP sessions.
   The retransmission streams corresponding to define. For multicast, the separate different layers can
   themselves be seen as different retransmission layers. The relative
   importance of the different retransmission streams should reflect
   the relative importance of the different original streams.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                17
   A retransmission stream may be implemented by separate multicast groups,
   different ports sent in the same group, RTP session as its
   corresponding original layer through SSRC multiplexing or by in a
   different SSRC within RTP session through session multiplexing.

   An SDP description example for SSRC-multiplexing is given below:

   c=IN IP4 224.2.1.1/127/3
   m=video 8000 RTP/AVPF 98 99
   a=rtpmap:98 MP4V-ES/90000
   a=rtcp-fb:98 nack
   a=rtpmap:99 rtx/90000
   a=fmtp:99 apt=98
   a=fmtp:99 rtx-time=3000

   The server and the
   same group/port. For unicast, different ports or different SSRC receiver may
   be used. Each of these approaches has drawbacks and benefits which
   depend on implement the application".

   This retransmission draft recommends the following rules:
   Separate addresses and/or ports must be used in the multicast case
   and should be used method
   as illustrated in the unicast case previous examples. In addition, they may
   choose to multiplex the original
   stream request and retransmit a lost packet depending on the retransmission stream. In
   layer it belongs to.

11. IANA considerations

11.1 Registration of audio/rtx

   MIME type: audio

   MIME subtype: rtx

   Required parameters:

        rate: the unicast case, exactly
   one RTP stream and its associated retransmission stream may be sent timestamp clockrate is equal to the same port and multiplexed based on their SSRCs RTP timestamp
        clockrate of the media that is retransmitted.

        apt: associated payload type. The motivation not to prevent SSRC multiplexing value of this parameter is to minimise
        the
   number payload type of ports usage when it may be the associated original stream.

   Optional parameters:

        rtx-time: indicates the time in milliseconds, measured from the
        time a performance issue for high-
   scale RTP servers and/or middle-ware proxies while allowing packet was first sent until the

   Leon, Varsa          - Expires December 2002 time the server will
        stop trying to retransmit the packet

   Encoding considerations: this type is only defined for transfer via
   RTP.

   Security considerations: see Section 12
                     RTP retransmission framework            June 2002

   original and of RFC XXXX
   Interoperability considerations: none

   Published specification: RFC XXXX

   Applications which use this media type: multimedia streaming
   applications

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                18
   Additional information: none

   Person & email address to contact for further information:
   rey@panasonic.de
   david.leon@nokia.com
   avt@ietf.org

   Intended usage: COMMON

   Author/Change controller:
   Jose Rey
   David Leon.
   IETF AVT WG

11.2 Registration of video/rtx

   MIME type: video

   MIME subtype: rtx

   Required parameters:

        rate: the retransmitted data to be sent into separate RTP
   streams with their own sequence number spaces.

Appendix B: FEC for retransmission

   It timestamp clockrate is possible equal to retransmit the payload of an original packet by
   sending a FEC packet as defined in [7] instead RTP timestamp
        clockrate  of using the
   retransmission media that is retransmitted.

        apt: associated payload format. type. The base sequence number value of the FEC
   header this parameter is
        the sequence number payload type of the associated original packet that carried
   the same payload and stream.
   Optional parameters:

        rtx-time: indicates the mask is set to zero. There are some
   advantages time in using milliseconds, measured from the FEC payload format in particular in
   multicast sessions as
        time a single FEC packet may repair was first sent until the loss of
   different packets at different receivers. In a multicast session,
   FEC may be combined with retransmission requests as described in [8]
   in order time the server will
        stop trying to achieve scalable reliable multicast transmission.

   There are however retransmit the following motivations packet

   Encoding considerations: this type is only defined for transfer via
   RTP.

   Security considerations: see Section 12 of RFC XXXX

   Interoperability considerations: none

   Published specification: RFC XXXX

   Applications which use this media type: multimedia streaming
   applications

   Additional information: none

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                19
   Person & email address to define contact for further information:
   rey@panasonic.de
   david.leon@nokia.com
   avt@ietf.org

   Intended usage: COMMON

   Author/Change controller:
   Jose Rey
   David Leon
   IETF AVT WG

11.3 Registration of text/rtx

   MIME type: text

   MIME subtype: rtx

   Required parameters:

        rate: the
   retransmission payload format in order RTP timestamp clockrate is equal to perform retransmission
   instead the RTP timestamp
        clockrate  of using the FEC media that is retransmitted.

        apt: associated payload format:

   *The retransmission type. The value of this parameter is
        the payload format has reduced overhead (3 bytes
   instead type of 12 bytes).

   *In the retransmission payload format, associated original stream.
   Optional parameters:

        rtx-time: indicates the time in milliseconds, measured from the
        time a packet was first sent until the time the RTP header TS field is server will
        stop trying to retransmit the actual timestamp packet

   Encoding considerations: this type is only defined for transfer via
   RTP.

   Security considerations: see Section 12 of the (retransmitted) RFC XXXX

   Interoperability considerations: none

   Published specification: RFC XXXX

   Applications which use this media carried in type: multimedia streaming
   applications

   Additional information: none

   Person & email address to contact for further information:
   rey@panasonic.de
   david.leon@nokia.com
   avt@ietf.org

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                20
   Intended usage: COMMON

   Author/Change controller:
   Jose Rey
   David Leon
   IETF AVT WG

11.4 Registration of application/rtx

   MIME type: application

   MIME subtype: rtx

   Required parameters:

        rate: the
   packets. This is in line with RTP [5] specifications. This timestamp clockrate is useful
   in particular for RTP mixers/translators which process the TS field.
   On the other hand, the FEC payload format uses equal to the RTP transmission
   time (as timestamp
        clockrate  of the FEC packet should be computed over data with different
   timestamp).

   *Assuming media that no retransmission is retransmitted.

        apt: associated payload format were defined, type. The value of this parameter is
        the
   FEC payload format would then be used in different ways: sending
   computed FEC packets proactively for correction type of lost packets at the receiver without requiring NACK messages (referred hereafter as
   proactive FEC) or sending retransmitted data upon receipt of a NACK
   message from associated original stream.

   Optional parameters:

        rtx-time: indicates the receiver.
   Although they could use time in milliseconds, measured from the same payload format, these two repair
   mechanisms are different. For a given amount of overhead, they offer
        time a different residual packet loss vs. latency trade-off.
   Retransmission provides higher was first sent until the time the server will
        stop trying to retransmit the packet loss recovery at

   Encoding considerations: this type is only defined for transfer via
   RTP.

   Security considerations: see Section 12 of RFC XXXX

   Interoperability considerations: none

   Published specification: RFC XXXX

   Applications which use this media type: multimedia streaming
   applications

   Additional information: none

   Person & email address to contact for further information:
   rey@panasonic.de
   david.leon@nokia.com
   avt@ietf.org

   Intended usage: COMMON

   Author/Change controller:
   Jose Rey
   David Leon
   IETF AVT WG

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                21

12. Security considerations

   Applications utilising encryption SHOULD encrypt both the expense
   of higher delay. If a sender uses proactive FEC original
   and none of the
   packets protected by a given FEC packet retransmission stream. Old keys will likely need to be
   cached so that when the keys change for the original stream, the old
   key is lost, there used until it is then no determined that the key has changed on the
   retransmission packets as well.

   The use of the FEC packet at the receiver. On same key for the other hand, data which
   are retransmitted are known to have been lost.
   Therefore, a receiver may wish to use only retransmission stream and not
   receive any proactive FEC from the sender in order
   original stream may lead to trade-off
   itself the buffering delay, security problems, e.g. two-time pads.
   This sharing has to be evaluated towards the data-loss rate chosen security
   protocol and security algorithms, e.g. the overhead.
   There is thus a motivation to let Secure Real-Time
   Transport Protocol (SRTP) RFC UUUU [8] establishes requirements for
   avoiding the receiver decide at session
   setup whether two-time pad.

   RTP recommends that the sender may send proactive FEC or retransmission
   only.

   Leon, Varsa          - Expires December 2002                     13 initial RTP retransmission framework            June 2002

   If timestamp SHOULD be random to
   secure the same stream against known plain text attacks. This payload
   format were used for these different purposes,
   the receiver would not know at session establishment which repair
   mechanism is used by the sender (without defining out-of-band
   signalling). The sender would decide by itself whether FEC or
   retransmission (or both) is used and the receiver would does not know
   until receiving follow this recommendation as the FEC packets whether proactive FEC or
   retransmission is used.
   On initial timestamp
   will be the other hand, having different payload formats or at least
   different out media timestamp of band signalling for these two repair mechanisms
   (e.g. through defining the binding name 'RTX' SDP rtpmap attribute)
   would allow the receiver to choose which mechanism to use (among
   those supported by first retransmitted packet.

   However, since the sender). The receiver would then have an
   explicit way to tell initial timestamp of the sender not to send proactive FEC.
   Furthermore, original stream is
   itself random, if the receiver did not know at session establishment
   whether it will receive FEC packets or retransmission, it original stream is encrypted, the first
   retransmitted packet timestamp would have
   to be prepared to receive FEC and thus also be able random to perform FEC packet
   recovery operations. Implementers an attacker.
   Therefore, security would thus not be able choose to
   implement only a FEC or compromised.

   Congestion control considerations with the use of retransmission scheme.

References

   1  Perkins, C., Hodson, O., "Options are
   dealt with in Section 7 of this document.

   Any other security considerations of the profile under which the
   retransmission scheme is used should be applied.

13. Acknowledgements

   We would like to express our gratitude to Carsten Burmeister for Repair his
   participation in the development of Streaming Media",
      RFC 2354, June 1998.

   2  Schulzrinne, H and this document. Our thanks also
   go to Koichi Hata, Colin Perkins, Stephen Casner, S. " RTP Profile for Audio Magnus Westerlund,
   Go Hori and
      VideoConferences with Minimal Control," Internet Draft draft-
      ietf-avt-profile-new-12.txt, November 2001.

   3  J Rahul Agarwal for their helpful comments.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                22

14. References

14.1 Normative References

   1 J. Ott, S S. Wenger, S Fukunaga, N N. Sato, K Yano, M Akihiro, H Koichi,
      R Hakenberg, C. Burmeister Burmeister, J. Rey, "Extended RTP
     profile for RTCP-based feedback", November 2001

   4 RFC 2119 S Bradner ., VVVV, September 2002.

   2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997

   5

   3 H. Schulzrinne, H., S. Casner, S., Frederick, R. Frederick and V. Jacobson, "RTP: A
     Transport Protocol for Real-Time Applications", Internet Draft
      draft-ietf-avt-rtp-new-11.txt, November 2001. RFC WWWW, May
     2002.

   4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC ZZZZ,
     May 2002.

   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 SDP", RFC YYYY, February 2002.

   7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol
     (RTSP)", RFC 2326, April 1998.

   8 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
     Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
     RFC UUUU, June 2002.

14.2 Non-normative References

   9 C. Perkins, O. Hodson, "Options for Repair of Streaming Media",
     RFC 2354, June 1998.

   10 J. Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000

   7  Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for
      Generic Forward Error Correction", RFC 2733, December 1999.

   8  Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss
      recovery for reliable multicast transmission", ACM SIGCOMM'97,
      Cannes, France, September 1997

   Leon, Varsa          - Expires December 2002                     14
                     RTP retransmission framework            June 2002

   11 M. Handley, et al., "The Reliable Multicast Design Space for Bulk
     Data Transfer", RFC 2887, August 2000.

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                23

Author's Addresses

   Jose Rey                                     rey@panasonic.de
   Panasonic European Laboratories GmbH
   Monzastr. 4c
   D-63225 Langen, Germany
   Phone: +49-6103-766-134
   Fax:   +49-6103-766-166

   David Leon                                   david.leon@nokia.com
   Nokia Research Center
   6000 Connection Drive            Phone:  1-972-374-1860
   Irving, TX. USA                  Email:  david.leon@nokia.com
   Phone:  1-972-374-1860

   Akihiro Miyazaki                             akihiro@isl.mei.co.jp
   Core Software Development Center
   Corporate Software Development Division
   Matsushita Electric Industrial Co., Ltd.
   1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
   Phone: +81-6-6900-9192
   Fax:   +81-6-6900-9193

   Viktor Varsa                                 viktor.varsa@nokia.com
   Nokia Research Center
   6000 Connection Drive            Phone:  1-972-374-1861
   Irving, TX. USA                  Email:  viktor.varsa@nokia.com

   Leon, Varsa          - Expires December 2002                     15
   Phone:  1-972-374-1861

   Rolf Hakenberg                               hakenberg@panasonic.de
   Panasonic European Laboratories GmbH
   Monzastr. 4c
   D-63225 Langen, Germany
   Phone: +49-6103-766-162
   Fax:   +49-6103-766-166

   Rey/Leon/Miyazaki/Varsa/Hakenberg                                24