Stephen Casner | 1 Feb 08:54 2003
Picon

Re: Final edits to RTP spec and A/V profile

On Wed, 15 Jan 2003, Pekka Pessi wrote:

> 	What is the difference between an RTP cloud (a la section 7) and
> 	an RTP session?

An RTP cloud is a portion of an RTP session.  As section 7 says,
typically, each cloud is defined by a common network and transport
protocol (e.g., IP/UDP) plus a multicast address and transport level
destination port or a pair of unicast addresses and ports.  In other
words, the clouds are separated from each other by being on different
networks or using different transport protocols or addresses.  The
translator or mixer joins together the clouds into one RTP session by
being connected to each cloud.

> >        RTP session: An association among a set of participants
> >             communicating with RTP.  A participant may be involved in
> >             multiple RTP sessions at the same time.  In a multimedia
> >             session, each medium is carried in a separate RTP session
> >             with its own RTCP packets.  A participant distinguishes
> >             multiple RTP sessions by reception of different sessions
> >             using different pairs of destination transport addresses,
> >             where a pair of transport addresses comprises one network
> >             address plus a pair of ports for RTP and RTCP.
>
> 	Don't we have multiple mediums in a single RTP session, for
> 	example, with some MPEG4 packetization? So, s/medium/RTP media
> 	type/, or is it then a circular definition?

Well, yes.  How about:

(Continue reading)

Sudhir Sharma | 1 Feb 09:48 2003

RTP Payload Format

Hi,

I want to create test programs for dtmf generation and also a program to
read dtmf from rtp according to this rfc rfc2833 .
Can anyone  please tell me some link where i can get sample program or help
regarding this.

I will really appreciate your quick reply.

Thanx and Regards
sudhir

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Daniel Feldman | 3 Feb 11:07 2003

TCRTP, L2TPHC and L2TPoAAL5

    Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson,
    Section 3.3.2 of the current TCRTP draft has a bandwidth comparison table, including TCRTP over PPP and TCRTP over AAL5.
    From the text I understand that:
a) TCRTP over PPP includes Header Compression only once, so the IP header (20 bytes) is not compressed. This could be reduced by using the COMPRESSED_NON_TCP format described in RFC2507 below the L2TPHC tunnel.
b) TCRTP over AAL5 includes a 20-bytes IP header which could be reduced to zero, if L2TPHC worked straight over AAL5.
 
    My questions are:
1) Can we add the scenario described in (a) to the TCRTP draft?
2) Is it possible to extend L2TPHC so it is compatible with L2TPoAAL5 (RFC3355)?
3) Can we add this scenario to the TCRTP draft?
 
    Thanks in advance and regards,
 
        Daniel Feldman.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Architecture Group Manager, IC4IC Ltd.
office: +972 (4) 959-4644 ext. 121
mobile: +972 (55) 99-0299
fax:    +972 (4) 959-4944
web:     http://www.ic4ic.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Fiandra Riccardo | 3 Feb 11:23 2003
Picon

RTCP unicast feedback for measurement applications?

Gents,
I was interested in the "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback" draft.
Actually, I was wondering if it is also targeted to have a very large and
distribuited network measurement framework.
Where multicast receivers (thousands) use RTCP to send report to a
measurement collector about packet loss, jitter, or other.
I see really many advantages on that for e2e measurements, especially in a
scenario where thousands of receivers are always connected to the network
and cannot send multicast (common scenario for an operator, even without
SSM...).

My questions are:
-Was this a scenario of application when writing the draft?
-In this case, could I use the RTCP channel multicasted to the receivers to
control them?
-Do you see any extension possible also for ptp rtp connections (forward
rtcp reports to another device?)

Tanx in advance for any feedback

Riccardo

 
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Marshall Eubanks | 3 Feb 15:18 2003

Re: RTCP unicast feedback for measurement applications?

Hello;

I see no reason why you could not use unicast RTCP for measurement 
applications

- we do this already with our prototype unicast RTCP
- the NLANR multicast beacon uses unicast reports (although not rtcp, 
alas) to
respond back to the beacon server, which is how

http://beaconserver.accessgrid.org:9999/

gets generated.

On Monday, February 3, 2003, at 05:23  AM, Fiandra Riccardo wrote:

> Gents,
> I was interested in the "RTCP Extensions for Single-Source Multicast
> Sessions with Unicast Feedback" draft.
> Actually, I was wondering if it is also targeted to have a very large 
> and
> distribuited network measurement framework.
> Where multicast receivers (thousands) use RTCP to send report to a
> measurement collector about packet loss, jitter, or other.
> I see really many advantages on that for e2e measurements, especially 
> in a
> scenario where thousands of receivers are always connected to the 
> network
> and cannot send multicast (common scenario for an operator, even without
> SSM...).
>
> My questions are:
> -Was this a scenario of application when writing the draft?

It was in my mind when reviewing it. In any case, Internet protocols are 
not restricted
to uses thought of in advance !

> -In this case, could I use the RTCP channel multicasted to the 
> receivers to
> control them?

Why not ?

> -Do you see any extension possible also for ptp rtp connections (forward
> rtcp reports to another device?)
>

The danger here is denial of service attacks (if you are sending 50 mbps 
of reports to somewhere,
and I can re-direct this to point somewhere else, we have  a big DOS 
problem).

> Tanx in advance for any feedback
>
> Riccardo
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
                                  Regards
                                  Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme <at> multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Eve Schooler | 4 Feb 02:02 2003
Picon

Re: RTCP unicast feedback for measurement applications?


Fiandra Riccardo <riccardo.fiandra <at> fastweb.it> wrote: 

>I was interested in the "RTCP Extensions for Single-Source Multicast
>Sessions with Unicast Feedback" draft.
>Actually, I was wondering if it is also targeted to have a very large and
>distribuited network measurement framework.
>Where multicast receivers (thousands) use RTCP to send report to a
>measurement collector about packet loss, jitter, or other.
>I see really many advantages on that for e2e measurements, especially in a
>scenario where thousands of receivers are always connected to the network
>and cannot send multicast (common scenario for an operator, even without
>SSM...).
>
>My questions are:
>-Was this a scenario of application when writing the draft?

