RFC 3158
RTP Testing Strategies
RFC 3158: RTP Testing Strategies 🎀
bestie, this one is a testing playbook for RTP, the real-time transport protocol that carries audio and video on the Internet 🦋. It was written by C. Perkins (USC/ISI), J. Rosenberg (dynamicsoft), and H. Schulzrinne (Columbia University) in August 2001. It's labelled Category: Informational 📚, so it's just sharing info and not a formal standard. It doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨.
Status of this Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 💅
This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.
Table of Contents 🗂️
1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2 End systems . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Media transport . . . . . . . . . . . . . . . . . 3
2.2 RTP Header Extension . . . . . . . . . . . . . . . 4
2.3 Basic RTCP . . . . . . . . . . . . . . . . . . . 4
2.3.1 Sender and receiver reports . . . . . . . . 4
2.3.2 RTCP source description packets . . . . . . 6
2.3.3 RTCP BYE packets . . . . . . . . . . . . . . 7
2.3.4 Application defined RTCP packets . . . . . . 7
2.4 RTCP transmission interval . . . . . . . . . . . . 7
2.4.1 Basic Behavior . . . . . . . . . . . . . . 8
2.4.2 Step join backoff . . . . . . . . . . . . 9
2.4.3 Steady State Behavior . . . . . . . . . . 11
2.4.4 Reverse Reconsideration . . . . . . . . . 12
2.4.5 BYE Reconsideration . . . . . . . . . . . 13
2.4.6 Timing out members . . . . . . . . . . . . 14
2.4.7 Rapid SR's . . . . . . . . . . . . . . . . 15
3 RTP translators . . . . . . . . . . . . . . . . . . . . 15
4 RTP mixers. . . . . . . . . . . . . . . . . . . . . . . 17
5 SSRC collision detection. . . . . . . . . . . . . . . . 18
6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19
7 Security Considerations . . . . . . . . . . . . . . . . 20
8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20
9 References. . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement. . . . . . . . . . . . . . . . . 221 Introduction 🌸
okay so this memo describes a possible testing strategy for RTP [1] implementations 🧚. The tests are meant to help show that multiple implementations can interoperate, and to highlight common implementation mistakes 🙈. They are not meant to be an exhaustive set, and passing them doesn't automatically mean you conform to the full RTP spec. So it's a great starting point, not the finish line ✨.
2 End systems 💖
Here's the setup for testing RTP end systems, shown in Figure 1 🦋.
+-----------------+
+--------+ Test instrument +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 1: Testing architectureso both RTP implementations send their packets to the test instrument, and the instrument forwards each packet from one implementation to the other 🔁. Unless told otherwise, packets get forwarded with no extra delay and no loss. The test instrument is required to delay or discard packets in some of the tests 🙃. It's totally invisible to the RTP implementations, it just pretends the network is being rude 😈.
The instrument can also log packet contents so you can check they're correct 📝.
A typical setup might be three machines on one Ethernet segment 🖥️. Two of them run the RTP implementations and the third runs the test instrument. The instrument is an application level packet forwarder, and both RTP implementations are told to send unicast RTP packets to it so it can pass them along 💅.
2.1 Media transport 🎶
The goal here is to show that basic media flows can go between the two RTP implementations 💜. First, the first RTP implementation transmits and the second receives. If that works, the roles flip, so the second sends and the first receives 🔄.
The receiving application should be able to handle these edge cases, on top of normal operation:
- Verify reception of packets which contain padding.
- Verify reception of packets which have the marker bit set
- Verify correct operation during sequence number wrap-around.
- Verify correct operation during timestamp wrap-around.
- Verify that the implementation correctly differentiates packets according to the payload type field.
- Verify that the implementation ignores packets with unsupported payload types
- Verify that the implementation can playout packets containing a CSRC list and non-zero CC field (see section 4).
The sending application should be verified to correctly handle these edge cases:
- If padding is used, verify that the padding length indicator (last octet of the packet) is correctly set and that the length of the data section of the packet corresponds to that of this particular payload plus the padding.
- Verify correct handling of the M bit, as defined by the profile.
- Verify that the SSRC is chosen randomly.
- Verify that the initial value of the sequence number is randomly selected.
- Verify that the sequence number increments by one for each packet sent.
- Verify correct operation during sequence number wrap-around.
- Verify that the initial value of the timestamp is randomly selected.
- Verify correct increment of timestamp (dependent on the payload format).
- Verify correct operation during timestamp wrap-around.
- Verify correct choice of payload type according to the chosen payload format, profile and any session level control protocol.
2.2 RTP Header Extension 🎀
An RTP implementation that doesn't use an extended header should still be able to process packets containing an extension header, by ignoring the extension 🙈.
If an implementation does use the header extension, check that the profile specific field and the length field of the extension are set correctly, and that the length of the packet is consistent 🔍.
2.3 Basic RTCP 🌈
An RTP implementation is required to send RTCP control packets in addition to data packets 📦. The setup for testing basic RTCP functions is the same one shown in Figure 1 🦋.
2.3.1 Sender and receiver reports 📊
The first test has both implementations running, but neither one sends data 😌. You should verify that each implementation generates RTCP packets, and that the other implementation correctly receives them. You should also verify that:
- all RTCP packets sent are compound packets
- all RTCP compound packets start with an empty RR packet
- all RTCP compound packets contain an SDES CNAME packet
Next, the first implementation is made to transmit data packets. Now that implementation should generate SR packets instead of RR packets, and the second application should generate RR packets containing a single report block 🔁. Verify that these SR and RR packets are correctly received. Also verify these features of the SR packets:
- that the length field is consistent with both the length of the packet and the RC field
- that the SSRC in SR packets is consistent with that in the RTP data packets
- that the NTP timestamp in the SR packets is sensible (matches the wall clock time on the sending machine)
- that the RTP timestamp in the SR packets is consistent with that in the RTP data packets
- that the packet and octet count fields in the SR packets are consistent with the number of RTP data packets transmitted
And for the RR packets, verify these features too 💅:
- that the SSRC in the report block is consistent with that in the data packets being received
- that the fraction lost is zero
- that the cumulative number of packets lost is zero
- that the extended highest sequence number received is consistent with the data packets being received (provided the round trip time between test instrument and receiver is smaller than the packet inter-arrival time, this can be directly checked by the test instrument).
- that the interarrival jitter is small (a precise value cannot be given, since it depends on the test instrument and network conditions, but very little jitter should be present in this scenario).
- that the last sender report timestamp is consistent with that in the SR packets (i.e., each RR passing through the test instrument should contain the middle 32 bits from the 64 bit NTP timestamp of the last SR packet which passed through the test instrument in the opposite direction).
- that the delay since last SR field is sensible (an estimate may be made by timing the passage of an SR and corresponding RR through the test instrument, this should closely agree with the DLSR field)
You should also verify that the timestamps, packet count and octet count correctly wrap-around after the appropriate interval ⏳.
the next test is all about behaviour when packets go missing 📉. The first implementation transmits data packets, which the second implementation receives. This time, though, the test instrument is made to randomly drop a small fraction (1% is suggested) of the data packets. The second implementation should still receive and process the data packets in a normal manner, with some quality degradation, obviously 😭. The RR packets should show a loss fraction matching the drop rate of the test instrument, and should show a cumulative number of packets lost that keeps going up.
Then the loss rate on the test instrument goes back to zero, and the instrument starts delaying each packet by some random amount 🕰️. The exact amount depends on the media type, but a small fraction of the average interarrival time is reasonable. This should make the reported interarrival jitter in the RR packets go up 📈.
If these tests succeed, repeat the whole thing with the second implementation transmitting and the first receiving 🦋.
2.3.2 RTCP source description packets
okay so both implementations should get run 💖, but neither is required to transmit data packets 🫶. You want to watch the RTCP packets and check that every compound packet has an SDES packet, that the SDES packet has a CNAME item, and that the CNAME was picked by the rules in the RTP spec and profile. In lots of cases the CNAME should look like example@10.0.0.1, but a profile definition can override that 🎀.
If an app supports extra SDES items, verify that they get sent alongside the CNAME in some SDES packets. How often those extra items show up depends on the app and the profile ✨.
It should also be verified that an implementation can correctly receive NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it never sends them 🦋. This matters because it may reasonably be expected to interwork with other implementations that support those items. Receiving and ignoring such packets is valid behavior 💅.
It should be verified that an implementation correctly sets the length fields in the SDES items it sends, and that the source count and packet length fields are correct. It should be verified that SDES fields are not zero terminated 🙈.
It should be verified that an implementation correctly receives SDES items which do not terminate in a zero byte 🧚.
2.3.3 RTCP BYE packets
okay bestie, same deal here 🌸: both implementations should be run, but neither is required to transmit data packets. Then the first implementation gets made to exit, and you should verify that it sends an RTCP BYE packet. Next, verify that the second implementation reacts to that BYE packet and notes that the first one has left the session 👑.
If that test passes, restart the implementations and repeat the whole thing with the second implementation leaving the session. It's giving symmetry 🔥.
It should be verified that implementations handle BYE packets containing the optional reason for leaving text. Ignoring the text is acceptable 💜.
2.3.4 Application defined RTCP packets
ngl this one is tricky 🙈. Tests for the correct response to application defined packets are difficult to specify, since the response is clearly implementation dependent. Still, it should be verified that an implementation ignores APP packets where the 4 octet name field is unrecognized. Implementations which use APP packets should verify that they behave as expected 🍓.
2.4 RTCP transmission interval
Now we're getting into the good stuff 🌈. The basic architecture for testing the RTCP transmission interval is shown in Figure 2 ✨.
The test instrument is connected to the same LAN as the RTP implementation being tested. It is assumed that the test instrument is preconfigured with the addresses and ports used by the RTP implementation, and that it knows the RTCP bandwidth and sender/receiver fractions too. The tests can be conducted using either multicast or unicast 🦋.
The test instrument must be capable of sending arbitrarily crafted RTP and RTCP packets to the RTP implementation. The test instrument should also be capable of receiving packets sent by the RTP implementation, parsing them, and computing metrics based on those packets 💅.
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+-------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
Figure 2: Testing architecture for RTCPIt is furthermore assumed that a number of basic controls over the RTP implementation exist. These controls are:
- the ability to force the implementation to send or not send RTP packets at any desired point in time
- the ability to force the application to terminate its involvement in the RTP session, and for this termination to be known immediately to the test instrument
- the ability to set the session bandwidth and RTCP sender and receiver fractions
The second of these is required only for the test of BYE reconsideration, and it's the only part of these tests that isn't easily implementable by pure automation 🙈. It will generally require manual intervention to terminate the session from the RTP implementation and to convey this to the test instrument through some non-RTP means 🫶.
2.4.1 Basic Behavior
First up is the test that checks basic correctness of the implementation of the RTCP transmission rules 💖. This basic behavior consists of:
- periodic transmission of RTCP packets
- randomization of the interval for RTCP packet transmission
- correct implementation of the randomization interval computations, with unconditional reconsideration
The RTP implementation acts as a receiver and never sends any RTP data packets 🎀. The implementation is configured with a large session bandwidth, say 1 Mbit/s. That causes the implementation to use the minimal interval of 5s rather than the small interval based on the session bandwidth and membership size 👑. The implementation will generate RTCP packets at this minimal interval, on average. The test instrument generates no packets, but it receives the RTCP packets generated by the implementation. Each time an RTCP packet arrives, the test instrument notes the time. The difference in time between each pair of subsequent packets (called the interval) is computed. These intervals are stored so that statistics based on them can be computed. It is recommended that this observation process operate for at least 20 minutes ⭐.
An implementation passes this test if the intervals have the following properties:
- the minimum interval is never less than 2 seconds or more than 2.5 seconds;
- the maximum interval is never more than 7 seconds or less than 5.5 seconds;
- the average interval is between 4.5 and 5.5 seconds;
- the number of intervals between x and x+500ms is less than the number of intervals between x+500ms and x+1s, for any x.
In particular, an implementation fails if the packets are sent with a constant interval 💀.
2.4.2 Step join backoff
The main purpose of the reconsideration algorithm is to avoid a flood of packets that might occur when a large number of users simultaneously join an RTP session 🌊. So reconsideration exhibits a backoff behavior in sending RTCP packets when group sizes increase. This aspect of the algorithm can be tested like so 🧚.
The implementation begins operation. The test instrument waits for the arrival of the first RTCP packet. When it arrives, the test instrument notes the time and then immediately sends 100 RTCP RR packets to the implementation, each with a different SSRC and SDES CNAME. The test instrument should ensure that each RTCP packet is of the same length. Then the instrument should wait until the next RTCP packet is received from the implementation, and the time of that reception is noted 🦋.
Without reconsideration, the next RTCP packet will arrive within a short period of time. With reconsideration, transmission of this packet will be delayed. The earliest it can arrive depends on the RTCP session bandwidth, receiver fraction, and average RTCP packet size. The RTP implementation should be using the exponential averaging algorithm defined in the specification to compute the average RTCP packet size. Since this is dominated by the received packets (the implementation has only sent one itself), the average will be roughly equal to the length of the RTCP packets sent by the test instrument. So the minimum amount of time between the first and second RTCP packets from the implementation is:
T > 101 * S / ( B * Fr * (e-1.5) * 2 )Where S is the size of the RTCP packets sent by the test instrument, B is the RTCP bandwidth (normally five percent of the session bandwidth), Fr is the fraction of RTCP bandwidth allocated to receivers (normally 75 percent), and e is the natural exponent. Without reconsideration, this minimum interval Te would be much smaller:
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )B should be chosen sufficiently small so that T is around 60 seconds. Reasonable choices for these parameters are B = 950 bits per second, and S = 1024 bits. An implementation passes this test if the interval between packets is not less than T above, and not more than 3 times T ✨.
Note: in all tests the value chosen for B, the RTCP bandwidth, is calculated including the lower layer UDP/IP headers. In a typical IPv4 based implementation, these comprise 28 octets per packet. A common mistake is to forget that these are included when choosing the size of packets to transmit 🙈.
The test should be repeated for the case when the RTP implementation is a sender. This is done by having the implementation send RTP packets at least once a second. In this case, the interval between the first and second RTCP packets should be no less than:
T > S / ( B * Fs * (e-1.5) * 2 )Where Fs is the fraction of RTCP bandwidth allocated to senders, usually 25%. Note that this value of T is significantly smaller than the interval for receivers 🍓.
2.4.3. Steady State Behavior ✨
okay so on top of the basic stuff in section 2.4.1 🎀, an implementation SHOULD also nail a few spicier features:
- scale the RTCP interval with the group size;
- correctly divide bandwidth between senders and receivers;
- correctly compute the RTCP interval when the user is a sender
the implementation starts out as a receiver 🧚, and the test instrument waits for its first RTCP packet. when that lands, the instrument notes the time and immediately sends 50 RTCP RR packets and 50 RTCP SR packets to the implementation, each with its own SSRC and SDES CNAME 💅. then it sends 50 RTP packets using the 50 SSRCs from those SR packets. the test instrument SHOULD make sure every RTCP packet is the same length 🙈. next it waits for the next RTCP packet from the implementation and notes when that arrives. the gap between that arrival and the previous one gets computed and stored. after every RTCP packet arrives, the 100 RTCP and 50 RTP packets get sent again, so the 100 users don't time out as senders or members 😭. the test instrument SHOULD collect interval measurements for at least 100 RTCP packets.
with 50 senders, the implementation SHOULD NOT try to split the RTCP bandwidth between senders and receivers. instead it groups everyone together and divides the RTCP bandwidth equally 👑. the test passes if the average RTCP interval is within 5% of:
T = 101* S/Bwhere S is the size of the RTCP packets the test instrument sends, and B is the RTCP bandwidth. B SHOULD be chosen small enough that T is on the order of tens of seconds or more. reasonable values are S=1024 bits and B=3.4 kb/s.
the previous test gets repeated, but now the test instrument sends 10 RTP packets instead of 50, and 10 RTCP SR packets plus 90 RTCP RR packets instead of 50 of each. on top of that, the implementation is made to send at least one RTP packet between each of its own RTCP packets 🦋. in this case the average RTCP interval SHOULD be within 5% of:
T = 11 * S / (B * Fs)S is still the size of the RTCP packets the test instrument sends, B is the RTCP bandwidth, and Fs is the fraction of RTCP bandwidth allocated for senders (normally 25%). the values for B and S SHOULD be chosen small enough that T is on the order of tens of seconds. reasonable choices are S=1024 bits and B=1.5 kb/s.
2.4.4. Reverse Reconsideration 🔄
reverse reconsideration is basically the mirror image of normal reconsideration 🪞. instead of stretching things out, it makes the RTCP interval shrink faster when group membership drops. this keeps the RTCP info as fresh as possible and helps avoid some premature timeout drama 💜.
in the first test, the implementation joins as a receiver. the moment it sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each the same length S and each with its own SDES CNAME and SSRC. then it waits for the implementation to send another RTCP packet. once that happens, the test instrument sends 100 BYE packets. each BYE has a different SSRC, and each one matches an SSRC from the initial RTCP packets. every BYE SHOULD also be the same size as the RTCP packets the test instrument sent 🍓. that's easy to pull off by using a BYE reason to pad out the length. the time of the next RTCP packet from the implementation gets noted. the delay T between that packet (the third RTCP packet) and the previous one SHOULD be no more than:
T < 3 * S / (B * Fr * (e-1.5) * 2)here S is the size of the RTCP and BYE packets the test instrument sends, B is the RTCP bandwidth, Fr is the fraction of RTCP bandwidth allocated to receivers, and e is the natural exponent. B SHOULD be chosen so that T is on the order of tens of seconds. a reasonable choice is S=1024 bits and B=168 bits per second.
this test shows basic correctness. an implementation without reverse reconsideration won't send its next RTCP packet for nearly 100 times as long as that amount. that's a whole vibe check ✨
in the second test, the implementation joins as a receiver. as soon as it sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each of length S, followed by 100 BYE packets, also of length S. every RTCP packet carries a different SDES CNAME and SSRC, and each one is matched with exactly one BYE packet using the same SSRC. this makes the implementation see a fast jump in group membership followed by a fast drop 🎢.
the test passes if the next RTCP packet shows up T seconds after the first, and T falls within:
2.5 / (e-1.5) < T < 7.5 / (e-1.5)this checks that the pmembers variable is being maintained correctly. a broken implementation might try to run reverse reconsideration every single time a BYE comes in, instead of only when group membership drops below pmembers. if it did that, it would send an RTCP packet right after the stream of BYEs ended 🙈. for this test to work, B MUST be chosen as a large value, around 1Mb/s.
2.4.5. BYE Reconsideration 👋
BYE reconsideration works pretty much like regular reconsideration, except it's applied to BYE packets. when a user leaves the group, it MAY delay its BYE packet instead of sending one right away, if others are already sending BYEs 🌸.
the test for this goes like so. the RTP implementation joins as a receiver, and the test instrument waits for its first RTCP packet. once that arrives, the test instrument immediately sends 100 RTCP RR packets, each the same length S, each with its own SSRC and SDES CNAME. after the test instrument gets the next RTCP packet from the implementation, the RTP implementation is made to leave the RTP session. that fact gets passed to the test instrument through some non-RTP channel 🫶. the test instrument then sends 100 BYE packets, each with a different SSRC, each matching an SSRC from a previously sent RTCP packet, and each also of size S. right after the BYEs, the test instrument sends 100 RTCP RR packets using the same SSRC/CNAMEs as the original 100 RTCP packets.
the test passes if the implementation either never sends a BYE, or if it does, the BYE reaches the test instrument no earlier than T seconds and no later than 3 * T seconds after the implementation left the session. T is:
T = 100 * S / ( 2 * (e-1.5) * B )S is the size of the RTCP and BYE packets, e is the natural exponent, B is the RTCP bandwidth, and Fr is the RTCP bandwidth fraction for receivers. S and B SHOULD be chosen so that T is on the order of 50 seconds. a reasonable choice is S=1024 bits and B=1.1 kb/s.
the RTCP packets in the last step are there to check that the implementation ignores non-BYE RTCP packets once it has decided to leave the group 🙅♀️.
2.4.6. Timing out members ⏳
active RTP participants are supposed to keep sending periodic RTCP packets. when someone leaves the session, they MAY send a BYE, but that is not REQUIRED 🫠. on top of that, BYE reconsideration MAY mean a BYE never gets sent at all. so participants MUST time out other participants who haven't sent an RTCP packet in a long time. according to the spec, anyone who hasn't sent an RTCP packet in the last 5 intervals gets timed out 💀. this test checks that those timeouts actually happen correctly.
the RTP implementation joins a session as a receiver. the test instrument waits for the first RTCP packet from it. once that shows up, the test instrument sends 100 RTCP RR packets, each with a different SDES and SSRC, and notes the time. this makes the implementation believe there are now 101 group participants, so it increases its RTCP interval 📈. the test instrument keeps watching the RTCP packets from the implementation. every time one arrives, its reception time gets noted and the interval since the last one gets stored. the 100 participants spoofed by the test instrument SHOULD eventually time out at the RTP implementation. this SHOULD cause the RTCP interval to drop to its minimum.
the test passes if the interval between RTCP packets after the first is no less than:
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)and that minimum interval is sustained no later than Td seconds after the 100 RRs were sent, where Td is:
Td = 7 * 101 * S / ( B * Fr )and the interval between RTCP packets after that point is no less than:
Tf > 2.5 / (e-1.5)for this test to work, B and S MUST be chosen so that Ti is on the order of minutes. recommended values are S = 1024 bits and B = 1.9 kbps.
2.4.7. Rapid SR's 🚀
the minimum RTCP interval can be shrunk for big session bandwidths. the reduction only applies to senders. the recommended algorithm for working out this minimum is 360 divided by the RTP session bandwidth in kbps. once bandwidth goes above 72 kbps, that interval drops below 5 seconds 🏎️.
this test checks that an implementation can use a lower RTCP minimum interval when it's a sender in a high bandwidth session. it can only be run on implementations that support this reduction, since it is OPTIONAL 🧩.
the RTP implementation is set up to join the session as a sender, and the session is configured to use 360 kbps. if the recommended algorithm for the reduced minimum is used, the result is a 1 second interval. if the implementation uses a different algorithm, the session bandwidth SHOULD be set so that the reduced minimum comes out to 1 second.
once it joins, the RTP implementation SHOULD start sending both RTP and RTCP packets. the interval between RTCP packets gets measured and stored until 100 intervals have been collected ✨.
the test passes if the smallest interval is no less than 1/2 a second and the largest interval is no more than 1.5 seconds. the average SHOULD be close to 1 second. that's the whole steady-state crew, bestie 🌈💖
3. RTP translators ✨
okay so RTP translators get tested the same way we test end systems, just with the extra checks in this section 💅 here's the setup:
+-----------------+
+--------+ RTP Translator +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 3: Testing architecture for translatorsThe first RTP implementation gets told to send data to the translator, and the translator forwards those packets to the other RTP implementation after translating them however we want 🦋 then we check that the second implementation can actually play out the translated packets.
We also need to check that the packets the second implementation gets have the same SSRC as the ones the first implementation sent 🫶 the CC should be zero, and CSRC fields should not be present in the translated packets. The other RTP header fields are allowed to change depending on the translation, for example:
- the payload type should change if the translator changes the encoding of the data
- the timestamp may change if, for example, the encoding, packetisation interval or framerate is changed
- the sequence number may change if the translator merges or splits packets
- padding may be added or removed, in particular if the translator is adding or removing encryption
- the marker bit may be rewritten
If the translator changes the contents of the data packets, we also need to check that the matching RTCP packets get the same changes, and that the receivers can still process those modified RTCP packets correctly 😭 specifically:
- the SSRC is unchanged by the translator
- if the translator changes the data encoding, it should also change the octet count field in the SR packets
- if the translator combines multiple data packets into one, it should also change the packet count field in SR packets
- if the translator changes the sampling frequency of the data packets, it should also change the RTP timestamp field in the SR packets
- if the translator combines multiple data packets into one, it should also change the packet loss and extended highest sequence number fields of RR packets flowing back from the receiver (it is legal for the translator to strip the report blocks and send empty SR/RR packets, but this should only be done if the transformation of the data is such that the reception reports cannot sensibly be translated)
- the translator should forward SDES CNAME packets
- the translator may forward other SDES packets
- the translator should forward BYE packets unchanged
- the translator should forward APP packets unchanged
When the translator exits, we check that it sends a BYE packet to each receiver containing the SSRC of the other receiver 👑 then the receivers need to correctly process that BYE packet. This is different from the BYE test in section 2.3.3, because each BYE can include multiple SSRCs if the translator also sends its own RTCP information 💜
4. RTP mixers
RTP mixers get tested like end systems too, plus the stuff in this section ✨ here's the layout:
+----------------+
| Second RTP |
| implementation |
+-------+--------+
|
| +-----------+
+-------+ RTP Mixer +-----+
| +-----------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Third RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 4: Testing architecture for mixersThe first and second RTP implementations are told to send data packets to the RTP mixer. The mixer combines those packets and sends them on to the third RTP implementation. The mixer should also process RTCP packets from the other implementations, and should generate its own RTCP reports 🌸
We check that the third RTP implementation can play out the mixed packets. We also check that:
- the CC field in the RTP packets received by the third implementation is set to 2
- the RTP packets received by the third implementation contain 2 CSRCs corresponding to the first and second RTP implementations
- the RTP packets received by the third implementation contain an SSRC corresponding to that of the mixer
Next, we check that the mixer generates SR and RR packets for each cloud 🍓 the mixer should generate RR packets in the direction of the first and second implementations, and SR packets in the direction of the third implementation.
We also need to verify that the SR packets sent to the third implementation do not reference the first or second implementations, and vice versa 🙈
SDES CNAME information should be forwarded across the mixer. Other SDES fields may optionally be forwarded.
Last one: one of the implementations gets quit, and we check that the other implementations see the BYE packet. Then that implementation gets restarted, and the mixer gets quit. We check that the implementations see both the mixer and the implementations on the other side of the mixer quit. This shows they can respond to BYE packets with multiple sources 🔥
5. SSRC collision detection
RTP has a way to resolve SSRC collisions 🧚 these happen when two different session participants pick the same SSRC. In that case, both participants are supposed to send a BYE, leave the session, and rejoin with a different SSRC but the same CNAME. The point of this test is to confirm that this behaviour is actually in the implementation.
It's pretty straightforward. The RTP implementation joins the multicast group as a receiver. A test instrument waits for the first RTCP packet. Once it arrives, the test instrument notes the CNAME and SSRC from it. Then the test instrument generates an RTCP receiver report. That report contains an SDES chunk with an SSRC matching the RTP implementation's, but with a different CNAME ⚡ at this point, the implementation should send an RTCP BYE packet (containing an SDES chunk with the old SSRC and CNAME), and then rejoin, which makes it send a receiver report containing an SDES chunk with a new SSRC and the same CNAME.
The test passes if the RTP implementation sends the RTCP BYE and RTCP RR as described above within one minute of receiving the colliding RR from the test instrument ⏰ slay if it does.
6. SSRC Randomization
According to the RTP specification, SSRCs are supposed to be chosen randomly and uniformly over a 32 bit space 🎀 this is super useful for a couple of reasons:
- It reduces the probability of collisions in large groups.
- It simplifies the process of group sampling [3], which depends on the uniform distribution of SSRCs across the 32 bit space.
Ngl, checking that a random number really has 32 bits of uniform randomness takes a ton of samples 😩 so the procedure below only gives a rough check on the randomness used to generate the SSRC.
Here's how the test runs. The RTP implementation joins the group as a receiver. The test instrument waits for the first RTCP packet and notes the SSRC in it. The test is repeated 2500 times, which gives us a collection of 2500 SSRCs.
Next, the SSRCs are placed into 25 bins. An SSRC with value X goes into bin FLOOR(X/(2**32 / 25)). The idea is to split the 32 bit space into 25 regions and count how many SSRCs land in each one 🦋 ideally there should be 40 SSRCs in each bin. Of course, the actual number in each bin is a random variable whose expectation is 40. With 2500 SSRCs, the coefficient of variation of the number of SSRCs in a bin is 0.1, which means the number should be between 36 and 44. So the test passes if each bin has no less than 30 and no more than 50 SSRCs 💖
Running this test can take a lot of time, especially if there's no automated way to get the implementation to join the session. In that case, the test can be run fewer times 🌈 with 26 tests, half of the SSRCs should be less than 2**31, and the other half higher. The coefficient of variation here is 0.2, so the test is successful if there are more than 8 SSRCs less than 2**31, and less than 26.
In general, if the SSRC is collected N times and there are B bins, the coefficient of variation of the number of SSRCs in each bin is given by:
coeff = SQRT( (B-1)/N )7. Security Considerations
Implementations of RTP are subject to the security considerations mentioned in the RTP specification [1] and any applicable RTP profile (e.g., [2]) 🔐 the testing strategies described in this memo don't imply any additional security considerations.
8. Authors' Addresses
Colin Perkins
USC Information Sciences Institute
3811 North Fairfax Drive
Suite 200
Arlington, VA 22203
EMail: csp@isi.edu
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Ave.
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
EMail: schulzrinne@cs.columbia.edu9. References
[1] Schulzrinne, H., Casner, S., Frederick R. and V. Jacobson, "RTP: A Transport Protocol to Real-Time Applications", Work in Progress (update to RFC 1889), March 2001.
[2] Schulzrinne H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", Work in Progress (update to RFC 1890), March 2001.
[3] Rosenberg, J. and Schulzrinne, H. "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
Full Copyright Statement ✨
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc3158 2001-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms