draft-ietf-avt-rtp-retransmission-05.txt   draft-ietf-avt-rtp-retransmission-06.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission-05.txt J. Rey/Matsushita draft-ietf-avt-rtp-retransmission-06.txt J. Rey/Matsushita
D. Leon/Nokia D. Leon/Nokia
A. Miyazaki/Matsushita A. Miyazaki/Matsushita
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Matsushita R. Hakenberg/Matsushita
Expires: August 2003 February 2003 Expires: August 2003 February 2003
RTP Retransmission Payload Format RTP Retransmission Payload Format
Status of this Memo Status of this Memo
skipping to change at page 3, line 4 skipping to change at page 2, line 24
6. Use with the extended RTP profile for RTCP-based feedback......10 6. Use with the extended RTP profile for RTCP-based feedback......10
7. Congestion control.............................................12 7. Congestion control.............................................12
8. Retransmission Payload Format MIME type registration...........13 8. Retransmission Payload Format MIME type registration...........13
9. RTSP considerations............................................19 9. RTSP considerations............................................19
10. Implementation examples.......................................20 10. Implementation examples.......................................20
11. IANA considerations...........................................23 11. IANA considerations...........................................23
12. Security considerations.......................................23 12. Security considerations.......................................23
13. Acknowledgements..............................................24 13. Acknowledgements..............................................24
14. References....................................................24 14. References....................................................24
Author's Addresses................................................25 Author's Addresses................................................25
15. IPR Notices...................................................26
16. Full Copyright Statement......................................26
1. Introduction 1. Introduction
Packet losses between an RTP sender and receiver may significantly Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received media. Several techniques, such degrade the quality of the received media. Several techniques, such
as forward error correction (FEC), retransmissions or interleaving as forward error correction (FEC), retransmissions or interleaving
may be considered to increase packet loss resiliency. RFC 2354 [8] may be considered to increase packet loss resiliency. RFC 2354 [8]
discusses the different options. discusses the different options.
When choosing a repair technique for a particular application, the When choosing a repair technique for a particular application, the
skipping to change at page 8, line 34 skipping to change at page 8, line 34
retransmission packet SHOULD carry the same header extension. This retransmission packet SHOULD carry the same header extension. This
header extension MUST be placed right after the fixed RTP header, as header extension MUST be placed right after the fixed RTP header, as
specified in RTP [3]. In this case, the retransmission payload specified in RTP [3]. In this case, the retransmission payload
header is thus placed after the header extension. header is thus placed after the header extension.
If the original RTP packet contained RTP padding, that padding MUST If the original RTP packet contained RTP padding, that padding MUST
be removed before constructing the retransmission packet. If be removed before constructing the retransmission packet. If
padding of the retransmission packet is needed, padding is performed padding of the retransmission packet is needed, padding is performed
as with any RTP packets and the padding bit is set. as with any RTP packets and the padding bit is set.
The M, CC and CSRC bit of the original RTP header MUST remain The M, CC and CSRC bit of the original RTP header MUST be copied "as
unchanged in the retransmission packet. is" into the RTP header of the retransmission packet.
5. Association of a retransmission stream with its original stream 5. Association of a retransmission stream with its original stream
5.1 Retransmission session sharing 5.1 Retransmission session sharing
In the case of session-multiplexing, a retransmission session MUST In the case of session-multiplexing, a retransmission session MUST
map to exactly one original session, i.e. the same retransmission map to exactly one original session, i.e. the same retransmission
session cannot be used for different original sessions. session cannot be used for different original sessions.
If retransmission session sharing were allowed, it would be a If retransmission session sharing were allowed, it would be a
skipping to change at page 17, line 30 skipping to change at page 17, line 30
David Leon David Leon
IETF AVT WG IETF AVT WG
8.6 Mapping to SDP 8.6 Mapping to SDP
The information carried in the MIME media type specification has a The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is used to specify retransmissions describe RTP sessions. When SDP is used to specify retransmissions
for an RTP stream, the mapping is done as follows: for an RTP stream, the mapping is done as follows:
- The MIME types ("video"), ("audio") and ("text") go in the SDP - The MIME types ("video"), ("audio"), ("text") and ("application")
"m=" as the media name. go in the SDP "m=" as the media name.
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be that of the name. The RTP clock rate in "a=rtpmap" MUST be that of the
retransmission payload type. See Section 4 for details on this. retransmission payload type. See Section 4 for details on this.
- The AVPF profile-specific parameters "ack" and "nack" go in SDP - The AVPF profile-specific parameters "ack" and "nack" go in SDP
"a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of
feedback. See the AVPF profile [1] for details. feedback. See the AVPF profile [1] for details.
- The retransmission payload-format-specific parameters "apt" and - The retransmission payload-format-specific parameters "apt" and
skipping to change at page 18, line 13 skipping to change at page 18, line 13
one media specification "m" line per RTP session. The SDP MUST one media specification "m" line per RTP session. The SDP MUST
provide the grouping of the original and associated retransmission provide the grouping of the original and associated retransmission
sessions' "m" lines, using the Flow Identification (FID) semantics sessions' "m" lines, using the Flow Identification (FID) semantics
defined in RFC 3388 [6]. defined in RFC 3388 [6].
The following example specifies two original, AMR and MPEG-4, The following example specifies two original, AMR and MPEG-4,
streams on ports 49170 and 49174 and their corresponding streams on ports 49170 and 49174 and their corresponding
retransmission streams on ports 49172 and 49176, respectively: retransmission streams on ports 49172 and 49176, respectively:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 125.25.5.1 c=IN IP4 192.0.2.0
a=group:FID 1 2 a=group:FID 1 2
a=group:FID 3 4 a=group:FID 3 4
m=audio 49170 RTP/AVPF 96 m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000 a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1 a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=mid:1 a=mid:1
m=audio 49172 RTP/AVPF 97 m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000 a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
skipping to change at page 18, line 46 skipping to change at page 18, line 46
A special case of the SDP description is a description that contains A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session only one original session "m" line and one retransmission session
"m" line, the grouping is then obvious and FID semantics MAY be "m" line, the grouping is then obvious and FID semantics MAY be
omitted in this special case only. omitted in this special case only.
This is illustrated in the following example, which is an SDP This is illustrated in the following example, which is an SDP
description for a single original MPEG-4 stream and its description for a single original MPEG-4 stream and its
corresponding retransmission session: corresponding retransmission session:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 125.25.5.1 c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
m=video 49172 RTP/AVPF 97 m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
8.8 SDP description with SSRC-multiplexing 8.8 SDP description with SSRC-multiplexing
The following is an example of an SDP description for an RTP video The following is an example of an SDP description for an RTP video
session using SSRC-multiplexing with similar parameters as in the session using SSRC-multiplexing with similar parameters as in the
single-session example above: single-session example above:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 125.25.5.1 c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97 m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
9. RTSP considerations 9. RTSP considerations
The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an
skipping to change at page 20, line 28 skipping to change at page 20, line 28
The session-level "control" attribute is then used as usual to The session-level "control" attribute is then used as usual to
control the playing of the original stream. When the receiver control the playing of the original stream. When the receiver
starts receiving the original stream, it can then request starts receiving the original stream, it can then request
retransmissions through RTCP without additional RTSP signalling. retransmissions through RTCP without additional RTSP signalling.
9.3 RTSP control of the retransmission stream 9.3 RTSP control of the retransmission stream
Because of the nature of retransmissions, the sending of Because of the nature of retransmissions, the sending of
retransmission packets SHOULD NOT be controlled through RTSP PLAY retransmission packets SHOULD NOT be controlled through RTSP PLAY
and PAUSE requests. The PLAY and PAUSE requests should not affect and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect
the retransmission stream. Retransmission packets are sent upon the retransmission stream. Retransmission packets are sent upon
receiver requests in the original RTCP stream, regardless of the receiver requests in the original RTCP stream, regardless of the
state. state.
9.4 Cache control 9.4 Cache control
Retransmission streams SHOULD NOT be cached. Retransmission streams SHOULD NOT be cached.
In the case of session-multiplexing, the "Cache-Control" header In the case of session-multiplexing, the "Cache-Control" header
SHOULD be set to "no-cache" for the retransmission stream. SHOULD be set to "no-cache" for the retransmission stream.
skipping to change at page 21, line 30 skipping to change at page 21, line 30
10.1 A minimal receiver implementation example 10.1 A minimal receiver implementation example
This section gives an example of an implementation supporting This section gives an example of an implementation supporting
multiple retransmissions. The sender transmits the original data in multiple retransmissions. The sender transmits the original data in
RTP packets using the MPEG-4 video RTP payload format. RTP packets using the MPEG-4 video RTP payload format.
It is assumed that NACK feedback messages are used, as per It is assumed that NACK feedback messages are used, as per
[1]. An SDP description example with SSRC-multiplexing is given [1]. An SDP description example with SSRC-multiplexing is given
below: below:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 125.25.5.1 c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97 m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
The format-specific parameter "rtx-time" indicates that the server The format-specific parameter "rtx-time" indicates that the server
will buffer the sent packets in a retransmission buffer for 3.0 will buffer the sent packets in a retransmission buffer for 3.0
seconds, after which the packets are deleted from the retransmission seconds, after which the packets are deleted from the retransmission
buffer and will never be sent again. buffer and will never be sent again.
skipping to change at page 22, line 38 skipping to change at page 22, line 38
and optimise the performance of the implementation by using selective and optimise the performance of the implementation by using selective
requests. requests.
Note that these receiver enhancements do not need to be negotiated as Note that these receiver enhancements do not need to be negotiated as
they do not affect the sender implementation. However, in order to they do not affect the sender implementation. However, in order to
allow the receiver to acknowledge packets, it is needed to allow the 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 use of ACKs in the SDP description, by means of an additional SDP
"a=rtcp-fb" line, as follows: "a=rtcp-fb" line, as follows:
v=0 v=0
o=mascha 2980675221 2980675778 IN IP4 at.home.ru o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 125.25.5.1 c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97 m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000 a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtcp-fb:96 ack a=rtcp-fb:96 ack
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000 a=fmtp:97 apt=96;rtx-time=3000
10.3 Retransmission of Layered Encoded Media in Multicast 10.3 Retransmission of Layered Encoded Media in Multicast
This section shows how to combine retransmissions with layered This section shows how to combine retransmissions with layered
skipping to change at page 23, line 16 skipping to change at page 23, line 16
relative importance of the different original streams. relative importance of the different original streams.
In multicast, SSRC-multiplexing of the original and retransmission In multicast, SSRC-multiplexing of the original and retransmission
streams is not allowed as per Section 5.3 of this document. For this streams is not allowed as per Section 5.3 of this document. For this
reason, the retransmission stream(s) MUST be sent in different RTP reason, the retransmission stream(s) MUST be sent in different RTP
session(s) using session-multiplexing. session(s) using session-multiplexing.
An SDP description example of multicast retransmissions for layered An SDP description example of multicast retransmissions for layered
encoded media is given below: encoded media is given below:
c=IN IP4 224.2.1.1/127/3
m=video 8000 RTP/AVPF 98 m=video 8000 RTP/AVPF 98
c=IN IP4 192.0.2.0/127/3
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
c=IN IP4 224.2.1.4/127/3
m=video 8000 RTP/AVPF 99 m=video 8000 RTP/AVPF 99
c=IN IP4 192.0.2.4/127/3
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000 a=fmtp:99 apt=98;rtx-time=3000
The server and the receiver may implement the retransmission methods The server and the receiver may implement the retransmission methods
illustrated in the previous examples. In addition, they may choose illustrated in the previous examples. In addition, they may choose
to request and retransmit a lost packet depending on the layer it to request and retransmit a lost packet depending on the layer it
belongs to. belongs to.
11. IANA considerations 11. IANA considerations
A new MIME subtype name, "rtx", has been registered. An additional A new MIME subtype name, "rtx", has been registered for four
REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", different media types, as follows: "video", "audio", "text" and
are defined. See Section 8 for details. "application". An additional REQUIRED parameter, "apt", and an
OPTIONAL parameter, "rtx-time", are defined. See Section 8 for
details.
12. Security considerations 12. Security considerations
Applications utilising encryption SHOULD encrypt both the original If cryptography is used to provide security services on the original
and the retransmission stream. Old keys will likely need to be stream, then the same services, with equivalent cryptographic
cached so that when the keys change for the original stream, the old strength, MUST be provided on the retransmission stream. Old keys
key is used until it is determined that the key has changed on the will likely need to be cached so that when the keys change for the
retransmission packets as well. 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 The use of the same key for the retransmitted stream and the
original stream may lead to security problems, e.g. two-time pads. original stream may lead to security problems, e.g. two-time pads.
This sharing has to be evaluated towards the chosen security This sharing has to be evaluated towards the chosen security
protocol and security algorithms. protocol and security algorithms.
RTP recommends that the initial RTP timestamp SHOULD be random to RTP recommends that the initial RTP timestamp SHOULD be random to
secure the stream against known plain text attacks. This payload secure the stream against known plain text attacks. This payload
format does not follow this recommendation as the initial timestamp format does not follow this recommendation as the initial timestamp
will be the media timestamp of the first retransmitted packet. will be the media timestamp of the first retransmitted packet.
skipping to change at page 25, line 21 skipping to change at page 25, line 24
10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk
Data Transfer", RFC 2887, August 2000. Data Transfer", RFC 2887, August 2000.
11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 11 Friedman, et. al., "RTP Extended Reports", Work in Progress.
12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
draft-ietf-avt-srtp-05.txt, June 2002. draft-ietf-avt-srtp-05.txt, June 2002.
13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," BCP 11, RFC 2028, IETF, October 1996.
Author's Addresses Author's Addresses
Jose Rey rey@panasonic.de Jose Rey rey@panasonic.de
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-134 Phone: +49-6103-766-134
Fax: +49-6103-766-166 Fax: +49-6103-766-166
David Leon david.leon@nokia.com David Leon david.leon@nokia.com
skipping to change at page 26, line 4 skipping to change at page 26, line 9
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
Phone: 1-972-374-1861 Phone: 1-972-374-1861
Rolf Hakenberg hakenberg@panasonic.de Rolf Hakenberg hakenberg@panasonic.de
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-162 Phone: +49-6103-766-162
Fax: +49-6103-766-166 Fax: +49-6103-766-166
IPR Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP 11 [13]. Copies
of claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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