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.
6. Use with the Extended RTP Profile for RTCP-based Feedback
This section gives general hints for the usage of this payload format
with the extended RTP profile for RTCP-based feedback, denoted AVPF
[1]. Note that the general RTCP send and receive rules and the RTCP
packet format as specified in RTP apply, except for the changes that
the AVPF profile introduces. In short, the AVPF profile relaxes the
RTCP timing rules and specifies additional general-purpose RTCP
feedback messages. See [1] for details.
6.1. RTCP at the Sender
In the case of session-multiplexing, Sender Report (SR) packets for
the original stream are sent in the original session and SR packets
for the retransmission stream are sent in the retransmission session
according to the rules of RTP.
In the case of SSRC-multiplexing, SR packets for both original and
retransmission streams are sent in the same session according to the
rules of RTP. The original and retransmission streams are seen, as
far as the RTCP bandwidth calculation is concerned, as independent
senders belonging to the same RTP session and are thus equally
sharing the RTCP bandwidth assigned to senders.
Note that in both cases, session- and SSRC-multiplexing, BYE packets
MUST still be sent for both streams as specified in RTP. In other
words, it is not enough to send BYE packets for the original stream
only.
6.2. RTCP Receiver Reports
In the case of session-multiplexing, the receiver will send report
blocks for the original stream and the retransmission stream in
separate Receiver Report (RR) packets belonging to separate RTP
sessions. RR packets reporting on the original stream are sent in
the original RTP session while RR packets reporting on the
retransmission stream are sent in the retransmission session. The
RTCP bandwidth for these two sessions may be chosen independently
(e.g., through RTCP bandwidth modifiers [4]).
In the case of SSRC-multiplexing, the receiver sends report blocks
for the original and the retransmission streams in the same RR packet
since there is a single session.
6.3. Retransmission Requests
The NACK feedback message format defined in the AVPF profile SHOULD
be used by receivers to send retransmission requests. Whether or not
a receiver chooses to request a packet is an implementation issue.
An actual receiver implementation should take into account such
factors as the tolerable application delay, the network environment,
and the media type.
The receiver should generally assess whether the retransmitted packet
would still be useful at the time it is received. The timestamp of
the missing packet can be estimated from the timestamps of packets
preceding and/or following the sequence number gap caused by the
missing packet in the original stream. In most cases, some form of
linear estimate of the timestamp is good enough.
Furthermore, a receiver should compute an estimate of the round-trip
time (RTT) to the sender. This can be done, for example, by
measuring the retransmission delay to receive a retransmission packet
after a NACK has been sent for that packet. This estimate may also
be obtained from past observations, RTCP report round-trip time if
available, or any other means. A standard mechanism for the receiver
to estimate the RTT is specified in "RTP Control Protocol Extended
Reports (RTCP XR)" [11].
The receiver should not send a retransmission request as soon as it
detects a missing sequence number but should add some extra delay to
compensate for packet reordering. This extra delay may, for example,
be based on past observations of the experienced packet reordering.
It should be noted that, in environments where packet reordering is
rare or does not take place, e.g., if the underlying datalink layer
affords ordered delivery, the delay may be extremely low or even take
the value zero. In such cases, an appropriate "reorder delay"
algorithm may not actually be timer based, but packet based. For
example, if n number of packets are received after a gap is detected,
then it may be assumed that the packet was truly lost rather than out
of order. This may turn out to be far easier to code on some
platforms as a very short fixed FIFO packet buffer as opposed to the
timer-based mechanism.
To increase the robustness to the loss of a NACK or of a
retransmission packet, a receiver may send a new NACK for the same
packet. This is referred to as multiple retransmissions. Before
sending a new NACK for a missing packet, the receiver should rely on
a timer to be reasonably sure that the previous retransmission
attempt has failed and so avoid unnecessary retransmissions. The
timer value shall be based on the observed round-trip time. A static
or an adaptive value MAY be used. For example, an adaptive timer
could be one that changes its value with every new request for the
same packet. This document does not provide any guidelines as to how
this adaptive value should be calculated because no experiments have
been done to find this out.
NACKs MUST be sent only for the original RTP stream. Otherwise, if a
receiver wanted to perform multiple retransmissions by sending a NACK
in the retransmission stream, it would not be able to know the
original sequence number and a timestamp estimation of the packet it
requests.
Appendix A gives some guidelines as to how to control the number of
retransmissions.
6.4. Timing Rules
The NACK feedback message may be sent in a regular full compound RTCP
packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK
in an early packet allows reacting more quickly to a given packet
loss. However, in that case if a new packet loss occurs right after
the early RTCP packet was sent, the receiver will then have to wait
for the next regular RTCP compound packet after the early packet.
Sending NACKs only in regular RTCP compound decreases the maximum
delay between detecting an original packet loss and being able to
send a NACK for that packet. Implementers should consider the
possible implications of this fact for the application being used.
Furthermore, receivers may make use of the minimum interval between
regular RTCP compound packets. This interval can be used to keep
regular receiver reporting down to a minimum, while still allowing
receivers to send early RTCP packets during periods requiring more
frequent feedback, e.g., times of higher packet loss rate. Note that
although RTCP packets may be suppressed because they do not contain
NACKs, the same RTCP bandwidth as if they were sent needs to be
available. See AVPF [1] for details on the use of the minimum
interval.
7. Congestion Control
RTP retransmission poses a risk of increasing network congestion. In
a best-effort environment, packet loss is caused by congestion.
Reacting to loss by retransmission of older data without decreasing
the rate of the original stream would thus further increase
congestion. Implementations SHOULD follow the recommendations below
in order to use retransmission.
The RTP profile under which the retransmission scheme is used defines
an appropriate congestion control mechanism in different
environments. Following the rules under the profile, an RTP
application can determine its acceptable bitrate and packet rate in
order to be fair to other TCP or RTP flows.
If an RTP application uses retransmission, the acceptable packet rate
and bitrate include both the original and retransmitted data. This
guarantees that an application using retransmission achieves the same
fairness as one that does not. Such a rule would translate in
practice into the following actions:
If enhanced service is used, it should be made sure that the total
bitrate and packet rate do not exceed that of the requested service.
It should be further monitored that the requested services are
actually delivered. In a best-effort environment, the sender SHOULD
NOT send retransmission packets without reducing the packet rate and
bitrate of the original stream (for example, by encoding the data at
a lower rate).
In addition, the sender MAY selectively retransmit only the packets
that it deems important and ignore NACK messages for other packets in
order to limit the bitrate.
These congestion control mechanisms should keep the packet loss rate
within acceptable parameters. In the context of congestion control,
packet loss is considered acceptable if a TCP flow across the same
network path and experiencing the same network conditions would
achieve, on a reasonable timescale, an average throughput that is not
less than the one the RTP flow achieves. If congestion is not kept
under control, then retransmission SHOULD NOT be used.
Retransmissions MAY still be sent in some cases, e.g., in wireless
links where packet losses are not caused by congestion, if the server
(or the client that makes the retransmission request) estimates that
a particular packet or frame is important to continue play out, or if
an RTSP PAUSE has been issued to allow the buffer to fill up (RTSP
PAUSE does not affect the sending of retransmissions).
Finally, it may further be necessary to adapt the transmission rate
(or the number of layers subscribed for a layered multicast session),
or to arrange for the receiver to leave the session.
8. Retransmission Payload Format MIME Type Registration
8.1. Introduction
The following MIME subtype name and parameters are introduced in this
document: "rtx", "rtx-time", and "apt".
The binding used for the retransmission stream to the payload type
number is indicated by an rtpmap attribute. The MIME subtype name
used in the binding is "rtx".
The "apt" (associated payload type) parameter MUST be used to map the
retransmission payload type to the associated original stream payload
type. If multiple original payload types are used, then multiple
"apt" parameters MUST be included to map each original payload type
to a different retransmission payload type.
An OPTIONAL payload-format-specific parameter, "rtx-time", indicates
the maximum time a sender will keep an original RTP packet in its
buffers available for retransmission. This time starts with the
first transmission of the packet.
The syntax is as follows:
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
where
<number>: indicates the dynamic payload type number assigned to
the retransmission payload format in an rtpmap attribute.
<apt-value>: is the value of the original stream payload type to
which this retransmission stream payload type is associated.
<rtx-time-val>: specifies the time in milliseconds (measured from
the time a packet was first sent) that a sender keeps an RTP
packet in its buffers available for retransmission. The absence
of the rtx-time parameter for a retransmission stream means that
the maximum retransmission time is not defined, but MAY be
negotiated by other means.
8.2. Registration of audio/rtx
MIME type: audio
MIME subtype: rtx
Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp
clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds (measured from the
time a packet was first sent) that the sender keeps an RTP packet
in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none
Published specification: RFC 4588
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Intended usage: COMMON
Authors:
Jose Rey
David Leon
Change controller:
IETF AVT WG delegated from the IESG
8.3. Registration of video/rtx
MIME type: video
MIME subtype: rtx
Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp
clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds (measured from the
time a packet was first sent) that the sender keeps an RTP packet
in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none
Published specification: RFC 4588
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Intended usage: COMMON
Authors:
Jose Rey
David Leon
Change controller:
IETF AVT WG delegated from the IESG
8.4. Registration of text/rtx
MIME type: text
MIME subtype: rtx
Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp
clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds (measured from the
time a packet was first sent) that the sender keeps an RTP packet
in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none
Published specification: RFC 4588
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Intended usage: COMMON
Authors:
Jose Rey
David Leon
Change controller:
IETF AVT WG delegated from the IESG
8.5. Registration of application/rtx
MIME type: application
MIME subtype: rtx
Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP timestamp
clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is the
payload type of the associated original stream.
Optional parameters:
rtx-time: indicates the time in milliseconds (measured from the
time a packet was first sent) that the sender keeps an RTP packet
in its buffers available for retransmission.
Encoding considerations: this type is only defined for transfer via
RTP.
Security considerations: see Section 12 of RFC 4588
Interoperability considerations: none
Published specification: RFC 4588
Applications which use this media type: multimedia streaming
applications
Additional information: none
Person & email address to contact for further information:
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Intended usage: COMMON
Authors:
Jose Rey
David Leon
Change controller:
IETF AVT WG delegated from the IESG
8.6. Mapping to SDP
The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is used to specify retransmissions
for an RTP stream, the mapping is done as follows:
- The MIME types ("video"), ("audio"), ("text"), and ("application")
go in the SDP "m=" as the media name.
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding
name. The RTP clockrate in "a=rtpmap" MUST be that of the
retransmission payload type. See Section 4 for details on this.
- The AVPF profile-specific parameters "ack" and "nack" go in SDP
"a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types
of feedback. See the AVPF profile [1] for details.
- The retransmission payload-format-specific parameters "apt" and
"rtx-time" go in the SDP "a=fmtp" as a semicolon-separated list of
parameter=value pairs.
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a
semicolon-separated list of parameter=value pairs.
In the following sections, some example SDP descriptions are
presented. In some of these examples, long lines are folded to meet
the column width constraints of this document; the backslash ("\") at
the end of a line and the carriage return that follows it should be
ignored.
8.7. SDP Description with Session-Multiplexing
In the case of session-multiplexing, the SDP description contains one
media specification "m" line per RTP session. The SDP MUST provide
the grouping of the original and associated retransmission sessions’
"m" lines, using the Flow Identification (FID) semantics defined in
RFC 3388 [6].
The following example specifies two original, AMR and MPEG-4, streams
on ports 49170 and 49174 and their corresponding retransmission
streams on ports 49172 and 49176, respectively:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
A special case of the SDP description is a description that contains
only one original session "m" line and one retransmission session "m"
line, the grouping is then obvious and FID semantics MAY be omitted
in this special case only.
This is illustrated in the following example, which is an SDP
description for a single original MPEG-4 stream and its corresponding
retransmission session:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
8.8. SDP Description with SSRC-Multiplexing
The following is an example of an SDP description for an RTP video
session using SSRC-multiplexing with similar parameters as in the
single-session example above:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
9. RTSP Considerations
The Real Time Streaming Protocol (RTSP), RFC 2326 [7], is an
application-level protocol for control over the delivery of data with
real-time properties. This section looks at the issues involved in
controlling RTP sessions that use retransmissions.
9.1. RTSP Control with SSRC-Multiplexing
In the case of SSRC-multiplexing, the "m" line includes both original
and retransmission payload types and has a single RTSP "control"
attribute. The receiver uses the "m" line to request SETUP and
TEARDOWN of the whole media session. The RTP profile contained in
the Transport header MUST be the AVPF profile or another suitable
profile allowing extended feedback. If the SSRC value is included in
the SETUP response’s Transport header, it MUST be that of the
original stream.
In order to control the sending of the session original media stream,
the receiver sends as usual PLAY and PAUSE requests to the sender for
the session. The RTP-info header that is used to set RTP-specific
parameters in the PLAY response MUST be set according to the RTP
information of the original stream.
When the receiver starts receiving the original stream, it can then
request retransmission through RTCP NACKs without additional RTSP
signalling.
9.2. RTSP Control with Session-Multiplexing
In the case of session-multiplexing, each SDP "m" line has an RTSP
"control" attribute. Hence, when retransmission is used, both the
original session and the retransmission have their own "control"
attributes. The receiver can associate the original session and the
retransmission session through the FID semantics as specified in
Section 8.
The original and the retransmission streams are set up and torn down
separately through their respective media "control" attribute. The
RTP profile contained in the Transport header MUST be the AVPF
profile or another suitable profile allowing extended feedback for
both the original and the retransmission sessions.
The RTSP presentation SHOULD support aggregate control and SHOULD
contain a session-level RTSP URL. The receiver SHOULD use aggregate
control for an original session and its associated retransmission
session. Otherwise, there would need to be two different ’session-
id’ values, i.e., different values for the original and
retransmission sessions, and the sender would not know how to
associate them.
The session-level "control" attribute is then used as usual to
control the playing of the original stream. When the receiver starts
receiving the original stream, it can then request retransmissions
through RTCP without additional RTSP signalling.
9.3. RTSP Control of the Retransmission Stream
Because of the nature of retransmissions, the sending of
retransmission packets SHOULD NOT be controlled through RTSP PLAY and
PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect the
retransmission stream. Retransmission packets are sent upon receiver
requests in the original RTCP stream, regardless of the state.
9.4. Cache Control
Retransmission streams SHOULD NOT be cached.
In the case of session-multiplexing, the "Cache-Control" header
SHOULD be set to "no-cache" for the retransmission stream.
In the case of SSRC-multiplexing, RTSP cannot specify independent
caching for the retransmission stream, because there is a single "m"
line in SDP. Therefore, the implementer should take this fact into
account when deciding whether or not to cache an SSRC-multiplexed
session.
10. Implementation Examples
This document mandates only the sender and receiver behaviours that
are necessary for interoperability. In addition, certain algorithms,
such as rate control or buffer management when targeted at specific
environments, may enhance the retransmission efficiency.
This section gives an overview of different implementation options
allowed within this specification.
The first example describes a minimal receiver implementation. With
this implementation, it is possible to retransmit lost RTP packets,
detect efficiently the loss of retransmissions, and perform multiple
retransmissions, if needed. Most of the necessary processing is done
at the server.
The second example shows how retransmissions may be used in (small)
multicast groups in conjunction with layered encoding. It
illustrates that retransmissions and layered encoding may be
complementary techniques.
10.1. A Minimal Receiver Implementation Example
This section gives an example of an implementation supporting
multiple retransmissions. The sender transmits the original data in
RTP packets using the MPEG-4 video RTP payload format. It is assumed
that NACK feedback messages are used, as per [1]. An SDP description