Absolutely, though the primary focus of the draft was to solve 
the problem posed by the removal/restriction of the backchannel 
caused by SSM and other uni-directional or asymmetric topologies. 
Solving the feedback problem for SSM gives us the blueprint for
other unicast-based feedback architectures, including ones for
network measurement in general.

>-In this case, could I use the RTCP channel multicasted to the receivers to
>control them?

Yes you could.  This is certainly what we envision in the RTCP
context; use the multicast channel in the source-to-receiver
direction, and use the unicast backchannels in the 
receiver-to-source direction.

We also propose to use the multicast channel either:
- to reflect receiver feedback (received on the unicast backchannels)
  back out on the multicast channel to reach all receivers, or
- to redistribute to the receivers feedback summaries 
  (receiver feedback collected at the source and aggregated into 
  a single mathematical distribution) back out on the multicast channel.

>-Do you see any extension possible also for ptp rtp connections (forward
>rtcp reports to another device?)

In section 10 of draft-ietf-avt-rtcpssm-02.txt, we use
an extension to SDP to indicate the device to which the
feedback gets reported.  This is done following the proposal 
for SDP source filters documented in 
draft-ietf-mmusic-sdp-srcfilter-00.txt.

We also just completed a paper that expands upon the ideas
in the I-D and that should provide further application 
scenarios.  I'll post it here shortly.

Eve

-=-=-=-=-

Eve M. Schooler                 Voice:  1-650-330-7913
AT&T Labs - Research            FAX:    1-650-463-7037
75 Willow Road                  E-mail: schooler <at> research.att.com
Menlo Park, CA, USA 94025       http://www.research.att.com/~schooler
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Jose Rey | 4 Feb 10:43 2003
Picon

draft-ietf-avt-rtp-retransmission-05.txt

Hi all,

attached the latest revision of the retransmission draft. We feel it is
ready for WGLC and would like to ask for your comments.

This is the list of changes since version -04:

a) s.3: 1st paragragh. Applicability of the retransmission payload
format (Colin's comment)
b) s.3.1: last paragraph (no SSRC-mux if multicast rtx, Colin's comment,
solved on the list)
c) s.4: 5th paragraph starting from the end. In section 4, two main
changes/additions: possibility to retransmit at a lower rate and
clarification of headers ordering (Colin's comment, the latter); plus
one minor thing: clarification of SSRC collision handling by the sender.
d) s.5.3: last paragraph but one
e) s.6.1: new, to separate sender and receiver RTCP.
f) s.10.2: implementation examples. Clarified.
g) s.11 MIME registration reorganised.
h) s.12: the retransmission payload format cannot be used under SAVP.
Reference to SAVP removed, as concluded on the list.

I think that's it.

cheers,

José


   Internet Draft                                                         
   draft-ietf-avt-rtp-retransmission-05.txt             J. Rey/Matsushita 
                                                            D. Leon/Nokia 
                                                   A. Miyazaki/Matsushita 
                                                           V. Varsa/Nokia 
                                                  R. Hakenberg/Matsushita 
                                                                          
                                                                          
                                                                          
   Expires: August 2003                                     February 2003 
    
    
                     RTP 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 RFC 2026. 
    
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        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. 
    
   Copyright Notice 
    
      Copyright (C) The Internet Society (2003).  All Rights Reserved. 
    
    
   [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.] 
    
   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 RTCP 

     
                   IETF draft - Expires August 2003           [Page 1] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   feedback as defined in the extended RTP profile for RTCP-based 
   feedback (denoted RTP/AVPF), is available in this memo. 
 
 
Table of Contents 
    
   1. Introduction....................................................3 
   2. Terminology.....................................................3 
   3. Requirements and design rationale for a retransmission scheme...4 
   4. Retransmission payload format...................................6 
   5. Association of a retransmission stream with its original stream.8 
   6. Use with the extended RTP profile for RTCP-based feedback......10 
   7. Congestion control.............................................12 
   8. Retransmission Payload Format MIME type registration...........13 
   9. RTSP considerations............................................19 
   10. Implementation examples.......................................20 
   11. IANA considerations...........................................23 
   12. Security considerations.......................................23 
   13. Acknowledgements..............................................24 
   14. References....................................................24 
   Author's Addresses................................................25 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     
   Rey, et al.                                                [Page 2] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
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.   
    
   However, 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.  Retransmission may 
   thus be considered for such applications.   
    
   This document specifies a retransmission method for RTP applicable 
   to unicast and (small) multicast groups: it defines a payload format 
   for retransmitted RTP packets and provides protocol rules for the 
   sender and the receiver involved in retransmissions. 
    
   Furthermore, 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 small number of 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 which 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. 
    
     
   Rey, et al.                                                [Page 3] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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-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 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 fulfil 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. 
   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. 
    
     
   Rey, et al.                                                [Page 4] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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.  
    
   Mixers and translators may process the original stream and simply 
   discard the retransmission stream if they are unable to utilise it.  
   Using two separate streams thus 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 
     
   Rey, et al.                                                [Page 5] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 stream.  This allows streaming servers and 
   middleware which 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). 
    
    
4. Retransmission payload format  
    
   The format of a retransmission packet is shown below: 
    
    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         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 
     
   Rey, et al.                                                [Page 6] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   original stream or the retransmission stream, the RTP specification 
   requires that an RTCP BYE packet MUST be sent for this stream.  No 
   RTCP BYE packet MUST be sent for the associated stream.  Therefore, 
   only the stream that experienced SSRC collision will choose a new 
   SSRC value.  Refer to Section 5.3 for the implications on the 
   original 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 is 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. 
    
   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.  Each payload type of the original 
   stream MUST map to a different payload type value in the 
   retransmission stream.  Therefore, when multiple payload types are 
   used in the original stream, multiple dynamic payload types will 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 SDP. 
    
   As the retransmission packet timestamp carries the original media 
   timestamp, the timestamp clockrate used by the retransmission 
   payload type is the same as the one used by the associated original 
   payload type.  It is thus possible to send retransmission packets 
   whose original payload types have different timestamp clockrates in 
   the same 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, 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, is 
   placed right after the retransmission payload header. 
    
   For payload types 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.  
     
   Rey, et al.                                                [Page 7] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 not 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 
   retransmission payload header is thus 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 is thus 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 is performed 
   as with any RTP packets and the padding bit is set. 
    
   The M, CC and CSRC bit of the original RTP header MUST remain 
   unchanged in the retransmission packet. 
    
    
