draft-ietf-avt-rtp-retransmission-01.txt   draft-ietf-avt-rtp-retransmission-02.txt 
David Leon David Leon
Internet Draft Viktor Varsa Internet Draft Viktor Varsa
Document: Nokia Document: Nokia
draft-ietf-avt-rtp-retransmission-01.txt draft-ietf-avt-rtp-retransmission-02.txt
Expires: December 2002 June 2002 Expires: December 2002 June 2002
RTP retransmission framework RTP retransmission framework
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 43 skipping to change at line 43
real-time applications with relaxed delay bounds. real-time applications with relaxed delay bounds.
This document describes an RTP retransmission framework. It defines This document describes an RTP retransmission framework. It defines
a payload format for retransmitted packets and recommends rules for a payload format for retransmitted packets and recommends rules for
sending these packets. Retransmitted RTP packets are sent in a sending these packets. Retransmitted RTP packets are sent in a
separate stream from the original RTP stream. It is assumed that separate stream from the original RTP stream. It is assumed that
feedback from receivers to senders indicating the occurred packet feedback from receivers to senders indicating the occurred packet
losses is available by some means not defined here. losses is available by some means not defined here.
Main changes Main changes
*since draft-ietf-avt-rtp-retransmission-01.txt
IANA considerations section added
New appendix on RTP retransmission and multiplexing. It results from
a discussion on mailing list.
*since draft-ietf-avt-rtp-retransmission-00.txt: *since draft-ietf-avt-rtp-retransmission-00.txt:
An applicability statement was added. An applicability statement was added.
The security considerations section was expanded. The security considerations section was expanded.
Leon, Varsa IETF draft - Expires September 2002 1
RTP retransmission framework June 2002
*since draft-leon-rtp-retransmission-02.txt: *since draft-leon-rtp-retransmission-02.txt:
The previous version of the draft described the use of the The previous version of the draft described the use of the
redundancy payload format (RFC 2198) in order to send retransmission redundancy payload format (RFC 2198) in order to send retransmission
Leon, Varsa IETF draft - Expires September 2002 1
RTP retransmission framework June 2002
data and original data in the same stream. At IETF #53, it was data and original data in the same stream. At IETF #53, it was
concluded that RFC 2198 was not intended to such a use. Piggybacking concluded that RFC 2198 was not intended to such a use. Piggybacking
retransmitted packets was thus removed from the draft. retransmitted packets was thus removed from the draft.
Table of Contents Table of Contents
Abstract...........................................................1 Abstract...........................................................1
Main changes.......................................................1 Main changes.......................................................1
1. Introduction....................................................2 1. Introduction....................................................2
2. Terminology.....................................................3 2. Terminology.....................................................3
3. Applicability statement.........................................3 3. Applicability statement.........................................3
4. Retransmission framework basic principles.......................4 4. Retransmission framework basic principles.......................4
5. Retransmission payload format...................................5 5. Retransmission payload format...................................5
6. Use with the Extended RTP profile for RTCP-based feedback.......6 6. Use with the Extended RTP profile for RTCP-based feedback.......6
7. Congestion control..............................................8 7. Congestion control..............................................8
8. Example scenario of unicast streaming...........................8 8. Example scenario of unicast streaming...........................9
9. SDP usage.......................................................9 9. SDP usage.......................................................9
10. Security consideration.........................................9 10. IANA considerations............................................9
Appendix: FEC for retransmission..................................10 11. Security consideration........................................11
References........................................................11 Appendix A: Retransmission and SSRC multiplexing..................12
Author's Addresses................................................11 Appendix B: FEC for retransmission................................13
References........................................................14
Author's Addresses................................................15
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 signal. Several techniques, such degrade the quality of the received signal. Several techniques, such
as forward error correction (FEC), retransmissions or application as forward error correction (FEC), retransmissions or application
layer (e.g. video) error resilience adaptation based on back-channel layer (e.g. video) error resilience adaptation based on back-channel
messages may be considered to increase the robustness to packet messages may be considered to increase the robustness to packet
loss. RFC-2354 [1] discusses the different options. loss. RFC-2354 [1] discusses the different options.
When choosing a technique for a particular system, the tolerable When choosing a technique for a particular system, the tolerable
latency of the application has to be taken into account. In the case 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 of multimedia conferencing, the end-to-end delay has to be at most a
few hundred milliseconds in order to guarantee interactivity, which few hundred milliseconds in order to guarantee interactivity, which
usually excludes the use of retransmission. On the other hand, in usually excludes the use of retransmission. On the other hand, in
the case of multimedia streaming, the user can tolerate an initial the case of multimedia streaming, the user can tolerate an initial
latency as part of the session setup and thus an end-to-end delay of latency as part of the session setup and thus an end-to-end delay of
several seconds is possible. Retransmission may thus be considered several seconds is possible. Retransmission may thus be considered
for such applications. for such applications.
Leon, Varsa - Expires December 2002 2
RTP retransmission framework June 2002
This document proposes a retransmission framework. It defines a This document proposes a retransmission framework. It defines a
payload format for retransmitted RTP packets and retransmission payload format for retransmitted RTP packets and retransmission
rules. This RTP retransmission scheme requires frequent packet loss rules. This RTP retransmission scheme requires frequent packet loss
indication feedback to the RTP entity performing retransmission. The indication feedback to the RTP entity performing retransmission. The
AV profile [2] does not provide this feature and could therefore not AV profile [2] does not provide this feature and could therefore not
be used. However, the retransmission scheme could be run under the be used. However, the retransmission scheme could be run under the
Leon, Varsa - Expires December 2002 2
RTP retransmission framework June 2002
extended RTP profile for RTCP-based feedback[3] which defines a NACK extended RTP profile for RTCP-based feedback[3] which defines a NACK
message that can be sent as part of a compound RTCP packet. message that can be sent as part of a compound RTCP packet.
2. Terminology 2. Terminology
The following terms are used in this document: The following terms are used in this document:
Original packet: refers to an RTP packet which carries user data Original packet: refers to an RTP packet which carries user data
sent for the first time by an RTP sender. sent for the first time by an RTP sender.
skipping to change at line 151 skipping to change at line 156
This draft enables the receiver to perform reliable loss detection This draft enables the receiver to perform reliable loss detection
of user data, i.e. the receiver can differentiate between lost of user data, i.e. the receiver can differentiate between lost
packets sent for first time and lost retransmissions. packets sent for first time and lost retransmissions.
Reliable user data loss detection is required for example in RTP Reliable user data loss detection is required for example in RTP
conversational text (RFC 2793) in order to indicate missing text to conversational text (RFC 2793) in order to indicate missing text to
the user. For some applications, reliable loss detection of user the user. For some applications, reliable loss detection of user
data may not be strictly required but may enhance a receiver data may not be strictly required but may enhance a receiver
performance. performance.
Leon, Varsa - Expires December 2002 3
RTP retransmission framework June 2002
This retransmission algorithm allows receivers to trade-off the This retransmission algorithm allows receivers to trade-off the
playout delay versus the number of retransmissions for a given playout delay versus the number of retransmissions for a given
packet. This delay does not need to be signalled to the sender and packet. This delay does not need to be signalled to the sender and
can be changed dynamically during the session in order to adapt to can be changed dynamically during the session in order to adapt to
varying network conditions. Receivers should choose whether to varying network conditions. Receivers should choose whether to
request a missing packet based on an estimation of its timestamp request a missing packet based on an estimation of its timestamp
Leon, Varsa - Expires December 2002 3
RTP retransmission framework June 2002
which is usually obtained from the observed correlation between the which is usually obtained from the observed correlation between the
RTP sequence number and timestamp. Implementers should carefully RTP sequence number and timestamp. Implementers should carefully
design their decision retransmission request algorithm in order to design their decision retransmission request algorithm in order to
limit the risk of unnecessary retransmission. limit the risk of unnecessary retransmission.
This retransmission scheme requires a separate RTP session to send This retransmission scheme requires a separate RTP session to send
retransmitted packets. As a consequence, two additional ports are retransmitted packets. As a consequence, two additional ports are
needed: one port for the RTP retransmission stream and one port for needed: one port for the RTP retransmission stream and one port for
the associated RTCP. While this is generally not a problem, the the associated RTCP. While this is generally not a problem, the
implementers should assess the implications in the targeted implementers should assess the implications in the targeted
skipping to change at line 205 skipping to change at line 209
reliable loss detection of user data would not be possible. Reliable reliable loss detection of user data would not be possible. Reliable
data loss detection of user data is mandated for example in RTP data loss detection of user data is mandated for example in RTP
conversational text [6]. conversational text [6].
RTP Timestamp (TS) estimation of missing original packets is RTP Timestamp (TS) estimation of missing original packets is
necessary at the receiver in order to decide whether a necessary at the receiver in order to decide whether a
retransmission is useful or not. A retransmission is useful if the retransmission is useful or not. A retransmission is useful if the
retransmission packet sent as a response to the retransmission retransmission packet sent as a response to the retransmission
request may still be used when it arrives at the receiver. The request may still be used when it arrives at the receiver. The
missing original packet timestamp can be estimated from timestamp of missing original packet timestamp can be estimated from timestamp of
Leon, Varsa - Expires December 2002 4
RTP retransmission framework June 2002
packets preceding and/or following the sequence number gap caused by packets preceding and/or following the sequence number gap caused by
the missing packet in the original stream. the missing packet in the original stream.
The fact that RTP streams for original and retransmission packets do The fact that RTP streams for original and retransmission packets do
not share the same SN space guarantees that the RTP timestamp not share the same SN space guarantees that the RTP timestamp
estimation method is reliable. Reliability would be sacrificed if estimation method is reliable. Reliability would be sacrificed if
original and retransmission packets were sent in the same RTP stream original and retransmission packets were sent in the same RTP stream
as the timestamp estimate for a lost retransmission packet would as the timestamp estimate for a lost retransmission packet would
Leon, Varsa - Expires December 2002 4
RTP retransmission framework June 2002
then be incorrect. This is because the retransmission packet usually then be incorrect. This is because the retransmission packet usually
has a smaller "out-of-order" timestamp than the timestamp of the has a smaller "out-of-order" timestamp than the timestamp of the
consecutive original packets. consecutive original packets.
When the retransmission stream is sent to a multicast RTP session, When the retransmission stream is sent to a multicast RTP session,
receivers may choose whether to subscribe or not to the RTP session receivers may choose whether to subscribe or not to the RTP session
carrying the retransmission stream. Therefore, a multicast streaming carrying the retransmission stream. Therefore, a multicast streaming
application can use retransmission and still be backwards compatible application can use retransmission and still be backwards compatible
as receivers which do not implement the retransmission payload as receivers which do not implement the retransmission payload
format only join the RTP session carrying the original stream. A format only join the RTP session carrying the original stream. A
skipping to change at line 258 skipping to change at line 262
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| OPT | OSN | | |E| OPT | OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload | | Original RTP Packet Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leon, Varsa - Expires December 2002 5
RTP retransmission framework June 2002
RTP header usage: RTP header usage:
The same SSRC value SHOULD be used for the original stream and the The same SSRC value SHOULD be used for the original stream and the
retransmission stream. In the RTP header, SN has the standard retransmission stream. In the RTP header, SN has the standard
definition, i.e. it MUST be one higher than the sequence number of definition, i.e. it MUST be one higher than the sequence number of
the preceding retransmission packet. The payload type is dynamic and the preceding retransmission packet. The payload type is dynamic and
indicates the use of the retransmission payload format. All other indicates the use of the retransmission payload format. All other
fields of the RTP header have the same value as in the original RTP fields of the RTP header have the same value as in the original RTP
packet. packet.
Leon, Varsa - Expires December 2002 5
RTP retransmission framework June 2002
The retransmission packet payload carries an E bit, an OPT field (7 The retransmission packet payload carries an E bit, an OPT field (7
bits) and an OSN field (2 bytes) followed by the original RTP packet bits) and an OSN field (2 bytes) followed by the original RTP packet
payload. The E bit is an extension bit for future-proofing. It MUST payload. The E bit is an extension bit for future-proofing. It MUST
be set to zero. The OPT field is the payload type of the original be set to zero. The OPT field is the payload type of the original
packet payload that is being retransmitted. The OSN field is the packet payload that is being retransmitted. The OSN field is the
sequence number of the original packet that originally carried the sequence number of the original packet that originally carried the
same payload. same payload.
6. Use with the Extended RTP profile for RTCP-based feedback 6. Use with the Extended RTP profile for RTCP-based feedback
skipping to change at line 292 skipping to change at line 296
When the Extended RTP profile for RTCP-based feedback [4] is used, When the Extended RTP profile for RTCP-based feedback [4] is used,
it is RECOMMENDED that receivers send retransmission requests it is RECOMMENDED that receivers send retransmission requests
according to the rules in this section. The rules described according to the rules in this section. The rules described
hereafter aim at limiting the maximum delay before a retransmission hereafter aim at limiting the maximum delay before a retransmission
request can be sent and are compliant to the more general rules request can be sent and are compliant to the more general rules
described in the profile itself. described in the profile itself.
The NACK message format defined in the profile should be used. Early The NACK message format defined in the profile should be used. Early
RTCP packets should not be used and the NACK message should always RTCP packets should not be used and the NACK message should always
be appended to a regularly scheduled compound RTCP packet that is be appended to a regularly scheduled compound RTCP packet that is
sent at every RTCP report interval T_rr. sent at every RTCP report interval.
Any other rules to send feedback may be used as long as they are Any other rules to send feedback may be used as long as they are
compliant with the profile. In particular, a receiver may send NACK compliant with the profile. In particular, a receiver may send NACK
messages in early RTCP packets. However, in that case the time when messages in early RTCP packets. However, in that case the time when
the next RTCP packet following this early RTCP packet can be sent the next RTCP packet following this early RTCP packet can be sent
could be too late to report a loss occurring right after the early could be too late to report a loss occurring right after the early
RTCP packet was sent. Sending RTCP packets at regular intervals RTCP packet was sent. Sending RTCP packets at regular intervals
guarantees that the delay between detecting an original packet loss guarantees that the delay between detecting an original packet loss
and being able to send a NACK message for that packet is no longer and being able to send a NACK message for that packet is no longer
than the RTCP interval. than the RTCP interval.
6.2 Receiver algorithm for generating retransmission requests 6.2 Receiver algorithm for generating retransmission requests
This section gives some general guidelines on how a receiver should This section gives some general guidelines on how a receiver should
decide whether or not to request a packet retransmission. An actual decide whether or not to request a packet retransmission. An actual
receiver implementation should take into account such factors as the receiver implementation should take into account such factors as the
network environment and the media type. network environment and the media type.
A receiver should compute an estimate of the delay D to receive a
retransmission packet after a NACK message has been sent. This
estimate may be obtained from past observations, RTCP report round-
trip time if available or any other means.
The minimum receiver buffering delay B (i.e. the time between a
packet is received and its payload is used at the receiver) is the
RTCP reporting interval added to the delay estimate D, which
guarantees that a retransmission packet sent as a response to a
Leon, Varsa - Expires December 2002 6 Leon, Varsa - Expires December 2002 6
RTP retransmission framework June 2002 RTP retransmission framework June 2002
retransmission request can be received before its payload is used. A receiver should compute an estimate of the retransmission delay to
i.e. B>T_rr+D receive a retransmission packet after a NACK message has been sent.
This estimate may be obtained from past observations, RTCP report
round-trip time if available or any other means.
The minimum receiver buffering delay (i.e. the time between a packet
is received and its payload is used at the receiver) is the RTCP
reporting interval added to the retransmission delay estimate. This
delay guarantees that a retransmission packet sent as a response to
a retransmission request can be received before its payload is used.
It can be seen that the needed receiver buffering delay is dependent It can be seen that the needed receiver buffering delay is dependent
on the amount of RTCP traffic allowed in the session. It is on the amount of RTCP traffic allowed in the session. It is
illustrated in Section 8 that moderate RTCP feedback traffic is illustrated in Section 8 that moderate RTCP feedback traffic is
enough to perform retransmission with reasonable receiver buffering enough to perform retransmission with reasonable receiver buffering
delay. delay.
A receiver should maintain a list of missing original packet A receiver should maintain a list of missing original packet
sequence numbers. A receiver needs also to store for each missing sequence numbers. A receiver needs also to store for each missing
original packet an estimated RTP timestamp as described in Section original packet an estimated RTP timestamp as described in Section
skipping to change at line 367 skipping to change at line 369
original packet sequence number depends on the receiver buffering original packet sequence number depends on the receiver buffering
delay. delay.
The receiver should upon reception of a retransmission packet remove The receiver should upon reception of a retransmission packet remove
the corresponding original packet sequence number(OSN in the the corresponding original packet sequence number(OSN in the
retransmission payload format) from the list of missing sequence retransmission payload format) from the list of missing sequence
numbers. numbers.
6.3 RTCP sending rules in the retransmission RTP session 6.3 RTCP sending rules in the retransmission RTP session
Leon, Varsa - Expires December 2002 7
RTP retransmission framework June 2002
Since the original stream and the retransmission stream are carried Since the original stream and the retransmission stream are carried
in separate RTP sessions, the retransmission stream has its own RTCP in separate RTP sessions, the retransmission stream has its own RTCP
stream as well. The amount of RTCP sent for the retransmission stream as well. The amount of RTCP sent for the retransmission
stream is computed as a fraction of the retransmission RTP session stream is computed as a fraction of the retransmission RTP session
bandwidth. Since the retransmission traffic is limited, the overhead bandwidth. Since the retransmission traffic is limited, the overhead
caused by the additional RTCP packets in the retransmission RTP caused by the additional RTCP packets in the retransmission RTP
session is moderate. For example, assuming a 64 kbps original RTP session is moderate. For example, assuming a 64 kbps original RTP
session and on average 3% packet loss and all lost original packets session and on average 3% packet loss and all lost original packets
retransmitted once, the bandwidth of the retransmission RTP session retransmitted once, the bandwidth of the retransmission RTP session
Leon, Varsa - Expires December 2002 7
RTP retransmission framework June 2002
would be about 2 kbps. In this case the recommended RTCP traffic for would be about 2 kbps. In this case the recommended RTCP traffic for
the retransmission RTP session would be 0.1 kbps. the retransmission RTP session would be 0.1 kbps.
Early RTCP packets and RTCP feedback messages SHOULD NOT be used in Early RTCP packets and RTCP feedback messages SHOULD NOT be used in
the retransmission RTP session. the retransmission RTP session.
7. Congestion control 7. Congestion control
RTP retransmission poses a risk of increased network congestion. In RTP retransmission poses a risk of increased network congestion. In
a best-effort environment, packet loss is caused by congestion. a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmitting older packets in addition to the Reacting to loss by retransmission of older packets in addition to
current data would thus further increase congestion. Implementations the current data would thus further increase congestion.
SHOULD follow the recommendations below in order to use Implementations SHOULD follow the recommendations below in order to
retransmission. use retransmission.
The RTP profile under which the retransmission scheme is used The RTP profile under which the retransmission scheme is used
defines an appropriate congestion control mechanism in different defines an appropriate congestion control mechanism in different
environments. Following the rules under the profile, an RTP environments. Following the rules under the profile, an RTP
application can determine its acceptable bitrate and packet rate in application can determine its acceptable bitrate and packet rate in
order to be fair to other applications such as TCP flows and other order to be fair to other applications such as TCP flows and other
RTP flows. RTP flows.
If an RTP application uses retransmission, the acceptable packet If an RTP application uses retransmission, the acceptable packet
rate and bitrate SHOULD include both the original and retransmitted rate and bitrate SHOULD include both the original and retransmitted
skipping to change at line 423 skipping to change at line 424
bitrate of the original stream (for example by encoding the data at bitrate of the original stream (for example by encoding the data at
a lower rate). a lower rate).
In addition, the sender MAY retransmit only the packets that it In addition, the sender MAY retransmit only the packets that it
deems important and ignore NACK messages for other packets in order deems important and ignore NACK messages for other packets in order
to limit the bitrate to limit the bitrate
These congestion control mechanisms should keep the congestion level These congestion control mechanisms should keep the congestion level
under an acceptable limit. This would in turn guarantee that the under an acceptable limit. This would in turn guarantee that the
packet loss should be moderate. Too high a packet loss would mean packet loss should be moderate. Too high a packet loss would mean
Leon, Varsa - Expires December 2002 8
RTP retransmission framework June 2002
that congestion is not kept under control and retransmission should that congestion is not kept under control and retransmission should
then not be used. then not be used.
8. Example scenario of unicast streaming 8. Example scenario of unicast streaming
Let us assume that the RTP session bandwidth is 64 kbps and the Let us assume that the RTP session bandwidth is 64 kbps and the
receiver buffering delay is 3 seconds. The network round trip time receiver buffering delay is 3 seconds. The network round trip time
is 500 ms and Receiver RTCP packets (including NACK messages ) are is 500 ms and Receiver RTCP packets (including NACK messages ) are
Leon, Varsa - Expires December 2002 8
RTP retransmission framework June 2002
sent at 2-second intervals. With these time limitations, when the sent at 2-second intervals. With these time limitations, when the
receiver algorithm for generating retransmission requests described receiver algorithm for generating retransmission requests described
in Section 6.2 is followed, only one request per packet loss can be in Section 6.2 is followed, only one request per packet loss can be
sent. Let us assume an original packet rate of 50 packets per second sent. Let us assume an original packet rate of 50 packets per second
(1 packet every 20 ms). At this packet rate, with the packet loss (1 packet every 20 ms). At this packet rate, with the packet loss
distribution worst case scenario where every 17th original packet is distribution worst case scenario where every 17th original packet is
lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages lost (i.e. 5.88% uniform packet loss), a maximum of 6 NACK messages
need to be appended to the RTCP compound packet that is sent every 2 need to be appended to the RTCP compound packet that is sent every 2
seconds. The 6 NACK messages can report any packet losses in an SN seconds. The 6 NACK messages can report any packet losses in an SN
range of 6*17=102, thus the number of required NACK messages would range of 6*17=102, thus the number of required NACK messages would
skipping to change at line 460 skipping to change at line 461
The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+ The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+
RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The
needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP
bandwidth is well below the recommended RTCP bandwidth. The receiver bandwidth is well below the recommended RTCP bandwidth. The receiver
RTCP recommended bandwidth in an RTP session with 64 kbps is about RTCP recommended bandwidth in an RTP session with 64 kbps is about
0.25*64 = 1.6 kbps. 0.25*64 = 1.6 kbps.
9. SDP usage 9. SDP usage
The binding to the payload type number is indicated by an rtpmap The binding to the payload type number is indicated by an rtpmap
attribute. The name used in the binding is "RTX". attribute. The name used in the binding is "rtx".
An SDP example is shown below:
c=IN IP4 113.3.12.11 c=IN IP4 113.3.12.11
m=video 49170 RTP/AVPF 96 m=video 49170 RTP/AVPF 96
a=rtpmap:96 H263-1998/90000 a=rtpmap:96 H263-1998/90000
a=fmtp:96 rtcp-fb nack a=fmtp:96 rtcp-fb nack
m=video 49172 RTP/AVPF 97 m=video 49172 RTP/AVPF 97
a=rtpmap:97 RTX/90000 a=rtpmap:97 rtx/90000
10. Security consideration 10. IANA considerations
10.1 Registration of audio/rtx
MIME type: audio
Leon, Varsa - Expires December 2002 9
RTP retransmission framework June 2002
MIME subtype: rtx
Required parameters: rate
The RTP timestamp clockrate is equal to the RTP timestamp clockrate
of the media that is retransmitted.
Optional parameters: none
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 11
Interoperability considerations: none
Published specification: RFC xxx
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
david.leon@nokia.com
Intended usage: COMMON
Author/Change controller: David Leon
10.2 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.
Optional parameters: none
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 11
Interoperability considerations: none
Published specification: RFC xxx
Applications which use this media type: multimedia streaming
applications
Additional information: none
Leon, Varsa - Expires December 2002 10
RTP retransmission framework June 2002
Person & email address to contact for further information:
David.leon@nokia.com
Intended usage: COMMON
Author/Change controller: David Leon
10.3 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.
Optional parameters: none
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 11
Interoperability considerations: none
Published specification: RFC xxx
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
David.leon@nokia.com
Intended usage: COMMON
Author/Change controller: David Leon
11. Security consideration
Retransmission and FEC [7] have similar security conditions as far Retransmission and FEC [7] have similar security conditions as far
as encryption and congestion control are concerned. as encryption and congestion control are concerned.
Applications utilizing encryption SHOULD encrypt both the original Applications utilizing encryption SHOULD encrypt both the original
and the retransmission stream. Old keys will likely need to be and the retransmission stream. Old keys will likely need to be
cached so that when the keys change for the original stream, the old 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 key is used until it is determined that the key has changed on the
retransmission packets as well. retransmission packets as well.
Congestion control considerations with the use of retransmission are Congestion control considerations with the use of retransmission are
dealt with in Section 7 of this document. dealt with in Section 7 of this document.
Leon, Varsa - Expires December 2002 11
RTP retransmission framework June 2002
Any other security considerations of the profile under which the Any other security considerations of the profile under which the
retransmission scheme is used should be applied. retransmission scheme is used should be applied.
Leon, Varsa - Expires December 2002 9 Appendix A: Retransmission and SSRC multiplexing
In this document, it is required that two separate RTP streams with
their own sequence number space be used for the original stream and
the retransmission stream. This should be achieved by sending the
RTP stream and its associated retransmission stream to different
ports.
Another way the original and the retransmission stream could be
multiplexed is through the use of different SSRCs if these streams
are sent to the same port.
In general, SSRC multiplexing is not feasible as in a multicast
group it would not be possible to associate an original stream and
its retransmission stream since the SSRC is a random number chosen
by the RTP sender.
However, in unicast this should not be an issue if exactly one RTP
stream and its retransmission stream are multiplexed based on their
SSRC. Since the receiver knows the payload types used by the
original stream and the retransmission stream, it would be able to
derive which SSRC maps to the original data and which SSRC maps to
retransmissions.
SSRC multiplexing should generally be avoided as discussed in
Section 5.2 of RTP [5]. One of the advantage of multiplexing at the
transport layer (i.e. based on the IP address or port number) is the
use of different network paths or resources for different streams.
However, in the case of unicast retransmission, it is the same media
sent in both the original and the retransmission.
It also has to be noted that the SSRC-multiplexing approach is
allowed in FEC [7]. Section 3 of FEC states "This document does not
prescribe the definition of "separate streams", but leaves this to
applications and higher level protocols to define. For multicast,
the separate stream may be implemented by separate multicast groups,
different ports in the same group, or by a different SSRC within the
same group/port. For unicast, different ports or different SSRC may
be used. Each of these approaches has drawbacks and benefits which
depend on the application".
This retransmission draft recommends the following rules:
Separate addresses and/or ports must be used in the multicast case
and should be used in the unicast case to multiplex the original
stream and the retransmission stream. In the unicast case, exactly
one RTP stream and its associated retransmission stream may be sent
to the same port and multiplexed based on their SSRCs
The motivation not to prevent SSRC multiplexing is to minimise the
number of ports usage when it may be a performance issue for high-
scale RTP servers and/or middle-ware proxies while allowing the
Leon, Varsa - Expires December 2002 12
RTP retransmission framework June 2002 RTP retransmission framework June 2002
Appendix: FEC for retransmission original and the retransmitted data to be sent into separate RTP
streams with their own sequence number spaces.
Appendix B: FEC for retransmission
It is possible to retransmit the payload of an original packet by It is possible to retransmit the payload of an original packet by
sending a FEC packet as defined in [7] instead of using the sending a FEC packet as defined in [7] instead of using the
retransmission payload format. The base sequence number of the FEC retransmission payload format. The base sequence number of the FEC
header is the sequence number of the original packet that carried header is the sequence number of the original packet that carried
the same payload and the mask is set to zero. There are some the same payload and the mask is set to zero. There are some
advantages in using the FEC payload format in particular in advantages in using the FEC payload format in particular in
multicast sessions as a single FEC packet may repair the loss of multicast sessions as a single FEC packet may repair the loss of
different packets at different receivers. In a multicast session, different packets at different receivers. In a multicast session,
FEC may be combined with retransmission requests as described in [8] FEC may be combined with retransmission requests as described in [8]
skipping to change at line 534 skipping to change at line 698
of higher delay. If a sender uses proactive FEC and none of the of higher delay. If a sender uses proactive FEC and none of the
packets protected by a given FEC packet is lost, there is then no packets protected by a given FEC packet is lost, there is then no
use of the FEC packet at the receiver. On the other hand, data which use of the FEC packet at the receiver. On the other hand, data which
are retransmitted are known to have been lost. are retransmitted are known to have been lost.
Therefore, a receiver may wish to use only retransmission and not Therefore, a receiver may wish to use only retransmission and not
receive any proactive FEC from the sender in order to trade-off receive any proactive FEC from the sender in order to trade-off
itself the buffering delay, the data-loss rate and the overhead. itself the buffering delay, the data-loss rate and the overhead.
There is thus a motivation to let the receiver decide at session There is thus a motivation to let the receiver decide at session
setup whether the sender may send proactive FEC or retransmission setup whether the sender may send proactive FEC or retransmission
only. only.
Leon, Varsa - Expires December 2002 13
RTP retransmission framework June 2002
If the same payload format were used for these different purposes, If the same payload format were used for these different purposes,
the receiver would not know at session establishment which repair the receiver would not know at session establishment which repair
mechanism is used by the sender (without defining out-of-band mechanism is used by the sender (without defining out-of-band
signalling). The sender would decide by itself whether FEC or signalling). The sender would decide by itself whether FEC or
retransmission (or both) is used and the receiver would not know retransmission (or both) is used and the receiver would not know
Leon, Varsa - Expires December 2002 10
RTP retransmission framework June 2002
until receiving the FEC packets whether proactive FEC or until receiving the FEC packets whether proactive FEC or
retransmission is used. retransmission is used.
On the other hand, having different payload formats or at least On the other hand, having different payload formats or at least
different out of band signalling for these two repair mechanisms different out of band signalling for these two repair mechanisms
(e.g. through defining the binding name 'RTX' SDP rtpmap attribute) (e.g. through defining the binding name 'RTX' SDP rtpmap attribute)
would allow the receiver to choose which mechanism to use (among would allow the receiver to choose which mechanism to use (among
those supported by the sender). The receiver would then have an those supported by the sender). The receiver would then have an
explicit way to tell the sender not to send proactive FEC. explicit way to tell the sender not to send proactive FEC.
Furthermore, if the receiver did not know at session establishment Furthermore, if the receiver did not know at session establishment
whether it will receive FEC packets or retransmission, it would have whether it will receive FEC packets or retransmission, it would have
skipping to change at line 586 skipping to change at line 750
6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000
7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss
recovery for reliable multicast transmission", ACM SIGCOMM'97, recovery for reliable multicast transmission", ACM SIGCOMM'97,
Cannes, France, September 1997 Cannes, France, September 1997
Leon, Varsa - Expires December 2002 14
RTP retransmission framework June 2002
Author's Addresses Author's Addresses
David Leon David Leon
Leon, Varsa - Expires December 2002 11
RTP retransmission framework June 2002
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1860 6000 Connection Drive Phone: 1-972-374-1860
Irving, TX. USA Email: david.leon@nokia.com Irving, TX. USA Email: david.leon@nokia.com
Viktor Varsa Viktor Varsa
Nokia Research Center Nokia Research Center
6000 Connection Drive Phone: 1-972-374-1861 6000 Connection Drive Phone: 1-972-374-1861
Irving, TX. USA Email: viktor.varsa@nokia.com Irving, TX. USA Email: viktor.varsa@nokia.com
Leon, Varsa - Expires December 2002 12 Leon, Varsa - Expires December 2002 15
 End of changes. 

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