idnits 2.17.1 draft-ietf-avt-rtptest-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 November 2000) is 8556 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3' is mentioned on line 844, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 22 November 2000 3 Colin Perkins 4 USC/ISI 5 Jonathan Rosenberg 6 dynamicsoft 7 Henning Schulzrinne 8 Columbia University 10 RTP Testing Strategies 12 draft-ietf-avt-rtptest-04.txt 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as work in progress. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this document is unlimited. 36 Comments are solicited and should be addressed to the author and/or the 37 IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. 39 Abstract 41 This memo describes a possible testing strategy for RTP 42 implementations. It is intended as an aid to implementors 43 and does not specify a standard of any kind. 45 1 Introduction 47 This memo describes a possible testing strategy for RTP [1] implementations. 48 The tests are intended to help demonstrate interoperability of multiple 49 implementations, and to illustrate common implementation errors. They 50 are not intended to be an exhaustive set of tests and passing these 51 tests does not necessarily imply conformance to the complete RTP 52 specification. 54 This memo is for information only and does not specify a standard 55 of any kind. 57 2 End systems 59 The architecture for testing RTP end systems is shown in figure 1. 61 +-----------------+ 62 +-------+ Test instrument +-----+ 63 | +-----------------+ | 64 | | 65 +-------+--------+ +-------+--------+ 66 | First RTP | | Second RTP | 67 | implementation | | implementation | 68 +----------------+ +----------------+ 70 Figure 1: Testing architecture 72 Both RTP implementations send packets to the test instrument, which 73 forwards packets from one implementation to the other. Unless otherwise 74 specified, packets are forwarded with no additional delay and without 75 loss. The test instrument is required to delay or discard packets 76 in some of the tests. The test instrument is invisible to the RTP 77 implementations - it merely simulates poor network conditions. 79 The test instrument is also capable of logging packet contents for 80 inspection of their correctness. 82 A typical test setup might comprise three machines on a single Ethernet 83 segment. Two of these machines run the RTP implementations, the 84 third runs the test instrument. The test instrument is an application 85 level packet forwarder. Both RTP implementations are instructed to 86 send unicast RTP packets to the test instrument, which forwards packets 87 between them. 89 2.1 Media transport 91 The aim of these tests is to show that basic media flows can be 92 exchanged between the two RTP implementations. The initial test is 93 for the first RTP implementation to transmit and the second to receive. 94 If this succeeds, the process is reversed, with the second implementation 95 sending and the first receiving. 97 The receiving application should be able to handle the following 98 edge cases, in addition to normal operation: 100 o Verify reception of packets which contain padding. 102 o Verify reception of packets which have the marker bit set 104 o Verify correct operation during sequence number wrap-around. 106 o Verify correct operation during timestamp wrap-around. 108 o Verify that the implementation correctly differentiates packets 109 according to the payload type field. 111 o Verify that the implementation ignores packets with unsupported 112 payload types 114 o Verify that the implementation can playout packets containing 115 a CSRC list and non-zero CC field (see section 4). 117 The sending application should be verified to correctly handle the 118 following edge cases: 120 o If padding is used, verify that the padding length indicator 121 (last octet of the packet) is correctly set and that the length 122 of the data section of the packet corresponds to that of this 123 particular payload plus the padding. 125 o Verify correct handling of the M bit, as defined by the profile. 127 o Verify that the SSRC is chosen randomly. 129 o Verify that the initial value of the sequence number is randomly 130 selected. 132 o Verify that the sequence number increments by one for each packet 133 sent. 135 o Verify correct operation during sequence number wrap-around. 137 o Verify that the initial value of the timestamp is randomly selected. 139 o Verify correct increment of timestamp (dependent on the payload 140 format). 142 o Verify correct operation during timestamp wrap-around. 144 o Verify correct choice of payload type according to the chosen 145 payload format, profile and any session level control protocol. 147 2.2 RTP Header Extension 149 An RTP implementation which does not use an extended header should 150 be able to process packets containing an extension header by ignoring 151 the extension. 153 If an implementation makes use of the header extension, it should 154 be verified that the profile specific field and the length field 155 of the extension are set correctly, and that the length of the packet 156 is consistent. 158 2.3 Basic RTCP 160 An RTP implementation is required to send RTCP control packets in 161 addition to data packets. The architecture for testing basic RTCP 162 functions is that shown in figure 1. 164 2.3.1 Sender and receiver reports 166 The first test requires both implementations to be run, but neither 167 sends data. It should be verified that RTCP packets are generated 168 by each implementation, and that those packets are correctly received 169 by the other implementation. It should also be verified that: 171 o all RTCP packets sent are compound packets 173 o all RTCP compound packets start with an empty RR packet 175 o all RTCP compound packets contain an SDES CNAME packet 177 The first implementation should then be made to transmit data packets. 178 It should be verified that that implementation now generates SR packets 179 in place of RR packets, and that the second application now generates 180 RR packets containing a single report block. It should be verified 181 that these SR and RR packets are correctly received. The following 182 features of the SR packets should also be verified: 184 o that the length field is consistent with both the length of 185 the packet and the RC field 187 o that the SSRC in SR packets is consistent with that in the RTP 188 data packets 190 o that the NTP timestamp in the SR packets is sensible (matches 191 the wall clock time on the sending machine) 193 o that the RTP timestamp in the SR packets is consistent with 194 that in the RTP data packets 196 o that the packet and octet count fields in the SR packets are 197 consistent with the number of RTP data packets transmitted 199 In addition, the following features of the RR packets should also 200 be verified: 202 o that the SSRC in the report block is consistent with that in 203 the data packets being received 205 o that the fraction lost is zero 207 o that the cumulative number of packets lost is zero 209 o that the extended highest sequence number received is consistent 210 with the data packets being received (provided the round trip 211 time between test instrument and receiver is smaller than the 212 packet inter-arrival time, this can be directly checked by the 213 test instrument). 215 o that the interarrival jitter is small (a precise value cannot 216 be given, since it depends on the test instrument and network 217 conditions, but very little jitter should be present in this 218 scenario). 220 o that the last sender report timestamp is consistent with that 221 in the SR packets (i.e. each RR passing through the test instrument 222 should contain the middle 32 bits from the 64 bit NTP timestamp 223 of the last SR packet which passed through the test instrument 224 in the opposite direction). 226 o that the delay since last SR field is sensible (an estimate 227 may be made by timing the passage of an SR and corresponding 228 RR through the test instrument, this should closely agree with 229 the DLSR field) 231 It should also be verified that the timestamps, packet count and 232 octet count correctly wrap-around after the appropriate interval. 234 The next test is to show behaviour in the presence of packet loss. 235 The first implementation is made to transmit data packets, which 236 are received by the second implementation. This time, however, the 237 test instrument is made to randomly drop a small fraction (1% is 238 suggested) of the data packets. The second implementation should 239 be able to receive the data packets and process them in a normal 240 manner (with, of course, some quality degradation). The RR packets 241 should show a loss fraction corresponding to the drop rate of the 242 test instrument and should show an increasing cumulative number of 243 packets lost. 245 The loss rate in the test instrument is then returned to zero and 246 it is made to delay each packet by some random amount (the exact 247 amount depends on the media type, but a small fraction of the average 248 interarrival time is reasonable). The effect of this should be to 249 increase the reported interarrival jitter in the RR packets. 251 If these tests succeed, the process should be repeated with the second 252 implementation transmitting and the first receiving. 254 2.3.2 RTCP source description packets 256 Both implementations should be run, but neither is required to transmit 257 data packets. The RTCP packets should be observed and it should 258 be verified that each compound packet contains an SDES packet, that 259 that packet contains a CNAME item and that the CNAME is chosen according 260 to the rules in the RTP specification and profile (in many cases 261 the CNAME should be of the form `example@10.0.0.1' but this may be 262 overridden by a profile definition). 264 If an application supports additional SDES items then it should be 265 verified that they are sent in addition to the CNAME with some SDES 266 packets (the exact rate at which these additional items are included 267 is dependent on the application and profile). 269 It should be verified that an implementation can correctly receive 270 NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does 271 not send them. This is because it may reasonably be expected to 272 interwork with other implementations which support those items. Receiving 273 and ignoring such packets is valid behaviour. 275 It should be verified that an implementation correctly sets the length 276 fields in the SDES items it sends, and that the source count and 277 packet length fields are correct. It should be verified that SDES 278 fields are not zero terminated. 280 It should be verified that an implementation correctly receives SDES 281 items which do not terminate in a zero byte. 283 2.3.3 RTCP BYE packets 285 Both implementations should be run, but neither is required to transmit 286 data packets. The first implementation is then made to exit and 287 it should be verified that an RTCP BYE packet is sent. It should 288 be verified that the second implementation reacts to this BYE packet 289 and notes that the first implementation has left the session. 291 If the test succeeds, the implementations should be restarted and 292 the process repeated with the second implementation leaving the session. 294 It should be verified that implementations handle BYE packets containing 295 the optional reason for leaving text (ignoring the text is acceptable). 297 2.3.4 Application defined RTCP packets 299 Tests for the correct response to application defined packets are 300 difficult to specify, since the response is clearly implementation 301 dependent. It should be verified that an implementation ignores APP 302 packets where the 4 octet name field is unrecognised. Implementations 303 which use APP packets should verify that they behave as expected. 305 2.4 RTCP transmission interval 307 The basic architecture for performing tests of the RTCP transmission 308 interval is shown in figure 2. 310 +--------------+ 311 | test | 312 | instrument | 313 +-----+--------+ 314 | 315 ------+----------+-------------- LAN 316 | 317 +-------+--------+ 318 | RTP | 319 | implementation | 320 +----------------+ 322 Figure 2: Testing architecture for RTCP 324 The test instrument is connected to the same LAN as the RTP implementation 325 being tested. It is assumed that the test instrument is preconfigured 326 with the addresses and ports used by the RTP implementation, and 327 is also aware of the RTCP bandwidth and sender/receiver fractions. 328 The tests can be conducted using either multicast or unicast. 330 The test instrument must be capable of sending arbitrarily crafted 331 RTP and RTCP packets to the RTP implementation. The test instrument 332 should also be capable of receiving packets sent by the RTP implementation, 333 parsing them, and computing metrics based on those packets. 335 It is furthermore assumed that a number of basic controls over the 336 RTP implementation exist. These controls are: 338 o the ability to force the implementation to send or not send 339 RTP packets at any desired point in time 341 o the ability to force the application to terminate its involvement 342 in the RTP session, and for this termination to be known immediately 343 to the test instrument 345 o the ability to set the session bandwidth and RTCP sender and 346 receiver fractions 348 The second of these is required only for the test of BYE reconsideration, 349 and is the only aspect of these tests not easily implementable by 350 pure automation. It will generally require manual intervention to 351 terminate the session from the RTP implementation and to convey this 352 to the test instrument through some non-RTP means. 354 2.4.1 Basic Behavior 356 The first test is to verify basic correctness of the implementation 357 of the RTCP transmission rules. This basic behavior consists of: 359 o periodic transmission of RTCP packets 361 o randomization of the interval for RTCP packet transmission 363 o correct implementation of the randomization interval computations, 364 with unconditional reconsideration 366 The RTP implementation acts as a receiver, and never sends any RTP 367 data packets. The implementation is configured with a large session 368 bandwidth, say 1 Mbit/s. This will cause the implementation to use 369 the minimal interval of 5s rather than the small interval based on 370 the session bandwidth and membership size. The implementation will 371 generate RTCP packets at this minimal interval, on average. The 372 test instrument generates no packets, but receives the RTCP packets 373 generated by the implementation. When an RTCP packet is received, 374 the time is noted by the test instrument. The difference in time 375 between each pair of subsequent packets (called the interval) is 376 computed. These intervals are stored, so that statistics based on 377 these intervals can be computed. It is recommended that this observation 378 process operate for at least 20 minutes. 380 An implementation passes this test if the intervals have the following 381 properties: 383 o the minimum interval is never less than 2 seconds or more than 384 2.5 seconds; 386 o the maximum interval is never more than 7 seconds or less than 387 5.5 seconds; 389 o the average interval is between 4.5 and 5.5 seconds; 391 o the number of intervals between x and x+500ms is less than the 392 number of intervals between x+500ms and x+1s, for any x. 394 In particular, an implementation fails if the packets are sent with 395 a constant interval. 397 2.4.2 Step join backoff 399 The main purpose of the reconsideration algorithm is to avoid a flood 400 of packets that might occur when a large number of users simultaneously 401 join an RTP session. Reconsideration therefore exhibits a backoff 402 behavior in sending of RTCP packets when group sizes increase. This 403 aspect of the algorithm can be tested in the following manner. 405 The implementation begins operation. The test instrument waits for 406 the arrival of the first RTCP packet. When it arrives, the test 407 instrument notes the time and then immediately sends 100 RTCP RR 408 packets to the implementation, each with a different SSRC and SDES 409 CNAME. The test instrument should ensure that each RTCP packet is 410 of the same length. The instrument should then wait until the next 411 RTCP packet is received from the implementation, and the time of 412 such reception is noted. 414 Without reconsideration, the next RTCP packet will arrive within a 415 short period of time. With reconsideration, transmission of this 416 packet will be delayed. The earliest it can arrive depends on the 417 RTCP session bandwidth, receiver fraction, and average RTCP packet 418 size. The RTP implementation should be using the exponential averaging 419 algorithm defined in the specification to compute the average RTCP 420 packet size. Since this is dominated by the received packets (the 421 implementation has only sent one itself), the average will be roughly 422 equal to the length of the RTCP packets sent by the test instrument. 424 Therefore, the minimum amount of time between the first and second 425 RTCP packets from the implementation is: 427 T > 101 * S / ( B * Fr * (e-1.5) * 2 ) 429 Where S is the size of the RTCP packets sent by the test instrument, 430 B is the RTCP bandwidth (normally five percent of the session bandwidth), 431 Fr is the fraction of RTCP bandwidth allocated to receivers (normally 432 75 percent), and e is the natural exponent. Without reconsideration, 433 this minimum interval Te would be much smaller: 435 Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] ) 437 B should be chosen sufficiently small so that T is around 60 seconds. 438 Reasonable choices for these parameters are B = 950 bits per second, 439 and S = 1024 bits. An implementation passes this test if the interval 440 between packets is not less than T above, and not more than 3 times 441 T. 443 The test should be repeated for the case when the RTP implementation 444 is a sender. This is accomplished by having the implementation send 445 RTP packets at least once a second. In this case, the interval between 446 the first and second RTCP packets should be no less than: 448 T > S / ( B * Fs * (e-1.5) * 2 ) 450 Where Fs is the fraction of RTCP bandwidth allocated to senders, 451 usually 25%. Note that this value of T is significantly smaller 452 than the interval for receivers. 454 2.4.3 Steady State Behavior 456 In addition to the basic behavior in section 2.4.1, an implementation 457 should correctly implement a number of other, slightly more advanced 458 features: 460 o scale the RTCP interval with the group size; 462 o correctly divide bandwidth between senders and receivers; 464 o correctly compute the RTCP interval when the user is a sender 466 The implementation begins operation as a receiver. The test instrument 467 waits for the first RTCP packet from the implementation. When it 468 arrives, the test instrument notes the time, and immediately sends 469 50 RTCP RR packets and 50 RTCP SR packets to the implementation, 470 each with a different SSRC and SDES CNAME. The test instrument then 471 sends 50 RTP packets, using the 50 SSRC from the RTCP SR packets. 472 The test instrument should ensure that each RTCP packet is of the 473 same length. The instrument should then wait until the next RTCP 474 packet is received from the implementation, and the time of such 475 reception is noted. The difference between the reception of the 476 RTCP packet and the reception of the previous is computed and stored. 477 In addition, after every RTCP packet reception, the 100 RTCP and 478 50 RTP packets are retransmitted by the test instrument. This ensures 479 that the sender and member status of the 100 users does not time 480 out. The test instrument should collect the interval measurements 481 figures for at least 100 RTCP packets. 483 With 50 senders, the implementation should not try to divide the 484 RTCP bandwidth between senders and receivers, but rather group all 485 users together and divide the RTCP bandwidth equally. The test is 486 deemed successful if the average RTCP interval is within 5% of: 488 T = 101* S/B 490 Where S is the size of the RTCP packets sent by the test instrument, 491 and B is the RTCP bandwidth. B should be chosen sufficiently small 492 so that the value of T is on the order of tens of seconds or more. 493 Reasonable values are S=1024 bits and B=3.4 kb/s. 495 The previous test is repeated. However, the test instrument sends 496 10 RTP packets instead of 50, and 10 RTCP SR and 90 RTCP RR instead 497 of 50 of each. In addition, the implementation is made to send at 498 least one RTP packet between transmission of every one of its own 499 RTCP packets. 501 In this case, the average RTCP interval should be within 5% of: 503 T = 11 * S / (B * Fs) 505 Where S is the size of the RTCP packets sent by the test instrument, 506 B is the RTCP bandwidth, and Fs is the fraction of RTCP banwidth 507 allocated for senders (normally 25%). The values for B and S should 508 be chosen small enough so that T is on the order of tens of seconds. 509 Reasonable choices are S=1024 bits and B=1.5 kb/s. 511 2.4.4 Reverse Reconsideration 513 The reverse reconsideration algorithm is effectively the opposite 514 of the normal reconsideration algorithm. It causes the RTCP interval 515 to be reduced more rapidly in response to decreases in the group 516 membership. This is advantageous in that it keeps the RTCP information 517 as fresh as possible, and helps avoids some premature timeout problems. 519 In the first test, the implementation joins the session as a receiver. 520 As soon as the implementation sends its first RTCP packet, the test 521 instrument sends 100 RTCP RR packets, each of the same length S, 522 and a different SDES CNAME and SSRC in each. It then waits for the 523 implementation to send another RTCP packet. Once it does, the test 524 instrument sends 100 BYE packets, each one containing a different 525 SSRC, but matching an SSRC from one of the initial RTCP packets. 526 Each BYE should also be the same size as the RTCP packets sent by 527 the test instrument. This is easily accomplished by using a BYE 528 reason to pad out the length. The time of the next RTCP packet from 529 the implementation is then noted. The delay T between this (the 530 third RTCP packet) and the previous should be no more than: 532 T < 3 * S / (B * Fr * (e-1.5) * 2) 534 Where S is the size of the RTCP and BYE packets sent by the test 535 instrument, B is the RTCP bandwidth, Fr is the fraction of the RTCP 536 bandwidth allocated to receivers, and e is the natural exponent. 537 B should be chosen such that T is on the order of tens of seconds. 538 A reasonable choice is S=1024 bits and B=168 bits per second. 540 This test demonstrates basic correctness of implementation. An 541 implementation without reverse reconsideration will not send its 542 next RTCP packet for nearly 100 times as long as the above amount. 544 In the second test, the implementation joins the session as a receiver. 545 As soon as it sends its first RTCP packet, the test instrument sends 546 100 RTCP RR packets, each of the same length S, followed by 100 BYE 547 packets, also of length S. Each RTCP packet carries a different SDES 548 CNAME and SSRC, and is matched with precisely one BYE packet with 549 the same SSRC. This will cause the implementation to see a rapid 550 increase and then rapid drop in group membership. 552 The test is deemed succesful if the next RTCP packet shows up T seconds 553 after the first, and T is within: 555 2.5 / (e-1.5) < T < 7.5 / (e-1.5) 556 This tests correctness of the maintenance of the pmembers variable. 557 An incorrect implementation might try to execute reverse reconsideration 558 every time a BYE is received, as opposed to only when the group membership 559 drops below pmembers. If an implementation did this, it would end 560 up sending an RTCP packet immediately after receiving the stream 561 of BYE's. For this test to work, B must be chosen to be a large 562 value, around 1Mb/s. 564 2.4.5 BYE Reconsideration 566 The BYE reconsideration algorithm works in much the same fashion 567 as regular reconsideration, except applied to BYE packets. When a 568 user leaves the group, instead of sending a BYE immediately, it may 569 delay transmission of its BYE packet if others are sending BYE's. 571 The test for correctness of this algorithm is as follows. The RTP 572 implementation joins the group as a receiver. The test instrument 573 waits for the first RTCP packet. When the test instrument receives 574 this packet, the test instrument immediately sends 100 RTCP RR packets, 575 each of the same length S, and each containing a different SSRC and 576 SDES CNAME. Once the test instrument receives the next RTCP packet 577 from the implementation, the RTP implementation is made to leave 578 the RTP session, and this information is conveyed to the test instrument 579 through some non-RTP means. The test instrument then sends 100 BYE 580 packets, each with a different SSRC, and each matching an SSRC from 581 a previously transmitted RTCP packet. Each of these BYE packets 582 is also of size S. Immediately following the BYE packets, the test 583 instrument sends 100 RTCP RR packets, using the same SSRC/CNAMEs 584 as the original 100 RTCP packets. 586 The test is deemed successful if the implementation either never 587 sends a BYE, or if it does, the BYE is not received by the test 588 instrument earlier than T seconds after the implementation left the 589 session, where T is: 591 T = 100 * S / ( 2 * (e-1.5) * B * Fr) 593 S is the size of the RTCP and BYE packets, e is the natural exponent, 594 B is the RTCP bandwidth, and Fr is the RTCP bandwidth fraction for 595 receivers. S and B should be chosen so that T is on the order of 596 50 seconds. A reasonable choice is S=1024 bits and B=1.1 kb/s. 598 The transmission of the RTCP packets is meant to verify that the 599 implementation is ignoring non-BYE RTCP packets once it decides to 600 leave the group. 602 2.4.6 Timing out members 604 Active RTP participants are supposed to send periodic RTCP packets. 605 When a participant leaves the session, they may send a BYE, however 606 this is not required. Furthermore, BYE reconsideration may cause 607 a BYE to never be sent. As a result, participants must time out 608 other participants who have not sent an RTCP packet in a long time. 609 According to the specification, participants who have not sent an 610 RTCP packet in the last 5 intervals are timed out. This test verifies 611 that these timeouts are being performed correctly. 613 The RTP implementation joins a session as a receiver. The test instrument 614 waits for the first RTCP packet from the implementation. Once it 615 arrives, the test instrument sends 100 RTCP RR packets, each with 616 a different SDES and SSRC, and notes the time. This will cause the 617 implementation to believe that there are now 101 group participants, 618 causing it to increase its RTCP interval. The test instrument continues 619 to monitor the RTCP packets from the implementation. As each RTCP 620 packet is received, the time of its reception is noted, and the interval 621 between RTCP packets is stored. The 100 participants spoofed by 622 the test instrument should eventually time out at the RTP implementation. 623 This should cause the RTCP interval to be reduced to its minimum. 625 The test is deemed successful if the interval between RTCP packets 626 after the first is no less than: 628 Ti > 101 * S / ( 2 * (e-1.5) * B * Fr) 630 and this minimum interval is sustained no later than Td seconds after 631 the transmission of the 100 RR's, where Td is: 633 Td = 7 * 101 * S / ( B * Fr ) 635 and the interval between RTCP packets after this point is no less 636 than: 638 Tf > 2.5 / (e-1.5) 640 For this test to work, B and S must be chosen so Ti is on the order 641 of minutes. Recommended values are S = 1024 bits and B = 1.9 kbps. 643 2.4.7 Rapid SR's 645 The minimum interval for RTCP packets can be reduced for large session 646 bandwdiths. The reduction applies to senders only. The recommended 647 algorithm for computing this minimum interval is 360 divided by the 648 RTP session bandwidth, in kbps. For bandwidths larger than 72 kbps, 649 this interval is less than 5 seconds. 651 This test verifies the ability of an implementation to use a lower 652 RTCP minimum interval when it is a sender in a high bandwidth session. 653 The test can only be run on implementations that support this reduction, 654 since it is optional. 656 The RTP implementation is configured to join the session as a sender. 657 The session is configured to use 360 kbps. If the recommended algorithm 658 for computing the reduced minimum interval is used, the result is 659 a 1 second interval. If the RTP implementation uses a different 660 algorithm, the session bandwidth should be set in such a way to cause 661 the reduced minimum interval to be 1 second. 663 Once joining the session, the RTP implementation should begin to 664 send both RTP and RTCP packets. The interval between RTCP packets 665 is measured and stored until 100 intervals have been collected. 667 The test is deemed successful if the smallest interval is no less 668 than 1/2 a second, and the largest interval is no more than 1.5 seconds. 669 The average should be close to 1 second. 671 3 RTP translators 673 RTP translators should be tested in the same manner as end systems, 674 with the addition of the tests described in this section. 676 The architecture for testing RTP translators is shown in figure 3. 678 +-----------------+ 679 +-------+ RTP Translator +-----+ 680 | +-----------------+ | 681 | | 682 +-------+--------+ +-------+--------+ 683 | First RTP | | Second RTP | 684 | implementation | | implementation | 685 +----------------+ +----------------+ 687 Figure 3: Testing architecture for translators 689 The first RTP implementation is instructed to send data to the translator, 690 which forwards the packets to the other RTP implementation, after 691 translating then as desired. It should be verified that the second 692 implementation can playout the translated packets. 694 It should be verified that the packets received by the second implementation 695 have the same SSRC as those sent by the first implementation. The 696 CC should be zero and CSRC fields should not be present in the translated 697 packets. The other RTP header fields may be rewritten by the translator, 698 depending on the translation being performed, for example 700 o the payload type should change if the translator changes the 701 encoding of the data 703 o the timestamp may change if, for example, the encoding, packetisation 704 interval or framerate is changed 706 o the sequence number may change if the translator merges or splits 707 packets 709 o padding may be added or removed, in particular if the translator 710 is adding or removing encryption 712 o the marker bit may be rewritten 714 If the translator modifies the contents of the data packets it should 715 be verified that the corresponding change is made to the RTCP packets, 716 and that the receivers can correctly process the modified RTCP packets. 717 In particular 719 o the SSRC is unchanged by the translator 721 o if the translator changes the data encoding it should also change 722 the octet count field in the SR packets 724 o if the translator combines multiple data packets into one it 725 should also change the packet count field in SR packets 727 o if the translator changes the sampling frequency of the data 728 packets it should also change the RTP timestamp field in the 729 SR packets 731 o if the translator combines multiple data packets into one it 732 should also change the packet loss and extended highest sequence 733 number fields of RR packets flowing back from the receiver (it 734 is legal for the translator to strip the report blocks and send 735 empty SR/RR packets, but this should only be done if the transformation 736 of the data is such that the reception reports cannot sensibly 737 be translated) 739 o the translator should forward SDES CNAME packets 741 o the translator may forward other SDES packets 743 o the translator should forward BYE packets unchanged 745 o the translator should forward APP packets unchanged 747 When the translator exits it should be verified to send a BYE packet 748 to each receiver containing the SSRC of the other receiver. The 749 receivers should be verified to correctly process this BYE packet 750 (this is different to the BYE test in section 2.3.3 since multiple 751 SSRCs may be included in each BYE if the translator also sends its 752 own RTCP information). 754 4 RTP mixers 756 RTP mixers should be tested in the same manner as end systems, with 757 the addition of the tests described in this section. 759 The architecture for testing RTP mixers is shown in figure 4. 761 +----------------+ 762 | Second RTP | 763 | implementation | 764 +-------+--------+ 765 | 766 | +-----------+ 767 +-------+ RTP Mixer +-----+ 768 | +-----------+ | 769 | | 770 +-------+--------+ +-------+--------+ 771 | First RTP | | Third RTP | 772 | implementation | | implementation | 773 +----------------+ +----------------+ 775 Figure 4: Testing architecture for mixers 777 The first and second RTP implementations are instructed to send data 778 packets to the RTP mixer. The mixer combines those packets and sends 779 them to the third RTP implementation. The mixer should also process 780 RTCP packets from the other implementations, and should generate its 781 own RTCP reports. 783 It should be verified that the third RTP implementation can playout 784 the mixed packets. It should also be verified that 785 o the CC field in the RTP packets received by the third implementation 786 is set to 2 788 o the RTP packets received by the third implementation contain 789 2 CSRCs corresponding to the first and second RTP implementations 791 o the RTP packets received by the third implementation contain 792 an SSRC corresponding to that of the mixer 794 It should next be verified that the mixer generates SR and RR packets 795 for each cloud. The mixer should generate RR packets in the direction 796 of the first and second implementations, and SR packets in the direction 797 of the third implementation. 799 It should be verified that the SR packets sent to the third implementation 800 do not reference the first or second implementations, and vice versa. 802 It should be verified that SDES CNAME information is forwarded across 803 the mixer. Other SDES fields may optionally be forwarded. 805 Finally, one of the implementations should be quit, and it should 806 be verified that the other implementations see the BYE packet. This 807 implementation should then be restarted and the mixer should be quit. 808 It should be verified that the implementations see both the mixer 809 and the implementations on the other side of the mixer quit (illustrating 810 response to BYE packets containing multiple sources). 812 5 SSRC collision detection 814 RTP has provision for the resolution of SSRC collisions. These collisions 815 occur when two different session participants choose the same SSRC. 816 In this case, both participants are supposed to send a BYE, leave 817 the session, and rejoin with a different SSRC, but the same CNAME. 818 The purpose of this test is to verify that this function is present 819 in the implementation. 821 The test is straightforward. The RTP implementation is made to join 822 the multicast group as a receiver. A test instrument waits for the 823 first RTCP packet. Once it arrives, the test instrument notes the 824 CNAME and SSRC from the RTCP packet. The test instrument then generates 825 an RTCP receiver report. This receiver report contains an SDES chunk 826 with an SSRC matching that of the RTP implementation, but with a 827 different CNAME. At this point, the implementation should send a 828 BYE RTCP packet (containing an SDES chunk with the old SSRC and CNAME), 829 and then rejoin, causing it to send a receiver report containing 830 an SDES chunk, but with a new SSRC and the same CNAME. 832 The test is deemed succesful if the RTP implementation sends the 833 RTCP BYE and RTCP RR as described above within one minute of receiving 834 the colliding RR from the test instrument. 836 6 SSRC Randomization 838 According to the RTP specification, SSRC's are supposed to be chosen 839 randomly and uniformly over a 32 bit space. This randomization is 840 beneficial for several reasons: 842 o It reduces the probability of collisions in large groups. 844 o It simplifies the process of group sampling [3] which depends 845 on the uniform distribution of SSRC's across the 32 bit space. 847 Unfortunately, verifying that a random number has 32 bits of uniform 848 randomness requires a large number of samples. The procedure below 849 gives only a rough validation to the randomness used for generating 850 the SSRC. 852 The test runs as follows. The RTP implementation joins the group 853 as a receiver. The test instrument waits for the first RTCP packet. 854 It notes the SSRC in this RTCP packet. The test is repeated 2500 855 times, resulting in a collection of 2500 SSRC. 857 The are then placed into 25 bins. An SSRC with value X is placed 858 into bin FLOOR(X/(2**32 / 25)). The idea is to break the 32 bit 859 space into 25 regions, and compute the number of SSRC in each region. 860 Ideally, there should be 40 SSRC in each bin. Of course, the actual 861 number in each bin is a random variable whose expectation is 40. 862 With 2500 SSRC, the coefficient of variation of the number of SSRC 863 in a bin is 0.1, which means the number should be between 36 and 864 44. The test is thus deemed successful if each bin has no less than 865 30 and no more than 50 SSRC. 867 Running this test may require substantial amounts of time, particularly 868 if there is no automated way to have the implementation join the 869 session. In such a case, the test can be run fewer times. With 870 26 tests, half of the SSRC should be less than 2**31, and the other 871 half higher. The cofficient of variation in this case is 0.2, so 872 the test is successful if there are more than 8 SSRC less than 2**31, 873 and less than 26. 875 In general, if the SSRC is collected N times, and there are B bins, 876 the coefficient of variation of the number of SSRC in each bin is 877 given by: 879 coeff = SQRT( (B-1)/N ) 880 7 Authors' Address 882 Colin Perkins 883 USC Information Sciences Institute 884 4350 North Fairfax Drive 885 Suite 620 886 Arlington, VA 22203 887 Email: csp@isi.edu 889 Jonathan Rosenberg 890 dynamicsoft 891 72 Eagle Rock Ave. 892 First Floor 893 East Hanover, NJ 07936 894 Email: jdrosen@dynamicsoft.com 896 Henning Schulzrinne 897 Columbia University 898 M/S 0401 899 1214 Amsterdam Ave. 900 New York, NY 10027-7003 901 Email: schulzrinne@cs.columbia.edu 903 8 References 905 [1] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: 906 A Transport Protocol to Real-Time Applications'', Work in progress, 907 Internet Engineering Task Force, July 2000.