5. Association of a retransmission stream with its original stream 
    
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 CNAME for an original stream and its 
   associated retransmission stream. 
     
   Rey, et al.                                                [Page 8] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
    
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 
   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 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 which 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.                                                [Page 9] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
    
    
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 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 
   (for example 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. 
    
6.3 Retransmission requests 
    
   The NACK feedback message format defined in the AVPF profile SHOULD 
   be used by receivers to send retransmission requests.  Whether a 
   receiver chooses to request a packet or not is an implementation 
   issue.  An actual receiver implementation should take into account 

     
   Rey, et al.                                               [Page 10] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 Extended Reports 
   [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. 
    
   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 in order to avoid unnecessary retransmissions. 
    
   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. 
    
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 to react 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. 
    

     
   Rey, et al.                                               [Page 11] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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. 
    
   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 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.  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 the packet loss rate exceeds an acceptable level, it 
   should be concluded 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 
     
   Rey, et al.                                               [Page 12] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   for a layered multicast session), or to arrange for the receiver to 
   leave the session.  
    
    
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 payload types are used for the original 
   streams, then multiple "apt" parameters MUST be included to map each 
   original stream payload type to a different retransmission payload 
   type. 
    
   An OPTIONAL payload-format-specific parameter, "rtx-time," indicates 
   the maximum time a server will try to retransmit a 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>: the value of the original stream payload type to 
        which this retransmission stream payload type is associated. 
         
        <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.  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.  
         
         
8.2 Registration of audio/rtx 
    
   MIME type: audio 
    
   MIME subtype: rtx 
    
   Required parameters:  
    

     
   Rey, et al.                                               [Page 13] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
        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 until the 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 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 <at> panasonic.de 
   david.leon <at> nokia.com 
   avt <at> ietf.org 
    
   Intended usage: COMMON 
    
   Author/Change controller:  
   Jose Rey 
   David Leon 
   IETF AVT WG 
    
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.  
    
     
   Rey, et al.                                               [Page 14] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   Optional parameters: 
    
        rtx-time: 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. 
    
   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 <at> panasonic.de 
   david.leon <at> nokia.com 
   avt <at> ietf.org 
    
   Intended usage: COMMON 
    
   Author/Change controller:  
   Jose Rey 
   David Leon 
   IETF AVT WG 
    
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 until the time the server will 
        stop trying to retransmit the packet. 
    
    
     
   Rey, et al.                                               [Page 15] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 <at> panasonic.de 
   david.leon <at> nokia.com 
   avt <at> ietf.org 
    
   Intended usage: COMMON 
    
   Author/Change controller:  
   Jose Rey 
   David Leon 
   IETF AVT WG 
    
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 until the 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 of RFC XXXX 
    
   Interoperability considerations: none 
    
     
   Rey, et al.                                               [Page 16] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 <at> panasonic.de 
   david.leon <at> nokia.com 
   avt <at> ietf.org 
    
   Intended usage: COMMON 
    
   Author/Change controller:  
   Jose Rey 
   David Leon 
   IETF AVT WG 
    
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") 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 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. 
    
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 

     
   Rey, et al.                                               [Page 17] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 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 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 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 
    
     
   Rey, et al.                                               [Page 18] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
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: 
    
   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. 
    
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. 
    
   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.                                               [Page 19] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 session. 
    
   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 to cache an SSRC-multiplexed session 
   or not. 
    
    
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.  
    
   This section gives an overview of different implementation options 
   allowed within this specification. 
    

     
   Rey, et al.                                               [Page 20] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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 a receiver may implement additional 
   enhancements that might help reduce sender buffer requirements and 
   optimise the retransmission efficiency  
    
   The third 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 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" 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. 
    
   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 QoS and congestion state of the 
   network connection to the receiver.  Obviously, the sender processing 

     
   Rey, et al.                                               [Page 21] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   increases with the number of receivers as state information and 
   processing load must be allocated to each receiver. 
    
10.2 An enhanced receiver implementation example 
    
   The receiver may have more accurate information than the sender about 
   the current network QoS such as available bandwidth, packet loss 
   rate, delay and jitter.  In addition, other receiver-specific 
   parameters such as buffer level, estimated importance of the lost 
   packet and application level QoS may be used by the receiver to make 
   a more efficient use of RTP retransmission by selectively sending 
   NACKs for important lost packets and not for others.  For example, a 
   receiver may decide to suppress a request for a packet loss that 
   could be concealed locally, or for a retransmission that would arrive 
   late. 
    
   Furthermore, a receiver may acknowledge the received packets.  This 
   can be done by sending ACKs, as per [1].  Upon receiving an ACK, the 
   sender  may  delete  all  the  acknowledged  packets  from  its 
   retransmission buffer.  Note that this would also require only 
   limited increase in the required RTCP bandwidth as long as ACK 
   packets are sent seldom enough. 
    
   This implementation may help reduce buffer requirements at the sender 
   and optimise the performance of the implementation by using selective 
   requests.  
    
   Note that these receiver enhancements do not need to be negotiated as 
   they do not affect the sender implementation.  However, in order to 
   allow the receiver to acknowledge packets, it is needed to allow the 
   use of ACKs in the SDP description, 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 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 not intended as a complete solution to reliable 
   multicast.  Refer to RFC 2887 [10], for an overview of the problems 
   related with reliable multicast transmission. 
    
   Packets of different importance are sent in different RTP sessions.  
   The retransmission streams corresponding to the different layers can 
     
   Rey, et al.                                               [Page 22] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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: 
    
   c=IN IP4 224.2.1.1/127/3 
   m=video 8000 RTP/AVPF 98 
   a=rtpmap:98 MP4V-ES/90000 
   a=rtcp-fb:98 nack 
   c=IN IP4 224.2.1.4/127/3 
   m=video 8000 RTP/AVPF 99 
   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. 
    
    
11. IANA considerations 
    
   A new MIME subtype name, "rtx", has been registered.  An additional 
   REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", 
   are defined.  See Section 8 for details. 
    
    
12. Security considerations 
    
   Applications utilising encryption SHOULD encrypt both the original 
   and the retransmission stream.  Old keys will likely need to be 
   cached so that when the keys change for the original stream, the old 
   key is used until it is determined that the key has changed on the 
   retransmission packets as well. 
    
   The use of the same key for the retransmitted stream and the 
   original stream may lead to security problems, e.g. two-time pads.  
   This sharing has to be evaluated towards the chosen security 
   protocol and security algorithms. 
    
   RTP recommends that the initial RTP timestamp SHOULD be random to 
   secure the stream against known plain text attacks.  This payload 
   format does not follow this recommendation as the initial timestamp 
   will be the media timestamp of the first retransmitted packet.  
    

     
   Rey, et al.                                               [Page 23] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
   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.  
    
   Congestion control considerations with the use of retransmission 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.  The retransmission 
   payload format MUST NOT be used under the SAVP profile defined by 
   the Secure Real-Time Transport Protocol (SRTP)[12] but instead an 
   extension of SRTP should be defined to secure the AVPF profile.  The 
   definition of such a profile is out of the scope 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 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 
     profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback-
     04.txt, September 2002. 
    
   2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 
     Levels", BCP 14, RFC 2119, March 1997 
    
   3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 
     Transport Protocol for Real-Time Applications", draft-ietf-avt-
     rtp-new-11.txt, May 2002. 
    
   4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft-
     ietf-avt-rtcp-bw-05.txt, 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 the Session Description Protocol (SDP)", RFC 3388, December 
     2002. 
    
   7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 
     (RTSP)", RFC 2326, April 1998. 
    
    
     
   Rey, et al.                                               [Page 24] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
14.2 Informative References 
    
   8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 
     RFC 2354, June 1998. 
    
   9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 
    
   10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 
     Data Transfer", RFC 2887, August 2000. 
    
   11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 
 
   12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 
     Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 
     draft-ietf-avt-srtp-05.txt, June 2002. 
    
    
Author's Addresses 
    
   Jose Rey                                     rey <at> 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 <at> nokia.com 
   Nokia Research Center 
   6000 Connection Drive             
   Irving, TX. USA                   
   Phone:  1-972-374-1860 
    
   Akihiro Miyazaki                             akihiro <at> 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 <at> nokia.com 
   Nokia Research Center 
   6000 Connection Drive             
   Irving, TX. USA 
   Phone:  1-972-374-1861 
    
   Rolf Hakenberg                               hakenberg <at> panasonic.de 
   Panasonic European Laboratories GmbH          
   Monzastr. 4c                                  
   D-63225 Langen, Germany 
   Phone: +49-6103-766-162 
   Fax:   +49-6103-766-166 
    
     
   Rey, et al.                                               [Page 25] 
   Internet Draft    RTP Retransmission Payload Format   February 2003 
    
    
    
   Full Copyright Statement 
    
   "Copyright (C) The Internet Society (date).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the  purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will 
   not be revoked by the Internet Society or its successors or 
   assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS 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." 
























     
   Rey, et al.                                               [Page 26] 
Magnus Westerlund | 4 Feb 16:07 2003
Picon
Picon

Comments on draft-ietf-avt-rtp-retransmission-05.txt

Hi Jose,

I have a few minor comments that I believe that you must address before 
a successful WGLC can be performed.

A few of these are related to the ID-nits. See:
http://www.ietf.org/ID-nits.html

1. The SDP examples contain FQDNs that are not belonging to the example 
domain, see chapter 3 of RFC 2606.
2. IP addresses in SDP examples does not belong to example range 
192.0.2.0/24.
3. Section 4: Last paragraph. I think that it is erroneous formulated 
that the "M", "CC" and CSRC" bit MUST remain unchanged. I think one 
should clarify that they shall be copied as is from the original header 
instead,
4. Section 8.6, The MIME types listed as going into the m= line are 
missing "application".
5. Section 9.3: "The PLAY and PAUSE requests SHOULD NOT  affect the 
retransmission stream." I think this is normative language and the 
should not shall be capitalized.
6. Section 10.3 The SDP example is in error: The c= lines shall be 
placed after its corresponding m= line. Please mind the order and place 
it directly after the m= line as no i= is present.
7. Section 11: Might be nice to say that the RTX subtype is register for 
four different media types.
8. An IPR statement prior to copyright section is missing. See ID-nits 
about required sections

I think all is very easy to update.

Best Regards

Magnus

Jose Rey wrote:

>Hi all,
>
>attached the latest revision of the retransmission draft. We feel it is
>ready for WGLC and would like to ask for your comments.
>
>This is the list of changes since version -04:
>
>a) s.3: 1st paragragh. Applicability of the retransmission payload
>format (Colin's comment)
>b) s.3.1: last paragraph (no SSRC-mux if multicast rtx, Colin's comment,
>solved on the list)
>c) s.4: 5th paragraph starting from the end. In section 4, two main
>changes/additions: possibility to retransmit at a lower rate and
>clarification of headers ordering (Colin's comment, the latter); plus
>one minor thing: clarification of SSRC collision handling by the sender.
>d) s.5.3: last paragraph but one
>e) s.6.1: new, to separate sender and receiver RTCP.
>f) s.10.2: implementation examples. Clarified.
>g) s.11 MIME registration reorganised.
>h) s.12: the retransmission payload format cannot be used under SAVP.
>Reference to SAVP removed, as concluded on the list.
>
>
>I think that's it.
>
>cheers,
>
>José
>
>
>
>  
>
>------------------------------------------------------------------------
>
>
>
>                                                                          
>   Internet Draft                                                         
>   draft-ietf-avt-rtp-retransmission-05.txt             J. Rey/Matsushita 
>                                                            D. Leon/Nokia 
>                                                   A. Miyazaki/Matsushita 
>                                                           V. Varsa/Nokia 
>                                                  R. Hakenberg/Matsushita 
>                                                                          
>                                                                          
>                                                                          
>   Expires: August 2003                                     February 2003 
>    
>    
>                     RTP 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 RFC 2026. 
>    
>    
>   Internet-Drafts are working documents of the Internet Engineering 
>   Task Force (IETF), its areas, and its working groups.  Note that      
>   other groups may also distribute working documents as Internet-
>   Drafts. 
>    
>   Internet-Drafts are draft documents valid for a maximum of six 
>   months and may be updated, replaced, or obsoleted by other documents 
>   at any time.  It is inappropriate to use Internet-Drafts as 
>   reference material or to cite them other than as "work in progress." 
>    
>   The list of current Internet-Drafts can be accessed at 
>        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. 
>    
>   Copyright Notice 
>    
>      Copyright (C) The Internet Society (2003).  All Rights Reserved. 
>    
>    
>   [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.] 
>    
>   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 RTCP 
>
>     
>                   IETF draft - Expires August 2003           [Page 1] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   feedback as defined in the extended RTP profile for RTCP-based 
>   feedback (denoted RTP/AVPF), is available in this memo. 
> 
> 
>Table of Contents 
>    
>   1. Introduction....................................................3 
>   2. Terminology.....................................................3 
>   3. Requirements and design rationale for a retransmission scheme...4 
>   4. Retransmission payload format...................................6 
>   5. Association of a retransmission stream with its original stream.8 
>   6. Use with the extended RTP profile for RTCP-based feedback......10 
>   7. Congestion control.............................................12 
>   8. Retransmission Payload Format MIME type registration...........13 
>   9. RTSP considerations............................................19 
>   10. Implementation examples.......................................20 
>   11. IANA considerations...........................................23 
>   12. Security considerations.......................................23 
>   13. Acknowledgements..............................................24 
>   14. References....................................................24 
>   Author's Addresses................................................25 
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>    
>     
>   Rey, et al.                                                [Page 2] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>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.   
>    
>   However, 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.  Retransmission may 
>   thus be considered for such applications.   
>    
>   This document specifies a retransmission method for RTP applicable 
>   to unicast and (small) multicast groups: it defines a payload format 
>   for retransmitted RTP packets and provides protocol rules for the 
>   sender and the receiver involved in retransmissions. 
>    
>   Furthermore, 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 small number of 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 which 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. 
>    
>     
>   Rey, et al.                                                [Page 3] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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-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 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 fulfil 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. 
>   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. 
>    
>     
>   Rey, et al.                                                [Page 4] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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.  
>    
>   Mixers and translators may process the original stream and simply 
>   discard the retransmission stream if they are unable to utilise it.  
>   Using two separate streams thus 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 
>     
>   Rey, et al.                                                [Page 5] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 stream.  This allows streaming servers and 
>   middleware which 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). 
>    
>    
>4. Retransmission payload format  
>    
>   The format of a retransmission packet is shown below: 
>    
>    
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>   |                         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 
>     
>   Rey, et al.                                                [Page 6] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   original stream or the retransmission stream, the RTP specification 
>   requires that an RTCP BYE packet MUST be sent for this stream.  No 
>   RTCP BYE packet MUST be sent for the associated stream.  Therefore, 
>   only the stream that experienced SSRC collision will choose a new 
>   SSRC value.  Refer to Section 5.3 for the implications on the 
>   original 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 is 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. 
>    
>   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.  Each payload type of the original 
>   stream MUST map to a different payload type value in the 
>   retransmission stream.  Therefore, when multiple payload types are 
>   used in the original stream, multiple dynamic payload types will 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 SDP. 
>    
>   As the retransmission packet timestamp carries the original media 
>   timestamp, the timestamp clockrate used by the retransmission 
>   payload type is the same as the one used by the associated original 
>   payload type.  It is thus possible to send retransmission packets 
>   whose original payload types have different timestamp clockrates in 
>   the same 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, 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, is 
>   placed right after the retransmission payload header. 
>    
>   For payload types 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.  
>     
>   Rey, et al.                                                [Page 7] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 not 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 
>   retransmission payload header is thus 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 is thus 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 is performed 
>   as with any RTP packets and the padding bit is set. 
>    
>   The M, CC and CSRC bit of the original RTP header MUST remain 
>   unchanged in the retransmission packet. 
>    
>    
>5. Association of a retransmission stream with its original stream 
>    
>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 CNAME for an original stream and its 
>   associated retransmission stream. 
>     
>   Rey, et al.                                                [Page 8] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>    
>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 
>   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 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 which 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.                                                [Page 9] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>    
>    
>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 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 
>   (for example 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. 
>    
>6.3 Retransmission requests 
>    
>   The NACK feedback message format defined in the AVPF profile SHOULD 
>   be used by receivers to send retransmission requests.  Whether a 
>   receiver chooses to request a packet or not is an implementation 
>   issue.  An actual receiver implementation should take into account 
>
>     
>   Rey, et al.                                               [Page 10] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 Extended Reports 
>   [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. 

>    
>   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 in order to avoid unnecessary retransmissions. 
>    
>   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. 
>    
>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 to react 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. 
>    
>
>     
>   Rey, et al.                                               [Page 11] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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. 
>    
>   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 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.  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 the packet loss rate exceeds an acceptable level, it 
>   should be concluded 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 
>     
>   Rey, et al.                                               [Page 12] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   for a layered multicast session), or to arrange for the receiver to 
>   leave the session.  
>    
>    
>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 payload types are used for the original 
>   streams, then multiple "apt" parameters MUST be included to map each 
>   original stream payload type to a different retransmission payload 
>   type. 
>    
>   An OPTIONAL payload-format-specific parameter, "rtx-time," indicates 
>   the maximum time a server will try to retransmit a 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>: the value of the original stream payload type to 
>        which this retransmission stream payload type is associated. 
>         
>        <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.  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.  
>         
>         
>8.2 Registration of audio/rtx 
>    
>   MIME type: audio 
>    
>   MIME subtype: rtx 
>    
>   Required parameters:  
>    
>
>     
>   Rey, et al.                                               [Page 13] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>        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 until the 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 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 <at> panasonic.de 
>   david.leon <at> nokia.com 
>   avt <at> ietf.org 
>    
>   Intended usage: COMMON 
>    
>   Author/Change controller:  
>   Jose Rey 
>   David Leon 
>   IETF AVT WG 
>    
>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.  
>    
>     
>   Rey, et al.                                               [Page 14] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   Optional parameters: 
>    
>        rtx-time: 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. 
>    
>   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 <at> panasonic.de 
>   david.leon <at> nokia.com 
>   avt <at> ietf.org 
>    
>   Intended usage: COMMON 
>    
>   Author/Change controller:  
>   Jose Rey 
>   David Leon 
>   IETF AVT WG 
>    
>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 until the time the server will 
>        stop trying to retransmit the packet. 
>    
>    
>     
>   Rey, et al.                                               [Page 15] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 <at> panasonic.de 
>   david.leon <at> nokia.com 
>   avt <at> ietf.org 
>    
>   Intended usage: COMMON 
>    
>   Author/Change controller:  
>   Jose Rey 
>   David Leon 
>   IETF AVT WG 
>    
>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 until the 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 of RFC XXXX 
>    
>   Interoperability considerations: none 
>    
>     
>   Rey, et al.                                               [Page 16] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 <at> panasonic.de 
>   david.leon <at> nokia.com 
>   avt <at> ietf.org 
>    
>   Intended usage: COMMON 
>    
>   Author/Change controller:  
>   Jose Rey 
>   David Leon 
>   IETF AVT WG 
>    
>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") 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 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. 
>    
>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 
>
>     
>   Rey, et al.                                               [Page 17] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 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 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 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 
>    

>     
>   Rey, et al.                                               [Page 18] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>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: 
>    
>   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. 
>    
>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. 
>    
>   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.                                               [Page 19] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 session. 
>    
>   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 to cache an SSRC-multiplexed session 
>   or not. 
>    
>    
>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.  
>    
>   This section gives an overview of different implementation options 
>   allowed within this specification. 
>    
>
>     
>   Rey, et al.                                               [Page 20] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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 a receiver may implement additional 
>   enhancements that might help reduce sender buffer requirements and 
>   optimise the retransmission efficiency  
>    
>   The third 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 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" 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. 
>    
>   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 QoS and congestion state of the 
>   network connection to the receiver.  Obviously, the sender processing 
>
>     
>   Rey, et al.                                               [Page 21] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   increases with the number of receivers as state information and 
>   processing load must be allocated to each receiver. 
>    
>10.2 An enhanced receiver implementation example 
>    
>   The receiver may have more accurate information than the sender about 
>   the current network QoS such as available bandwidth, packet loss 
>   rate, delay and jitter.  In addition, other receiver-specific 
>   parameters such as buffer level, estimated importance of the lost 
>   packet and application level QoS may be used by the receiver to make 
>   a more efficient use of RTP retransmission by selectively sending 
>   NACKs for important lost packets and not for others.  For example, a 
>   receiver may decide to suppress a request for a packet loss that 
>   could be concealed locally, or for a retransmission that would arrive 
>   late. 
>    
>   Furthermore, a receiver may acknowledge the received packets.  This 
>   can be done by sending ACKs, as per [1].  Upon receiving an ACK, the 
>   sender  may  delete  all  the  acknowledged  packets  from  its 
>   retransmission buffer.  Note that this would also require only 
>   limited increase in the required RTCP bandwidth as long as ACK 
>   packets are sent seldom enough. 
>    
>   This implementation may help reduce buffer requirements at the sender 
>   and optimise the performance of the implementation by using selective 
>   requests.  
>    
>   Note that these receiver enhancements do not need to be negotiated as 
>   they do not affect the sender implementation.  However, in order to 
>   allow the receiver to acknowledge packets, it is needed to allow the 
>   use of ACKs in the SDP description, 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 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 not intended as a complete solution to reliable 
>   multicast.  Refer to RFC 2887 [10], for an overview of the problems 
>   related with reliable multicast transmission. 
>    
>   Packets of different importance are sent in different RTP sessions.  
>   The retransmission streams corresponding to the different layers can 
>     
>   Rey, et al.                                               [Page 22] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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: 
>    
>   c=IN IP4 224.2.1.1/127/3 
>   m=video 8000 RTP/AVPF 98 
>   a=rtpmap:98 MP4V-ES/90000 
>   a=rtcp-fb:98 nack 
>   c=IN IP4 224.2.1.4/127/3 
>   m=video 8000 RTP/AVPF 99 
>   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. 
>    
>    
>11. IANA considerations 
>    
>   A new MIME subtype name, "rtx", has been registered.  An additional 
>   REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", 
>   are defined.  See Section 8 for details. 
>    
>    
>12. Security considerations 
>    
>   Applications utilising encryption SHOULD encrypt both the original 
>   and the retransmission stream.  Old keys will likely need to be 
>   cached so that when the keys change for the original stream, the old 
>   key is used until it is determined that the key has changed on the 
>   retransmission packets as well. 
>    
>   The use of the same key for the retransmitted stream and the 
>   original stream may lead to security problems, e.g. two-time pads.  
>   This sharing has to be evaluated towards the chosen security 
>   protocol and security algorithms. 
>    
>   RTP recommends that the initial RTP timestamp SHOULD be random to 
>   secure the stream against known plain text attacks.  This payload 
>   format does not follow this recommendation as the initial timestamp 
>   will be the media timestamp of the first retransmitted packet.  
>    
>
>     
>   Rey, et al.                                               [Page 23] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>   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.  
>    
>   Congestion control considerations with the use of retransmission 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.  The retransmission 
>   payload format MUST NOT be used under the SAVP profile defined by 
>   the Secure Real-Time Transport Protocol (SRTP)[12] but instead an 
>   extension of SRTP should be defined to secure the AVPF profile.  The 
>   definition of such a profile is out of the scope 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 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 
>     profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback-
>     04.txt, September 2002. 
>    
>   2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 
>     Levels", BCP 14, RFC 2119, March 1997 
>    
>   3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 
>     Transport Protocol for Real-Time Applications", draft-ietf-avt-
>     rtp-new-11.txt, May 2002. 
>    
>   4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft-
>     ietf-avt-rtcp-bw-05.txt, 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 the Session Description Protocol (SDP)", RFC 3388, December 
>     2002. 
>    
>   7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 
>     (RTSP)", RFC 2326, April 1998. 
>    
>    
>     
>   Rey, et al.                                               [Page 24] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>14.2 Informative References 
>    
>   8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 
>     RFC 2354, June 1998. 
>    
>   9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 
>    
>   10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 
>     Data Transfer", RFC 2887, August 2000. 
>    
>   11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 
> 
>   12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 
>     Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 
>     draft-ietf-avt-srtp-05.txt, June 2002. 
>    
>    
>Author's Addresses 
>    
>   Jose Rey                                     rey <at> 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 <at> nokia.com 
>   Nokia Research Center 
>   6000 Connection Drive             
>   Irving, TX. USA                   
>   Phone:  1-972-374-1860 
>    
>   Akihiro Miyazaki                             akihiro <at> 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 <at> nokia.com 
>   Nokia Research Center 
>   6000 Connection Drive             
>   Irving, TX. USA 
>   Phone:  1-972-374-1861 
>    
>   Rolf Hakenberg                               hakenberg <at> panasonic.de 
>   Panasonic European Laboratories GmbH          
>   Monzastr. 4c                                  
>   D-63225 Langen, Germany 
>   Phone: +49-6103-766-162 
>   Fax:   +49-6103-766-166 
>    
>     
>   Rey, et al.                                               [Page 25] 
>   Internet Draft    RTP Retransmission Payload Format   February 2003 
>    
>    
>    
>   Full Copyright Statement 
>    
>   "Copyright (C) The Internet Society (date).  All Rights Reserved. 
>    
>   This document and translations of it may be copied and furnished to 
>   others, and derivative works that comment on or otherwise explain it 
>   or assist in its implementation may be prepared, copied, published 
>   and distributed, in whole or in part, without restriction of any 
>   kind, provided that the above copyright notice and this paragraph are 
>   included on all such copies and derivative works.  However, this 
>   document itself may not be modified in any way, such as by removing 
>   the copyright notice or references to the Internet Society or other 
>   Internet organizations, except as needed for the  purpose of 
>   developing Internet standards in which case the procedures for 
>   copyrights defined in the Internet Standards process must be 
>   followed, or as required to translate it into languages other than 
>   English. 
>    
>   The limited permissions granted above are perpetual and will 
>   not be revoked by the Internet Society or its successors or 
>   assigns. 
>    
>   This document and the information contained herein is provided on an 
>   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
>   TASK FORCE DISCLAIMS 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." 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     
>   Rey, et al.                                               [Page 26] 
>  
>

--

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> era.ericsson.se



_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Tmima Koren | 4 Feb 19:36 2003
Picon

Re: TCRTP, L2TPHC and L2TPoAAL5

At 12:07 PM 2/3/2003 +0200, Daniel Feldman wrote:

    Hello Tmima, Mr. Valencia, Mr. Wing and Mr. Thompson,
    Section 3.3.2 of the current TCRTP draft has a bandwidth comparison table, including TCRTP over PPP and TCRTP over AAL5.
    From the text I understand that:
a) TCRTP over PPP includes Header Compression only once, so the IP header (20 bytes) is not compressed. This could be reduced by using the COMPRESSED_NON_TCP format described in RFC2507 below the L2TPHC tunnel.

