RFC 4588
RTP Retransmission Payload Format
RFC 4588: RTP Retransmission Payload Format 🎀
Okay bestie, this is RFC 4588, and it's all about how to resend lost RTP packets 🦋 It came from the Network Working Group in July 2006, and it's a Standards Track document, so it's a real spec that implementers are supposed to follow. 💅
The author squad is:
- J. Rey (Panasonic)
- D. Leon (Consultant)
- A. Miyazaki (Panasonic)
- V. Varsa (Nokia)
- R. Hakenberg (Panasonic)
It doesn't obsolete or update any other RFCs, since there's no Obsoletes or Updates line in its header. ✨
Status of This Memo
This document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 To find the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🫶
Copyright Notice
Copyright (C) The Internet Society (2006). 🌈
Abstract
Okay, so RTP retransmission is an effective packet loss recovery technique for real-time apps that have relaxed delay bounds 💖 This doc describes an RTP payload format for doing those retransmissions. The retransmitted RTP packets get sent in a separate stream from the original RTP stream, which is iconic 👑
It assumes feedback from receivers to senders is available. Specifically, it assumes that Real-time Transport Control Protocol (RTCP) feedback, as defined in the extended RTP profile for RTCP-based feedback (called RTP/AVPF), is available in this memo. 🧚
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements and Design Rationale for a Retransmission Scheme ...4
3.1. Multiplexing Scheme Choice .................................6
4. Retransmission Payload Format ...................................7
5. Association of Retransmission and Original Streams ..............9
5.1. Retransmission Session Sharing .............................9
5.2. CNAME Use ..................................................9
5.3. Association at the Receiver ................................9
6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1. RTCP at the Sender ........................................11
6.2. RTCP Receiver Reports .....................................11
6.3. Retransmission Requests ...................................12
6.4. Timing Rules ..............................................13
7. Congestion Control .............................................13
8. Retransmission Payload Format MIME Type Registration ...........15
8.1. Introduction ..............................................15
8.2. Registration of audio/rtx .................................16
8.3. Registration of video/rtx .................................17
8.4. Registration of text/rtx ..................................18
8.5. Registration of application/rtx ...........................19
8.6. Mapping to SDP ............................................20
8.7. SDP Description with Session-Multiplexing .................20
8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP Considerations ............................................22
9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2. RTSP Control with Session-Multiplexing ....................22
9.3. RTSP Control of the Retransmission Stream .................23
9.4. Cache Control .............................................23
10. Implementation Examples .......................................23
10.1. A Minimal Receiver Implementation Example ................24
10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA Considerations ...........................................26
12. Security Considerations .......................................26
13. Acknowledgements ..............................................27
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
Appendix A. How to Control the Number of Rtxs. per Packet .........291. Introduction ✨
Okay, so packet losses between an RTP sender and receiver can seriously wreck the quality of the received media 😭 There are a few techniques you can use to boost packet loss resiliency, like forward error correction (FEC), retransmissions, or interleaving. RFC 2354 [8] goes over the different options.
When you're picking a repair technique for an app, you have to factor in how much latency it can tolerate 💅 For multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds to keep things interactive, and that usually rules out retransmission 🙈
With enough latency, the repair scheme can get way more efficient. The sender can use receiver feedback to react to losses before their playout time at the receiver. 🌸
For multimedia streaming, the user can put up with an initial latency as part of session set-up, so an end-to-end delay of several seconds might be totally fine. RTP retransmission, as defined in this document, is aimed at apps like that. 🎀
The RTP retransmission method defined here works for unicast and (small) multicast groups. This doc defines a payload format for retransmitted RTP packets, and it lays out the protocol rules for the sender and the receiver that are involved in retransmissions. 🦋
This retransmission payload format was designed to be used with the extended RTP profile for RTCP-based feedback, AVPF [1]. It may also be used with other RTP profiles that get defined in the future. 🧚
AVPF lets you send feedback more often and send early feedback. It defines a general-purpose feedback message, called NACK, plus codec and application-specific feedback messages. Check [1] for the details. 💖
2. Terminology 💅
These are the terms used in this document, so let's get on the same page:
- CSRC: contributing source. See [3].
- Original packet: an RTP packet that carries user data sent for the first time by an RTP sender.
- Original stream: the RTP stream of original packets.
- Retransmission packet: an RTP packet that the receiver uses instead of a lost original packet. This retransmission packet is said to be associated with the original RTP packet.
- Retransmission request: the means by which an RTP receiver can ask the RTP sender to send a retransmission packet for a given original packet. Usually, an RTCP NACK packet as specified in [1] is used as the retransmission request for lost packets.
- Retransmission stream: the stream of retransmission packets associated with an original stream.
- Session-multiplexing: the scheme where the original stream and the associated retransmission stream are sent into two different RTP sessions.
- SSRC: synchronization source. See [3].
- SSRC-multiplexing: the scheme where the original stream and the retransmission stream are sent in the same RTP session with different SSRC values.
Last but not least, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. These are the BCP 14 words, so they carry real weight. 👑
Part 1 of 8 is done, bestie 🧚 More sections coming up next!
3. Requirements and Design Rationale for a Retransmission Scheme ✨
okay so bestie, retransmissions in RTP are perfect for streaming media 🎀 when the delay bounds are relaxed and you don't need full reliability. the big trick is that you get to trade off reliability vs. delay 💅. endpoints can just give up on retransmitting a lost packet once a certain buffering time has passed. and because of that, there's no head-of-line blocking caused by RTP retransmissions, unlike TCP 🦋 iykyk. ngl, if you need full reliability, or you can handle higher delay and jitter, the implementer should totally look at TCP or other transport options instead 🫶
so the RTP retransmission scheme in this document is built to hit this list of requirements 👑
- it must not break general RTP and RTCP mechanisms 💜
- it must be suitable for unicast and small multicast groups 🌸
- it must work with mixers and translators 🧚
- it must work with all known payload types 🌈
- it must not prevent the use of multiple payload types in a session ✨
- in order to support the largest variety of payload formats, the RTP receiver must be able to derive how many and which RTP packets were lost as a result of a gap in received RTP sequence numbers 😭. this requirement is called sequence number preservation. without it, you couldn't use retransmission with payload formats like conversational text [9] or most audio/video streaming apps, because those use the RTP sequence number to detect lost packets 💀
when you're designing an RTP retransmission solution, there are a few ways you could multiplex the original RTP packets and the retransmitted ones 🍓
first option: retransmit the RTP packet with its original sequence number and send the original and the retransmission in the same RTP stream. the retransmission would then be identical to the original, meaning the same header (so same sequence number) and the same payload. but this is a no-go 🙅♀️ because it would corrupt the RTCP statistics, and requirement 1 would fail. correct RTCP statistics need the sequence number to go up by one for every RTP packet in the stream, full stop 😤
second option: multiplex the original and retransmission packets in the same RTP stream but give them different payload type values. with this one, both packets share the same sequence number space. that means the RTP receiver couldn't figure out how many and which original packets (which sequence numbers) got lost 🙈. so this fails sequence number preservation (requirement 6), which also means requirement 4 would fail. interop with mixers and translators would get harder too, since they'd have to understand this new retransmission payload type in a sender RTP stream. for all these reasons, multiplexing by payload type in the same RTP stream is excluded 💔
last option: send the original and retransmission packets as two separate streams. you can multiplex those either by using two different sessions (that's session-multiplexing), or by using the same session with different SSRC values (that's SSRC-multiplexing) 🦋. since the original and retransmission packets carry the same type of media, the objections in Section 5.2 of RTP [3] to RTP multiplexing don't apply here 🙌
mixers and translators can process the original stream and just discard the retransmission stream if they can't use it 🫧
on the flip side, sending two separate streams doesn't alone satisfy requirements 1 and 6 🥺. so this document includes the original sequence number in the retransmitted packets 💖
and that's how two separate streams end up satisfying all the requirements in this section, periodt 💅✨
3.1. Multiplexing Scheme Choice
session-multiplexing and SSRC-multiplexing have different pros and cons, so let's go through them 🎀
session-multiplexing means the retransmission stream goes in a different RTP session (as defined in RTP [3]) from the original stream. so the original and retransmission streams go to different network addresses and/or port numbers 🌸. having a separate session gives you more flexibility ✨. in multicast, using two separate sessions lets a receiver choose whether or not to subscribe to the RTP session carrying the retransmission stream 👑. the original session can also be single-source multicast, while separate unicast sessions carry retransmissions to each receiver, so each one only gets the retransmission packets it asked for 🧚
separate sessions also make it easier for the network to treat the two streams differently, and they can simplify processing in mixers, translators, and packet caches 🍓
with SSRC-multiplexing, you only need one session for the original and retransmission streams 🦋. this lets streaming servers and middleware handling a huge number of concurrent sessions keep their port usage down 🫶
this retransmission payload format allows both session-multiplexing and SSRC-multiplexing for unicast sessions 🌈. from an implementation point of view, the two approaches don't differ much at all 💅. so, to maximise interoperability, both multiplexing approaches SHOULD be supported by senders and receivers ✨. for multicast sessions, session-multiplexing MUST be used 🔥, because tying the original stream to the retransmission stream gets messy when SSRC-multiplexing is used with multicast sessions (see Section 5.3 for motivation) 😭
4. Retransmission Payload Format ✨
Okay bestie, here's what a retransmission packet looks like 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so here's how the RTP header gets used 💅
If we're doing session-multiplexing, the same SSRC value MUST be used for the original stream and the retransmission stream. If there's an SSRC collision in either the original session or the retransmission session, RTP says an RTCP BYE packet MUST be sent in the session where the collision happened. On top of that, an RTCP BYE packet MUST also be sent for the associated stream in its own session. Once you grab a new SSRC identifier, the SSRC of both streams MUST be set to this value. ✨
Now for SSRC-multiplexing 🦋 Here, two different SSRC values MUST be used for the original stream and the retransmission stream, because that's what RTP requires. If an SSRC collision gets detected for either the original stream or the retransmission stream, RTP requires that an RTCP BYE packet MUST be sent for this stream. An RTCP BYE packet MUST NOT be sent for the associated stream. So only the stream that experienced the SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 for the implications on the original stream and retransmission stream SSRC association at the receiver. It's giving "read the next section" energy 🙈
For either multiplexing scheme, the sequence number has the standard definition, i.e., it MUST be one higher than the sequence number of the preceding packet sent in the retransmission stream. Simple, iconic 🌸
The retransmission packet timestamp MUST be set to the original timestamp, i.e., to the timestamp of the original packet. As a consequence, the initial RTP timestamp for the first packet of the retransmission stream is not random. It's equal to the original timestamp of the first packet that gets retransmitted. See the Security Considerations section in this document for security implications. 😭
Implementers have to be aware that the RTCP jitter value for the retransmission stream does not reflect the actual network jitter. The reason is there could be little correlation between the time a packet is retransmitted and its original timestamp. Not the vibe you'd expect 💀
The payload type is dynamic. If multiple payload types using retransmission are present in the original stream, then for each of these, a dynamic payload type MUST be mapped to the retransmission payload format. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done with Session Description Protocol (SDP). 🧚
As the retransmission packet timestamp carries the original media timestamp, the timestamp clockrate used by the retransmission payload type MUST be the same as the one used by the associated original payload type. Therefore, if an RTP stream carries payload types of different clockrates, this will also be the case for the associated retransmission stream. Note that an RTP stream does not usually carry payload types of different clockrates, so this is a rare moment 🌈
The payload of the RTP retransmission packet is the retransmission payload header followed by the payload of the original RTP packet. The length of the retransmission payload header is 2 octets. This payload header contains only one field, OSN (original sequence number), which MUST be set to the sequence number of the associated original RTP packet. The original RTP packet payload, including any possible payload headers specific to the original payload type, MUST be placed right after the retransmission payload header. Layers of realness 🍓
For payload formats that support encoding at multiple rates, instead of retransmitting the same payload as the original RTP packet, the sender MAY retransmit the same data encoded at a lower rate. This aims at limiting the bandwidth usage of the retransmission stream. When doing so, the sender MUST ensure that the receiver will still be able to decode the payload of the already sent original packets that might have been encoded based on the payload of the lost original packet. In addition, if the sender chooses to retransmit at a lower rate, the values in the payload header of the original RTP packet may no longer apply to the retransmission packet. They may need to be modified in the retransmission packet to reflect the change in rate. The sender SHOULD trade off the decrease in bandwidth usage with the decrease in quality caused by resending at a lower rate. Balance is everything 💜
If the original RTP header carried any profile-specific extensions, the retransmission packet SHOULD include the same extensions immediately following the fixed RTP header, as expected by applications running under this profile. In this case, the retransmission payload header MUST be placed after the profile-specific extensions. 🎀
If the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension. This header extension MUST be placed right after the fixed RTP header, as specified in RTP [3]. In this case, the retransmission payload header MUST be placed after the header extension. Order matters, bestie 👑
If the original RTP packet contained RTP padding, that padding MUST be removed before constructing the retransmission packet. If padding of the retransmission packet is needed, padding MUST be performed as with any RTP packets, and the padding bit MUST be set. 🫶
The marker bit (M), the CSRC count (CC), and the CSRC list of the original RTP header MUST be copied "as is" into the RTP header of the retransmission packet. Copy-paste but make it iconic ✨
5. Association of Retransmission and Original Streams
5.1. Retransmission Session Sharing
In the case of session-multiplexing, a retransmission session MUST map to exactly one original session. In other words, the same retransmission session cannot be used for different original sessions. 🚫
If retransmission session sharing were allowed, it would be a problem for receivers, since they would receive retransmissions for original sessions they might not have joined. For example, a receiver wishing to receive only audio would also receive retransmitted video packets if an audio session and a video session shared the same retransmission session. Not me getting video I never asked for 😭
5.2. CNAME Use
In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same RTCP CNAME [3] for an original stream and its associated retransmission stream. Same name, same energy 🦋
5.3. Association at the Receiver
A receiver getting multiple original and retransmission streams needs to associate each retransmission stream with its original stream. The association is done differently depending on whether session-multiplexing or SSRC-multiplexing is used. ✨
If session-multiplexing is used, the receiver associates the two streams having the same SSRC in the two sessions. Note that the payload type field cannot be used to perform the association, since several media streams may have the same payload type value. The two sessions are themselves associated out-of-band. See Section 8 for how the grouping of the two sessions is done with SDP. 🧚
If SSRC-multiplexing is used, the receiver should first of all look for two streams that have the same CNAME in the session. In some cases, the CNAME may not be enough to determine the association, since multiple original streams in the same session may share the same CNAME. For example, there can be multiple video streams in the same video session mapping to different SSRCs, and they might still use the same CNAME and possibly the same payload type (PT) values. Each (or some) of these streams may have an associated retransmission stream. Layers on layers 🌸
In this case, to find out the association between original and retransmission streams having the same CNAME, the receiver SHOULD behave as follows. 🎀
The association can generally be resolved when the receiver gets a retransmission packet matching a retransmission request that had been sent earlier. Upon reception of a retransmission packet whose original sequence number has been previously requested, the receiver can derive that the SSRC of the retransmission packet is associated to the sender SSRC from which the packet was requested. Detective era 🔥
However, this mechanism might fail if there are two outstanding requests for the same packet sequence number in two different original streams of the session. Note that since the initial packet sequence numbers are random, the probability of having two outstanding requests for the same packet sequence number would be very small. Nevertheless, to avoid ambiguity in the unicast case, the receiver MUST NOT have two outstanding requests for the same packet sequence number in two different original streams before the association is resolved. In multicast, this ambiguity cannot be completely avoided, because another receiver may have requested the same sequence number from another stream. Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. Hard no in multicast 🚫
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. Start over, no shame 💅
6. Use with the Extended RTP Profile for RTCP-based Feedback
This section gives general hints for using 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. As far as the RTCP bandwidth calculation is concerned, the original and retransmission streams are seen as independent senders belonging to the same RTP session. They're thus equally sharing the RTCP bandwidth assigned to senders. Equal rights, equal slay 👑
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. Both streams get their goodbye, no leaving anyone on read 😭🫶
6.2. RTCP Receiver Reports 📨
okay so with session-multiplexing, the receiver sends report blocks for the original stream and the retransmission stream in separate Receiver Report (RR) packets, and each one lives in its own RTP session 💅. RR packets about the original stream go in the original RTP session, and RR packets about the retransmission stream go in the retransmission session. The RTCP bandwidth for those two sessions may be chosen independently (for example, through RTCP bandwidth modifiers [4]) 🦋
with SSRC-multiplexing, it's a lot simpler 🌸 there's only one session, so the receiver puts report blocks for both the original and the retransmission streams in the same RR packet. one packet, two streams, zero drama 🫶
6.3. Retransmission Requests 🔥
bestie, the NACK feedback message format from the AVPF profile SHOULD be used by receivers to send retransmission requests 💌 whether a receiver actually asks for a given packet is an implementation issue, so it's kind of your call. a real receiver should weigh things like how much application delay it can tolerate, what the network is like, and what kind of media it's dealing with ✨
the receiver should generally check whether the retransmitted packet would still be useful once it shows up 🕰️ the timestamp of a missing packet can be estimated from the timestamps of the packets before and/or after the sequence number gap that the missing packet left behind 🧚 most of the time, some kind of linear estimate is good enough, no cap 💖
the receiver should also work out an estimate of the round-trip time (RTT) to the sender 🎀 one way to do that is to measure how long it takes to get a retransmission back after a NACK has gone out for that packet. the estimate can also come from past observations, from the RTT in an RTCP report if one is available, or from any other means. there's a standard mechanism for the receiver to estimate the RTT in "RTP Control Protocol Extended Reports (RTCP XR)" [11] 🧠
here's the big one: the receiver should not send a retransmission request the instant it notices a missing sequence number 🙅♀️ it should add a bit of extra delay to make room for packet reordering. that extra delay can be based on past observations of how much reordering the receiver has actually experienced 🔍 in environments where reordering is rare or doesn't happen at all (say, the datalink layer gives ordered delivery), the delay may be extremely low or even zero 🌈 in those cases, the "reorder delay" algorithm may not be timer based at all and can be packet based instead. for example, if n packets are received after a gap is detected, the packet can be assumed to be truly lost rather than out of order. on some platforms this is way easier to code as a very short fixed FIFO packet buffer than as a timer 🧁
to make things more robust against a lost NACK or a lost retransmission packet, a receiver may send a new NACK for the same packet 🔁 this is called multiple retransmissions. before sending that new NACK, the receiver should lean on a timer to be reasonably sure the previous retransmission attempt actually failed, so it doesn't send unnecessary retransmissions 🙈 the timer value shall be based on the observed round-trip time. a static value or an adaptive value MAY be used. for example, an adaptive timer could change its value with every new request for the same packet ⭐ this document doesn't give any guidelines on how that 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 tried to do multiple retransmissions by sending a NACK in the retransmission stream, it wouldn't be able to know the original sequence number or make a timestamp estimate for the packet it's requesting. big oof 😭
Appendix A gives some guidelines on 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 means you can react more quickly to a packet loss, which is iconic 🏃♀️ but if a new packet loss happens right after the early RTCP packet was sent, the receiver then has to wait for the next regular RTCP compound packet after the early one 😬 sending NACKs only in regular RTCP compound packets decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. implementers should think about what that means for the application they're building 💅
receivers may also make use of the minimum interval between regular RTCP compound packets 🕊️ that interval can keep regular receiver reporting to a minimum while still letting receivers send early RTCP packets when things need more frequent feedback, like when the packet loss rate is high 🌧️ just a heads up: even though RTCP packets might get suppressed because they don't contain NACKs, the same RTCP bandwidth as if they were sent still needs to be available 💜 see AVPF [1] for the details on how to use the minimum interval.
7. Congestion Control 🚦
okay, this one is seriously important, bestie 😭 RTP retransmission poses a risk of increasing network congestion. in a best-effort environment, packet loss is caused by congestion, so if you react to loss by retransmitting older data without decreasing the rate of the original stream, you'd just make congestion worse 💀 implementations SHOULD follow the recommendations below if they want to use retransmission 🫶
the RTP profile that the retransmission scheme runs under defines an appropriate congestion control mechanism for different environments 🌐 following the rules under that profile, an RTP application can figure out its acceptable bitrate and packet rate so it stays fair to other TCP or RTP flows ⚖️
if an RTP application uses retransmission, its acceptable packet rate and bitrate include both the original and the retransmitted data 🎀 this guarantees that an application using retransmission gets the same fairness as one that doesn't. in practice, that rule turns 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) 🙅♀️ and the sender MAY selectively retransmit only the packets it deems important, ignoring NACK messages for the others, in order to limit the bitrate 🧠
these congestion control mechanisms should keep the packet loss rate within acceptable parameters 📉 in this context, packet loss counts as acceptable if a TCP flow across the same network path and under the same network conditions would achieve, on a reasonable timescale, an average throughput that is not less than what the RTP flow achieves ✨ if congestion isn't kept under control, then retransmission SHOULD NOT be used 🛑
retransmissions MAY still be sent in some cases, e.g., on wireless links where packet losses are not caused by congestion, if the server (or the client making the retransmission request) estimates that a particular packet or frame is important to keep play out going, or if an RTSP PAUSE has been issued to let the buffer 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 to 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 that 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, so that each original payload type maps 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 goes like this 📝
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>where:
<number>is 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 that this retransmission stream payload type is associated with.<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. if the rtx-time parameter is absent for a retransmission stream, the maximum retransmission time is not defined, but it MAY be negotiated by other means 🤝
8.2. Registration of audio/rtx 🎧
here's the registration template, copied exactly as the original has it 💅
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 IESG8.3. Registration of video/rtx 🎬
okay so this is the video twin of the rtx type, and it's giving the same energy as the audio one 💖 here's the whole template, copy-paste exact:
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 IESG8.4. Registration of text/rtx 📝
same slay, but make it text 💅 here's the template:
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 IESG8.5. Registration of application/rtx 🧩
last one in this family, and it's the application flavour 🫶 same template, no cuts:
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 IESG8.6. Mapping to SDP 🗺️
okay so the MIME type info has a specific map to SDP [5], which is what people use to describe RTP sessions 🎀 when SDP is used to set up retransmissions for an RTP stream, this is how it lines up:
- 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.
we're about to look at some example SDP descriptions 👀 a few of them have long lines that get folded to fit the column width of this doc. the backslash ("") at the end of a line, plus the carriage return right after it, should be ignored. not a bug, just formatting 🙈
8.7. SDP Description with Session-Multiplexing 🎞️
with session-multiplexing, the SDP description has one media "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].
this example has two original streams, AMR and MPEG-4, on ports 49170 and 49174, with their retransmission streams on ports 49172 and 49176:
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:4a special case is when the SDP only has one original session "m" line and one retransmission session "m" line. the grouping is then obvious, so FID semantics MAY be omitted in this special case only 🧠
here's that case, one original MPEG-4 stream plus its 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=30008.8. SDP Description with SSRC-Multiplexing 🔐
this one's an SDP description for an RTP video session using SSRC-multiplexing, with the same parameters as 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=30009. RTSP Considerations 🎀
RTSP, which is RFC 2326 [7], is an application-level protocol for controlling the delivery of data with real-time properties. this section looks at the stuff you need to think about when controlling RTP sessions that use retransmissions 💜
9.1. RTSP Control with SSRC-Multiplexing 🎛️
with SSRC-multiplexing, the "m" line includes both original and retransmission payload types, and it has a single RTSP "control" attribute. the receiver uses the "m" line to request SETUP and TEARDOWN for the whole media session. the RTP profile in the Transport header MUST be the AVPF profile or another suitable profile that allows extended feedback. if the SSRC value shows up in the SETUP response's Transport header, it MUST be the one from the original stream.
to control sending the original media stream for the session, the receiver sends PLAY and PAUSE requests to the sender like normal. the RTP-info header that sets RTP-specific parameters in the PLAY response MUST be set according to the RTP information of the original stream.
once the receiver starts getting the original stream, it can request retransmissions through RTCP NACKs without any extra RTSP signalling 🦋
9.2. RTSP Control with Session-Multiplexing 🧵
with session-multiplexing, each SDP "m" line has its own RTSP "control" attribute. so when retransmission is used, both the original session and the retransmission get their own "control" attributes. the receiver can match the original session with the retransmission session through the FID semantics from Section 8 🔗
the original and retransmission streams are set up and torn down separately, through their own media "control" attributes. the RTP profile in the Transport header MUST be the AVPF profile or another suitable profile that allows 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'd need to be two different 'session-id' values, i.e., different values for the original and retransmission sessions, and the sender wouldn't know how to link them 😭
the session-level "control" attribute is used as usual to control playing the original stream. once the receiver starts getting the original stream, it can request retransmissions through RTCP without any extra RTSP signalling ✨
9.3. RTSP Control of the Retransmission Stream 🚫
because of how retransmissions work, 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 get sent when the receiver asks for them in the original RTCP stream, no matter what state things are in 🌸
9.4. Cache Control 🧊
retransmission streams SHOULD NOT be cached.
with session-multiplexing, the "Cache-Control" header SHOULD be set to "no-cache" for the retransmission stream.
with SSRC-multiplexing, RTSP can't specify independent caching for the retransmission stream, because there's a single "m" line in SDP. so the implementer should take this into account when deciding whether or not to cache an SSRC-multiplexed session 🧠
10. Implementation Examples 🧚
this document only mandates the sender and receiver behaviours that are needed for interoperability 🫶 on top of that, certain algorithms, like rate control or buffer management tuned for specific environments, may make retransmissions more efficient.
this section gives an overview of the different implementation options allowed in this specification 🌈
the first example is a minimal receiver implementation. with it, you can retransmit lost RTP packets, efficiently detect when retransmissions themselves get lost, and do multiple retransmissions if needed. most of the heavy lifting happens at the server 💅
the second example shows how retransmissions can be used in (small) multicast groups together with layered encoding. it shows that retransmissions and layered encoding can be complementary techniques, which is honestly so iconic 👑
10.1. A Minimal Receiver Implementation Example 🎀
okay so this section is a full example of an implementation that supports multiple retransmissions 💖 the sender sends the original data in RTP packets using the MPEG-4 video RTP payload format. it's assumed that NACK feedback messages are used, as per [1] ✨ here's the SDP description with SSRC-multiplexing:
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=3000the format-specific parameter rtx-time tells you that the server will buffer the sent packets in a retransmission buffer for 3.0 seconds 🕒 after that, the packets get deleted from the buffer and will never be sent again 💀
in this example, the RTP receiver processing needed to handle retransmission is kept to a minimum 🧚 the receiver spots packet loss from the gaps in the received sequence numbers, then tells the sender about lost packets using NACKs, as defined in the AVPF profile [1]. the receiver should take into account the signalled sender retransmission buffer length when it sizes its own reception buffer. it should also work out, from that buffer length, the maximum number of times a packet's retransmission can be requested 🦋
the sender should retransmit the packets selectively, meaning it picks whether to retransmit a requested packet based on the packet's importance, the observed Quality of Service (QoS), and the congestion state of the connection to the receiver 👑 obviously, the sender's workload goes up with the number of receivers, since state information and processing load have to be allocated for each one 😭
10.2. Retransmission of Layered Encoded Media in Multicast 🌈
this section shows how to mix retransmissions with layered encoding in multicast sessions 🫶 heads up: the retransmission framework is only offered for small multicast applications. if you want the drama of NACK implosion (severe congestion caused by feedback traffic in large-group reliable multicast), check out RFC 2887 [10] 💀
packets of different importance get sent in different RTP sessions 💜 the retransmission streams for the different layers can be seen as different retransmission layers too. the relative importance of the retransmission streams should match the relative importance of the original streams ✨
in multicast, SSRC-multiplexing of the original and retransmission streams is not allowed, as per Section 5.3 of this document 🙈 so the retransmission stream(s) MUST be sent in different RTP session(s) using session-multiplexing. no exceptions, bestie 🔥
here's an SDP description example of multicast retransmissions for layered encoded media:
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=3000the server and the receiver can use the retransmission methods from the examples above 🌸 and they can also choose to request and retransmit a lost packet depending on which layer it belongs to 🍓
11. IANA Considerations 🧾
a new MIME subtype name, rtx, got registered for four media types: video, audio, text and application 🎉 there's an additional REQUIRED parameter, apt, and an OPTIONAL parameter, rtx-time. see Section 8 for all the details 💅
12. Security Considerations 🔐
this section is important, bestie. the security stuff is serious 😭
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 setups, message authentication, data integrity, replay protection, and confidentiality are all desired ✨
without authentication, man-in-the-middle and replay attacks become possible, and those can be super harmful for RTP retransmission 💀 for example: tampered RTCP packets could trigger inappropriate retransmissions, which effectively cut the bitrate share given to the original data stream. tampered RTP retransmission packets could crash the client's decoder. and tampered retransmission requests could invalidate the SSRC association mechanism described in Section 5 of this document 🙈 on top of that, replayed packets could lead to false reordering and RTT measurements (which the retransmission request strategy needs) and could make the receiver buffer overflow 😱
also, to keep the data confidential, the original payload data needs to be encrypted 🔐 the 2-byte retransmission payload header does not need encrypting, since it doesn't give away any hints about the data content 🤷♀️
it's RECOMMENDED that the cryptography used for this payload format protects against known plaintext attacks 🛡️ RTP recommends that the initial RTP timestamp SHOULD be random to protect the stream against known plaintext attacks. this payload format doesn't follow that recommendation, because the initial timestamp will be the media timestamp of the first retransmitted packet. still, the initial timestamp of the original stream is itself random, so if the original stream is encrypted, the first retransmitted packet's timestamp would also look random to an attacker. so confidentiality isn't compromised 🦋
if cryptography is used to secure the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream 🔥 using the same key for both streams may cause security problems, like two-time pads. check Section 9.1 of the Secure Real-Time Transport Protocol (SRTP) [12] for a discussion of two-time pads and how to avoid them 📚
at the time of writing, SRTP doesn't provide all the security services mentioned here 😬 there are at least two reasons: 1) two-time pads can occur, and 2) this payload format typically runs 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 for retransmission are covered in Section 7 of this document 🚦
13. Acknowledgements 🫶
big thanks to Carsten Burmeister for his participation in developing this document 💖 we also owe thanks 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 the right number of retransmissions (rtxs.) per packet for the best possible transmission is genuinely tricky 😵💫 the absolute minimum should be one (1); otherwise, don't use this payload format. as of the date of publication, the authors weren't aware of any studies on the number of retransmissions per packet that gives the best performance 🥲 so to help implementers and researchers, this section describes an estimate of the buffering time needed for a given number of retransmissions ✨ once that time is calculated, it can be communicated to the client via the SDP parameter rtx-time, as defined in this document 💜
that's the whole document, bestie 🌈💖
A.1. Scenario and Assumptions
okay so picture this bestie 🎀 we're in a streaming situation where the delay limits are chill 🌸 Client and server both get buffer space, and it gets signalled with the rtx-time parameter in SDP.
- We're using the RTP AVPF profile with the SSRC-multiplexing retransmission scheme 🦋 One SSRC carries the original packets and another carries the retransmission packets.
- The default RTCP bandwidth share for SRs and RRs is SR+RR = 0.05 ✨ There are 2 senders and 1 receiver. Receivers and senders split the RTCP bandwidth share equally, 1/3 each, because senders make up more than 1/4 of the session members 💅
- avg-rtcp-size gets approximated as 120 bytes 🧚 This is a rounded-up average of 2 SRs, one per SSRC, each with 40/8/28/32 bytes for IPv6/UDP/SR/SDES with CNAME, so 105 bytes each. There's also an RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, which makes 157 bytes. Since senders and receivers share the RTCP bandwidth equally:
avg-rtcp-size = (157+105+105)/3 = 117.3 ~= 120 bytesThe big takeaway is that it's something over 100 bytes, which seems to be a representative number for typical configurations 🌈
- The profile is AVPF [1] and Generic NACKs are used to request retransmissions 🔥 That adds 16 bytes of overhead for 1 NACK, plus 4 more bytes for every additional NACK Feedback Control Information (FCI) field.
- We're assuming a worst-case scenario 💀 where each packet uses up all of its available retransmissions, N, before it's received. So if a packet gets requested for retransmission a maximum of 2 times, its generic NACK report block gets sent in two consecutive RTCP compounds. If it's requested 10 times, the generic NACK gets sent 10 times. This assumption keeps the RTCP packet size roughly constant after N*RTCP intervals (seconds), at avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). The receiver RTCP bandwidth share is 1/3 here, so avg-rtcp-size = 124 + 4*N/3 🍓
- Two delay parameters are tricky to approximate and may depend on the implementation, so we list them without giving them a specific value 🙈 One is the packet loss detection time (T2), and the other is the feedback processing and queuing time for retransmissions (T5). Implementers shall assign appropriate values to these two parameters.
Here's the picture, graphically 🦋
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-timeA.2. Goal
The goal is to estimate the buffering time, T(), that a streaming server shall use so it can enable a given number of retransmissions for each packet, N ✨ This time is roughly the same at the server and the client, as long as you assume the client starts buffering T1 seconds later 🫶
A.3. Solution
First up, we figure out the estimate for 1 retransmission, T(1)=T 💜
T = T1 + T2 + T3 + T4 + T5Since T1 + T4 ~= RTT, that simplifies to:
T = RTT + T2 + T3 + T5For the worst case of T3, we assume reporting has to wait a whole RTCP interval and that the maximum randomization factor of 1.5 gets applied 😭 Then, after applying the compensation that avoids traffic bursts (see Appendix A.7 of RTP [3]), we get T3 = 1.5/1.21828*RTCP-Interval. So:
T = RTT + 1.2312*RTCP-Interval + T2 + T5Now, RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). In this scenario, senders + receivers = 3, and RR+RS is the receiver report plus sender report bandwidth share, which equals the default 5% of session bandwidth, bw. We assume an average RTCP packet size, avg-rtcp-size = 120 bytes. Putting it all together:
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5This is 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 we said above:
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3A.4. Numbers
If we ignore the effect of T2 and T5, which means assuming all losses get detected immediately and there's no extra delay from feedback processing or retransmission queuing, we get these 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,08To see how much error we'd get by ignoring the Generic NACKs, we can run the same numbers without their contribution, with avg-rtcp-size ~= 120 bytes 🙈 The results below suggest the buffer estimate could be off by 1-1.5 seconds (5-10%) at lower bandwidths and higher numbers of retransmissions. That effect is pretty small in this case, but you should still check it carefully for your own scenario, which 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,07Authors' 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.comFull 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 ✨
okay so, the IETF is NOT saying whether any patents or other rights are valid or how far they reach 🙈 It also isn't claiming it went hunting for them. If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚
bestie, if you want copies of IPR disclosures sent to the IETF Secretariat, or the assurances of licenses people have promised, or the results of anyone trying to get a general license or permission for implementers or users to use proprietary rights, you can look all of that up in the IETF online IPR repository at http://www.ietf.org/ipr 💜
and the IETF is literally asking everyone 🫶 If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please tell them at ietf-ipr@ietf.org. ngl that's the most helpful "tell us if you know" energy ever 💅
Acknowledgement
the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 🎀 so the people keeping these documents running have their support sorted, and that's iconic 🌸
📦 where this page comes from
- ietf: rfc4588 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms