example with SSRC-multiplexing is given below:
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=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 Quality of Service (QoS), and
congestion state of the network connection to the receiver.
Obviously, the sender processing increases with the number of
receivers as state information and processing load must be allocated
to each receiver.
10.2. 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 offered only for small multicast applications. Refer to
RFC 2887 [10] for a discussion of the problems of NACK implosion,
severe congestion caused by feedback traffic, in large-group reliable
multicast applications.
Packets of different importance are sent in different RTP sessions.
The retransmission streams corresponding to the different layers can
themselves be seen as different retransmission layers. The relative
importance of the different retransmission streams should reflect the
relative importance of the different original streams.
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:
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
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 for four
different media types, as follows: "video", "audio", "text" and
"application". An additional REQUIRED parameter, "apt", and an
OPTIONAL parameter, "rtx-time", are defined. See Section 8 for
details.
12. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in RTP
[3], Section 9.
In common streaming scenarios message authentication, data integrity,
replay protection, and confidentiality are desired.
The absence of authentication may enable man-in-the-middle and replay
attacks, which can be very harmful for RTP retransmission. For
example: tampered RTCP packets may trigger inappropriate
retransmissions that effectively reduce the actual bitrate share
allocated to the original data stream, tampered RTP retransmission
packets could cause the client’s decoder to crash, and tampered
retransmission requests may invalidate the SSRC association mechanism
described in Section 5 of this document. On the other hand, replayed
packets could lead to false reordering and RTT measurements (required
for the retransmission request strategy) and may cause the receiver
buffer to overflow.
Furthermore, in order to ensure confidentiality of the data, the
original payload data needs to be encrypted. There is actually no
need to encrypt the 2-byte retransmission payload header since it
does not provide any hints about the data content.
Furthermore, it is RECOMMENDED that the cryptography mechanisms used
for this payload format provide protection against known plaintext
attacks. RTP recommends that the initial RTP timestamp SHOULD be
random to secure the stream against known plaintext attacks. This
payload format does not follow this recommendation as the initial
timestamp will be the media timestamp of the first retransmitted
packet. 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.
If cryptography is used to provide security services on the original
stream, then the same services, with equivalent cryptographic
strength, MUST be provided on the retransmission stream. The use of
the same key for the retransmitted stream and the original stream may
lead to security problems, e.g., two-time pads. Refer to Section 9.1
of the Secure Real-Time Transport Protocol (SRTP) [12] for a
discussion the implications of two-time pads and how to avoid them.
At the time of writing this document, SRTP does not provide all the
security services mentioned. There are, at least, two reasons for
this: 1) the occurrence of two-time pads and 2) the fact that this
payload format typically works under the RTP/AVPF profile whereas
SRTP only supports RTP/AVP. An adapted variant of SRTP shall solve
these shortcomings in the future.
Congestion control considerations with the use of retransmission are
dealt with in Section 7 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] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP profile for Real-time Transport Control Protocol
(RTCP)-Based feedback", RFC 4585, July 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
14.2. Informative References
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[10] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L.,
and M. Luby, "The Reliable Multicast Design Space for Bulk Data
Transfer", RFC 2887, August 2000.
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
Appendix A. How to Control the Number of Rtxs. per Packet
Finding out the number of retransmissions (rtxs.) per packet for
achieving the best possible transmission is a difficult task. Of
course, the absolute minimum should be one (1); otherwise, do not use
this payload format. Moreover, as of date of publication, the
authors were not aware of any studies on the number of
retransmissions per packet that should be used for best performance.
To help implementers and researchers on this item, this section
describes an estimate of the buffering time required for achieving a
given number of retransmissions. Once this time has been calculated,
it can be communicated to the client via SDP parameter "rtx-time", as
defined in this document.
A.1. Scenario and Assumptions
* Streaming scenario with relaxed delay bounds. Client and server
are provided with buffering space as indicated by the parameter
"rtx-time" in SDP.
* RTP AVPF profile used with SSRC-multiplexing retransmission scheme:
1 SSRC for original packets, 1 for retransmission packets.
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR = 0.05.
We have senders (2) and receivers (1). Receivers and senders get
equally 1/3 of the RTCP bandwidth share because the proportion of
senders is greater than 1/4 of session members.
* avg-rtcp-size is approximated by 120 bytes. This is a rounded-up
average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes
for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a
RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.
Since senders and receivers share the RTCP bandwidth equally, then
avg-rtcp-size = (157+105+105)/3 = 117.3 ~= 120 bytes. The
important characteristic of this value is that it is something over
100 bytes, which seems to be a representative figure for typical
configurations.
* The profile used is AVPF [1] and Generic NACKs are used for
requesting retransmissions. This adds 16 bytes of overhead for 1
NACK and 4 bytes more for every additional NACK Feedback Control
Information (FCI) field.
* We assume a worst-case scenario in which each packet exhausts its
corresponding number of available retransmissions, N, before it is
received. This means that if a packet is requested for
retransmission a maximum of 2 times, the corresponding generic NACK
report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times.
This assumption makes the RTCP packet size approximately constant
after N*RTCP intervals (seconds), namely, to avg-rtcp-size = 120 +
(receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver
RTCP bandwidth share is 1/3; thus, avg-rtcp-size = 124 + 4*N/3.
* Two delay parameters are difficult to approximate and may be
implementation dependent. Therefore, we list them here explicitly
without assigning them a particular value: one is the packet loss
detection time (T2), and the other is feedback processing and
queuing time for retransmissions (T5). Implementers shall assign
appropriate values to these two parameters.
Graphically, we have the following:
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Legend:
=======
DL: downlink (client->server)
UL: uplink (server->client)
Time unit is seconds, s.
Bitrate unit is bits per second, bps.
DL transmission time: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Time to detect packet loss: T2 = pkt-loss-detect-time
Time to report packet loss: T3 = time-to-next-rtcp-report
UL transmission time: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
Retransmissions processing time: T5 = feedback-processing-time +
rtx-queuing-time
A.2. Goal
To find an estimate of the buffering time, T(), that a streaming
server shall use in order to enable a given number of retransmissions
for each packet, N. This time is approximately equal at the server
and at the client, if one considers that the client starts buffering
T1 seconds later.
A.3. Solution
First, we find the value of the estimate for 1 retransmission,
T(1)=T:
T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5
The worst case for T3 would be that we assume that reporting has to
wait a whole RTCP interval and that the maximum randomization factor
of 1.5 is applied. Therefore, after applying the subsequent
compensation to avoid traffic bursts (see Appendix A.7 of RTP [3]),
we have that T3 = 1.5/1.21828*RTCP-Interval. Thus,
T = RTT + 1.2312*RTCP-Interval + T2 + T5
On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders +
receivers)/(RR+RS). In this scenario: sender + receivers = 3; RR+RS
is the receiver report plus sender report bandwidth share, in this
case, equal to the default 5% of session bandwidth, bw. We assume an
average RTCP packet size, avg-rtcp-size = 120 bytes. Thus:
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
for 1 retransmission.
For enabling N retransmissions, the available buffering time in a
streaming server or client is approximately:
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
where, as per above,
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3.
A.4. Numbers
If we ignore the effect of T2 and T5, i.e., assume that all losses
are detected immediately and that there is no additional delay due to
feedback processing or retransmission queuing, we have the following
buffering times for different values of N:
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,21 2,44 6,28 8,97 13,18
128000 0,05 0,63 1,27 3,27 4,66 6,84
256000 0,05 0,34 0,68 1,76 2,50 3,67
512000 0,05 0,19 0,39 1,00 1,43 2,09
1024000 0,05 0,12 0,25 0,63 0,89 1,29
5000000 0,05 0,06 0,13 0,33 0,46 0,66
10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68
128000 0,2 0,78 1,57 4,02 5,71 8,34
256000 0,2 0,49 0,98 2,51 3,55 5,17
512000 0,2 0,34 0,69 1,75 2,48 3,59
1024000 0,2 0,27 0,55 1,38 1,94 2,79
5000000 0,2 0,21 0,43 1,08 1,51 2,16
10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68
128000 1 1,58 3,17 8,02 11,31 16,34
256000 1 1,29 2,58 6,51 9,15 13,17
512000 1 1,14 2,29 5,75 8,08 11,59
1024000 1 1,07 2,15 5,38 7,54 10,79
5000000 1 1,01 2,03 5,08 7,11 10,16
10000000 1 1,01 2,01 5,04 7,06 10,08
To quantify the error of not taking the Generic NACKS into account,
we can do the same numbers, but ignoring the Generic NACK
contribution, avg-rtcp-size ~= 120 bytes. As we see from below, this
may result in a buffer estimation error of 1-1.5 seconds (5-10%) for
lower bandwidth values and higher number of retransmissions. This
effect is low in this case. Nevertheless, it should be carefully
evaluated for the particular scenario; that is why the formula
includes it.
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,16 2,32 5,79 8,11 11,58
128000 0,05 0,60 1,21 3,02 4,23 6,04
256000 0,05 0,33 0,65 1,64 2,29 3,27
512000 0,05 0,19 0,38 0,94 1,32 1,89
1024000 0,05 0,12 0,24 0,60 0,83 1,19
5000000 0,05 0,06 0,13 0,32 0,45 0,64
10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08
128000 0,2 0,75 1,51 3,77 5,28 7,54
256000 0,2 0,48 0,95 2,39 3,34 4,77
512000 0,2 0,34 0,68 1,69 2,37 3,39
1024000 0,2 0,27 0,54 1,35 1,88 2,69
5000000 0,2 0,21 0,43 1,07 1,50 2,14
10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08
128000 1 1,55 3,11 7,77 10,88 15,54
256000 1 1,28 2,55 6,39 8,94 12,77
512000 1 1,14 2,28 5,69 7,97 11,39
1024000 1 1,07 2,14 5,35 7,48 10,69
5000000 1 1,01 2,03 5,07 7,10 10,14
10000000 1 1,01 2,01 5,04 7,05 10,07
Authors’ Addresses
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
David Leon
Consultant
EMail: davidleon123@yahoo.com
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: miyazaki.akihiro@jp.panasonic.com
Viktor Varsa
Nokia Research Center
6000 Connection Drive
Irving, TX. USA
Phone: 1-972-374-1861
EMail: viktor.varsa@nokia.com
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at