The L2TP packet traverses multiple links between source and destination
If some individual links on the path are point to point, it is possible to compress the L2TP IP header using IPHC
But it's not like you can do IPHC at the source and have the packet go compressed all the way to the destination
Once the packet is an L2TP packet it is a regular IP packet and it can be compressed on individual links like any other IP packet
So I'm not sure we need to add this to the TCRTP draft
Regards
Tmima

b) TCRTP over AAL5 includes a 20-bytes IP header which could be reduced to zero, if L2TPHC worked straight over AAL5.
 
    My questions are:
1) Can we add the scenario described in (a) to the TCRTP draft?
2) Is it possible to extend L2TPHC so it is compatible with L2TPoAAL5 (RFC3355)?
3) Can we add this scenario to the TCRTP draft?
 
    Thanks in advance and regards,
 
        Daniel Feldman.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Architecture Group Manager, IC4IC Ltd.
office: +972 (4) 959-4644 ext. 121
mobile: +972 (55) 99-0299
fax:    +972 (4) 959-4944
web:     http://www.ic4ic.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
David A. Mcgrew | 6 Feb 16:52 2003
Picon

RE: Security for draft-ietf-avt-rtp-retransmission

José,

> -----Original Message-----
> From: Jose Rey [mailto:rey <at> panasonic.de]
> Sent: Thursday, January 23, 2003 8:35 AM
> To: Avt <at> Ietf. Org
> Cc: mbaugher <at> cisco.com; elisabetta.carrara <at> era.ericsson.se;
> mcgrew <at> cisco.com; mats.naslund <at> era.ericsson.se;
> karl.norrman <at> era.ericsson.se; oran <at> cisco.com
> Subject: Security for draft-ietf-avt-rtp-retransmission
>
>
> Hi all,
>
> we are doing the final edits to the draft-ietf-avt-rtp-retransmission.
> We have considered all your comments until the date, but there's
> something for which we would like to get some feedback on: security.
>
> A couple of questions:
>
> 1.-As discussed on the list:
> ...
> > -----Original Message-----
> > From: avt-admin <at> ietf.org [mailto:avt-admin <at> ietf.org]On Behalf Of Colin
> > Perkins
> > Sent: Friday, January 10, 2003 4:39 AM
> > To: David.Leon <at> nokia.com
> > Cc: avt <at> ietf.org
> > Subject: Re: [AVT] Comments on
> > draft-ietf-avt-rtp-retransmission-04.txt
> >
> ...snip...
>
> > >>  - In section 12, how does this draft affect SRTP? Is it
> > possible to use
> > >>    the two formats together?
> > >
> > >We'll try to draft something on that. My understanding is that the
> > >retransmission stream is seen as any other stream by SRTP
> > and there should
> > >thus be no problem.
> >
> > I was not clear if retransmitting packets caused problems for
> > SRTP; maybe
> > one of the SRTP authors can comment on any potential security issue?
> >
>
> we don't see any problems (except for SRTCP as below in 2) to use SRTP
> with RTX since the RTP retransmission packets (with a two byte
> retransmission payload header) are seen by SRTP as 'normal' RTP packets.
> Is our assumption correct?

I think so.  Certainly if the retransmission packets are treated as a separate
session or separate stream with its own set of SRTP keys, then there's no
problem.  The only potential issue that I see is that the SRTP protection for
the retransmission data will need to get keys (and other parameters) somehow.
Is the plan to signal the retransmission session/stream at the same time as the
original stream, but then only use it if it is needed?  In that case, I'd expect
that all the SRTP info for both streams/sessions would be provided by the
signaling, which seems like it would work well.

>
> 2.-The retransmission payload format needs of the AVPF profile to enable
> more frequent feedback and to request packets. This profile defines
> (besides the new timing rules) some general-purpose messages such as
> ACKs and NACKs and a new RTCP packet format: the early feedback packet,
> which just contains 1 SR or RR and 1 SDES with just the CNAME. Now,
> there should be no problem to encrypt/authenticate early packets,
> according to the SRTP draft:
>
> "
>    According to [RFC1889] there is a "recommended" packet format for
>    compound packets. SRTCP MUST be given packets according to that
>    recommendation in the sense that the first part MUST be a sender
>    report or a receiver report. However, the encryption prefix (Section
>    6.1 of [RFC1889]), a random 32-bit quantity intended to deter known
>    plaintext attacks, MUST NOT be used (see below).
> "
>
>
> Also there should be no problem to authenticate/encrypt ACKs and NACKs
> with SRTCP since they are sent in compound RTCP packets starting with an
> RR or SR packet. Let us know if you disagree with this point.
>
>
> 3.- if a new profile needs be defined, something like "SAVPF", where
> shall this profile "SAVPF" be specified and registered? wouldn't it be
> reasonable to do this in the SRTP draft which already registers the
> "SAVP" profile given that the feedback draft would (presumably) have a
> similar schedule to the SRTP draft? In this way the question 2. could
> also be anwered there.

The SRTP draft is in IESG review, so at this point it wouldn't be appropriate to
drag it back.  But if the new profile is uncomplicated, it shouldn't be hard to
throw together a new draft that references AVPF and SRTP to make SAVPF.  Could
you point me in the right direction as to what differences between AVP and AVPF
would be important w.r.t. SRTP?

>
> 4.- the security section in the retransmission draft already points out
> the risks of using the same keys across sessions, e.g. two.-time pads
> and points to the SRTP for solutions. That much is done. Are we missing
> something else?

The draft says that "Applications utilising encryption SHOULD encrypt both the
original    and the retransmission stream."   IIUC, it might be better to state
that "If cryptography is used to provide security services on the original
stream, then the same services, with equivalent cryptographic strength, SHOULD
be provided on the retransmission stream."  Also, I'm wondering why you would
want a SHOULD and not a MUST here!

Correct me if I'm wrong, but here's my mental picture of how the combined
srtp/retransmission system would work:

sender side
-----------

original rtp source -+------------------> srtp encrypter (key1) ---> ...
                     |
                     +-> rexmit buffer -> srtp encrypter (key2) ---> ...

Another approach would be to move the retransmission buffer to the other side of
the srtp encrypter, and get rid of key2.  This would be workable, since the
original sequence number is provided in the retransmitted packet.  However, this
scheme would not provide message authentication on the retransmission packet
flow.  Another demerit of this scheme is that it would interact badly with the
SRTP anti-replay window; the recommended size for this window is 128, and this
scheme might require an even larger one.  So I like the first method (the way I
think that you're doing it) better!

At any rate, it might be good to describe how you want the retransmission
mechanism to work with SRTP or other crypto mechanisms, to avoid confusion down
the road.

>
> 5.-It is also pointed out that the Timestamp of the retransmission
> packets is the same as in the original packets. Since this is random it
> should be no problem for security. Is this assumption correct?

I think that the non-randomness of the initial timestamp of the retransmission
stream is not an issue.  The unpredictability of the initial RTP timestamp makes
a DoS attack more difficult for an attacker who is not able to observe the RTP
flow, but who knows the destination address, destination port number, and SSRC
of that flow.  The same argument could be made for the avt-rtp-retranmission
mechanism.  If the attacker can't see the original flow, she can't predict the
initial timestamp of the retransmission flow.  If she can see the original flow,
then there is no protection provided by having random timestamp on either flow.
So there is no disadvantage to the avt-rtp-retransmission mechanism's re-use of
the initial timestamp.

David

>
> Thanks in advance,
>
>
> José
>
>
> PS: by the way, in draft-05 Rolf Blom's email is the same as Mark
> Baugher's. Probably a cut&paste error.

Or maybe a subtle identity theft? :-)

David

>
>

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt


Gmane