File: rfc3158.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1235 lines) | stat: -rw-r--r-- 48,208 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235






Network Working Group                                         C. Perkins
Request for Comments: 3158                                       USC/ISI
Category: Informational                                     J. Rosenberg
                                                             dynamicsoft
                                                          H. Schulzrinne
                                                     Columbia University
                                                             August 2001


                         RTP Testing Strategies

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



Perkins, et al.              Informational                      [Page 1]

RFC 3158                 RTP Testing Strategies              August 2001


   6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19
   7 Security Considerations . . . . . . . . . . . . . . . . 20
   8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20
   9 References. . . . . . . . . . . . . . . . . . . . . . . 21
   Full Copyright Statement. . . . . . . . . . . . . . . . . 22

1 Introduction

   This memo describes a possible testing strategy for RTP [1]
   implementations.  The tests are intended to help demonstrate
   interoperability of multiple implementations, and to illustrate
   common implementation errors.  They are not intended to be an
   exhaustive set of tests and passing these tests does not necessarily
   imply conformance to the complete RTP specification.

2 End systems

   The architecture for testing RTP end systems is shown in Figure 1.

                             +-----------------+
                    +--------+ Test instrument +-----+
                    |        +-----------------+     |
                    |                                |
            +-------+--------+               +-------+--------+
            |     First RTP  |               |   Second RTP   |
            | implementation |               | implementation |
            +----------------+               +----------------+

                     Figure 1:  Testing architecture

   Both RTP implementations send packets to the test instrument, which
   forwards packets from one implementation to the other.  Unless
   otherwise specified, packets are forwarded with no additional delay
   and without loss.  The test instrument is required to delay or
   discard packets in some of the tests.  The test instrument is
   invisible to the RTP implementations - it merely simulates poor
   network conditions.

   The test instrument is also capable of logging packet contents for
   inspection of their correctness.

   A typical test setup might comprise three machines on a single
   Ethernet segment.  Two of these machines run the RTP implementations,
   the third runs the test instrument.  The test instrument is an
   application level packet forwarder.  Both RTP implementations are
   instructed to send unicast RTP packets to the test instrument, which
   forwards packets between them.




Perkins, et al.              Informational                      [Page 2]

RFC 3158                 RTP Testing Strategies              August 2001


2.1 Media transport

   The aim of these tests is to show that basic media flows can be
   exchanged between the two RTP implementations.  The initial test is
   for the first RTP implementation to transmit and the second to
   receive.  If this succeeds, the process is reversed, with the second
   implementation sending and the first receiving.

   The receiving application should be able to handle the following edge
   cases, in addition to normal operation:

      o  Verify reception of packets which contain padding.

      o  Verify reception of packets which have the marker bit set

      o  Verify correct operation during sequence number wrap-around.

      o  Verify correct operation during timestamp wrap-around.

      o  Verify that the implementation correctly differentiates packets
         according to the payload type field.

      o  Verify that the implementation ignores packets with unsupported
         payload types

      o  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 the
   following edge cases:

      o  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.

      o  Verify correct handling of the M bit, as defined by the
         profile.

      o  Verify that the SSRC is chosen randomly.

      o  Verify that the initial value of the sequence number is
         randomly selected.

      o  Verify that the sequence number increments by one for each
         packet sent.

      o  Verify correct operation during sequence number wrap-around.



Perkins, et al.              Informational                      [Page 3]

RFC 3158                 RTP Testing Strategies              August 2001


      o  Verify that the initial value of the timestamp is randomly
         selected.

      o  Verify correct increment of timestamp (dependent on the payload
         format).

      o  Verify correct operation during timestamp wrap-around.

      o  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 which does not use an extended header should be
   able to process packets containing an extension header by ignoring
   the extension.

   If an implementation makes use of the header extension, it should be
   verified 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 architecture for testing basic RTCP
   functions is that shown in Figure 1.

2.3.1 Sender and receiver reports

   The first test requires both implementations to be run, but neither
   sends data.  It should be verified that RTCP packets are generated by
   each implementation, and that those packets are correctly received by
   the other implementation.  It should also be verified that:

      o  all RTCP packets sent are compound packets

      o  all RTCP compound packets start with an empty RR packet

      o  all RTCP compound packets contain an SDES CNAME packet

   The first implementation should then be made to transmit data
   packets.  It should be verified that that implementation now
   generates SR packets in place of RR packets, and that the second
   application now generates RR packets containing a single report
   block.  It should be verified that these SR and RR packets are
   correctly received.  The following features of the SR packets should
   also be verified:



Perkins, et al.              Informational                      [Page 4]

RFC 3158                 RTP Testing Strategies              August 2001


      o  that the length field is consistent with both the length of the
         packet and the RC field

      o  that the SSRC in SR packets is consistent with that in the RTP
         data packets

      o  that the NTP timestamp in the SR packets is sensible (matches
         the wall clock time on the sending machine)

      o  that the RTP timestamp in the SR packets is consistent with
         that in the RTP data packets

      o  that the packet and octet count fields in the SR packets are
         consistent with the number of RTP data packets transmitted

   In addition, the following features of the RR packets should also be
   verified:

      o  that the SSRC in the report block is consistent with that in
         the data packets being received

      o  that the fraction lost is zero

      o  that the cumulative number of packets lost is zero

      o  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).

      o  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).

      o  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).

      o  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)





Perkins, et al.              Informational                      [Page 5]

RFC 3158                 RTP Testing Strategies              August 2001


   It should also be verified that the timestamps, packet count and
   octet count correctly wrap-around after the appropriate interval.

   The next test is to show behavior in the presence of packet loss.
   The first implementation is made to transmit data packets, which are
   received by the second implementation.  This time, however, the test
   instrument is made to randomly drop a small fraction (1% is
   suggested) of the data packets.  The second implementation should be
   able to receive the data packets and process them in a normal manner
   (with, of course, some quality degradation).  The RR packets should
   show a loss fraction corresponding to the drop rate of the test
   instrument and should show an increasing cumulative number of packets
   lost.

   The loss rate in the test instrument is then returned to zero and it
   is made to delay 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).  The effect of this should be to
   increase the reported interarrival jitter in the RR packets.

   If these tests succeed, the process should be repeated with the
   second implementation transmitting and the first receiving.

2.3.2 RTCP source description packets

   Both implementations should be run, but neither is required to
   transmit data packets.  The RTCP packets should be observed and it
   should be verified that each compound packet contains an SDES packet,
   that that packet contains a CNAME item and that the CNAME is chosen
   according to the rules in the RTP specification and profile (in many
   cases the CNAME should be of the form `example@10.0.0.1' but this may
   be overridden by a profile definition).

   If an application supports additional SDES items then it should be
   verified that they are sent in addition to the CNAME with some SDES
   packets (the exact rate at which these additional items are included
   is dependent on the application and profile).

   It should be verified that an implementation can correctly receive
   NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does
   not send them.  This is because it may reasonably be expected to
   interwork with other implementations which 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.



Perkins, et al.              Informational                      [Page 6]

RFC 3158                 RTP Testing Strategies              August 2001


   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

   Both implementations should be run, but neither is required to
   transmit data packets.  The first implementation is then made to exit
   and it should be verified that an RTCP BYE packet is sent.  It should
   be verified that the second implementation reacts to this BYE packet
   and notes that the first implementation has left the session.

   If the test succeeds, the implementations should be restarted and the
   process repeated with the second implementation leaving the session.

   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

   Tests for the correct response to application defined packets are
   difficult to specify, since the response is clearly implementation
   dependent.  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

   The basic architecture for performing tests of 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 is also aware of the RTCP bandwidth and
   sender/receiver fractions.  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.







Perkins, et al.              Informational                      [Page 7]

RFC 3158                 RTP Testing Strategies              August 2001


                          +--------------+
                          |     test     |
                          |  instrument  |
                          +-----+--------+
                                |
              ------+-----------+-------------- LAN
                    |
            +-------+--------+
            |       RTP      |
            | implementation |
            +----------------+

            Figure 2:  Testing architecture for RTCP

   It is furthermore assumed that a number of basic controls over the
   RTP implementation exist.  These controls are:

      o  the ability to force the implementation to send or not send RTP
         packets at any desired point in time

      o  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

      o  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 is the only aspect of these tests not 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

   The first test is to verify basic correctness of the implementation
   of the RTCP transmission rules.  This basic behavior consists of:

      o  periodic transmission of RTCP packets

      o  randomization of the interval for RTCP packet transmission

      o  correct implementation of the randomization interval
         computations, with unconditional reconsideration







Perkins, et al.              Informational                      [Page 8]

RFC 3158                 RTP Testing Strategies              August 2001


   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.  This will cause 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 receives the RTCP packets
   generated by the implementation.  When an RTCP packet is received,
   the time is noted by the test instrument.  The difference in time
   between each pair of subsequent packets (called the interval) is
   computed.  These intervals are stored, so that statistics based on
   these intervals 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:

      o  the minimum interval is never less than 2 seconds or more than
         2.5 seconds;

      o  the maximum interval is never more than 7 seconds or less than
         5.5 seconds;

      o  the average interval is between 4.5 and 5.5 seconds;

      o  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.  Reconsideration therefore
   exhibits a backoff behavior in sending of RTCP packets when group
   sizes increase.  This aspect of the algorithm can be tested in the
   following manner.

   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.  The instrument should then wait until the next RTCP
   packet is received from the implementation, and the time of such
   reception is noted.



Perkins, et al.              Informational                      [Page 9]

RFC 3158                 RTP Testing Strategies              August 2001


   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.  Therefore, 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 accomplished 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.






Perkins, et al.              Informational                     [Page 10]

RFC 3158                 RTP Testing Strategies              August 2001


2.4.3 Steady State Behavior

   In addition to the basic behavior in section 2.4.1, an implementation
   should correctly implement a number of other, slightly more advanced
   features:

      o  scale the RTCP interval with the group size;

      o  correctly divide bandwidth between senders and receivers;

      o  correctly compute the RTCP interval when the user is a sender

   The implementation begins operation as a receiver.  The test
   instrument waits for the first RTCP packet from the implementation.
   When it arrives, the test instrument notes the time, and immediately
   sends 50 RTCP RR packets and 50 RTCP SR packets to the
   implementation, each with a different SSRC and SDES CNAME.  The test
   instrument then sends 50 RTP packets, using the 50 SSRC from the RTCP
   SR packets.  The test instrument should ensure that each RTCP packet
   is of the same length.  The instrument should then wait until the
   next RTCP packet is received from the implementation, and the time of
   such reception is noted.  The difference between the reception of the
   RTCP packet and the reception of the previous is computed and stored.
   In addition, after every RTCP packet reception, the 100 RTCP and 50
   RTP packets are retransmitted by the test instrument.  This ensures
   that the sender and member status of the 100 users does not time out.
   The test instrument should collect the interval measurements figures
   for at least 100 RTCP packets.

   With 50 senders, the implementation should not try to divide the RTCP
   bandwidth between senders and receivers, but rather group all users
   together and divide the RTCP bandwidth equally.  The test is deemed
   successful if the average RTCP interval is within 5% of:

      T = 101* S/B

   Where S is the size of the RTCP packets sent by the test instrument,
   and B is the RTCP bandwidth.  B should be chosen sufficiently small
   so that the value of 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 is repeated.  However, the test instrument sends 10
   RTP packets instead of 50, and 10 RTCP SR and 90 RTCP RR instead of
   50 of each.  In addition, the implementation is made to send at least
   one RTP packet between transmission of every one of its own RTCP
   packets.





Perkins, et al.              Informational                     [Page 11]

RFC 3158                 RTP Testing Strategies              August 2001


   In this case, the average RTCP interval should be within 5% of:

      T = 11 * S / (B * Fs)

   Where S is the size of the RTCP packets sent by the test instrument,
   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 so 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

   The reverse reconsideration algorithm is effectively the opposite of
   the normal reconsideration algorithm.  It causes the RTCP interval to
   be reduced more rapidly in response to decreases in the group
   membership.  This is advantageous in that it keeps the RTCP
   information as fresh as possible, and helps avoids some premature
   timeout problems.

   In the first test, the implementation joins the session as a
   receiver.  As soon as the implementation sends its first RTCP packet,
   the test instrument sends 100 RTCP RR packets, each of the same
   length S, and a different SDES CNAME and SSRC in each.  It then waits
   for the implementation to send another RTCP packet.  Once it does,
   the test instrument sends 100 BYE packets, each one containing a
   different SSRC, but matching an SSRC from one of the initial RTCP
   packets.  Each BYE should also be the same size as the RTCP packets
   sent by the test instrument.  This is easily accomplished by using a
   BYE reason to pad out the length.  The time of the next RTCP packet
   from the implementation is then noted.  The delay T between this (the
   third RTCP packet) and the previous should be no more than:

      T < 3 * S / (B * Fr * (e-1.5) * 2)

   Where S is the size of the RTCP and BYE packets sent by the test
   instrument, B is the RTCP bandwidth, Fr is the fraction of the RTCP
   bandwidth allocated to receivers, and e is the natural exponent.  B
   should be chosen such 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 demonstrates basic correctness of implementation.  An
   implementation without reverse reconsideration will not send its next
   RTCP packet for nearly 100 times as long as the above amount.

   In the second test, the implementation joins the session as a
   receiver.  As soon as it sends its first RTCP packet, the test
   instrument sends 100 RTCP RR packets, each of the same length S,
   followed by 100 BYE packets, also of length S.  Each RTCP packet



Perkins, et al.              Informational                     [Page 12]

RFC 3158                 RTP Testing Strategies              August 2001


   carries a different SDES CNAME and SSRC, and is matched with
   precisely one BYE packet with the same SSRC.  This will cause the
   implementation to see a rapid increase and then rapid drop in group
   membership.

   The test is deemed successful if the next RTCP packet shows up T
   seconds after the first, and T is within:

      2.5 / (e-1.5) < T < 7.5 / (e-1.5)

   This tests correctness of the maintenance of the pmembers variable.
   An incorrect implementation might try to execute reverse
   reconsideration every time a BYE is received, as opposed to only when
   the group membership drops below pmembers.  If an implementation did
   this, it would end up sending an RTCP packet immediately after
   receiving the stream of BYE's.  For this test to work, B must be
   chosen to be a large value, around 1Mb/s.

2.4.5 BYE Reconsideration

   The BYE reconsideration algorithm works in much the same fashion as
   regular reconsideration, except applied to BYE packets.  When a user
   leaves the group, instead of sending a BYE immediately, it may delay
   transmission of its BYE packet if others are sending BYE's.

   The test for correctness of this algorithm is as follows.  The RTP
   implementation joins the group as a receiver.  The test instrument
   waits for the first RTCP packet.  When the test instrument receives
   this packet, the test instrument immediately sends 100 RTCP RR
   packets, each of the same length S, and each containing a different
   SSRC and SDES CNAME.  Once the test instrument receives the next RTCP
   packet from the implementation, the RTP implementation is made to
   leave the RTP session, and this information is conveyed to the test
   instrument through some non-RTP means.  The test instrument then
   sends 100 BYE packets, each with a different SSRC, and each matching
   an SSRC from a previously transmitted RTCP packet.  Each of these BYE
   packets is also of size S.  Immediately following the BYE packets,
   the test instrument sends 100 RTCP RR packets, using the same
   SSRC/CNAMEs as the original 100 RTCP packets.

   The test is deemed successful if the implementation either never
   sends a BYE, or if it does, the BYE is received by the test
   instrument not earlier than T seconds, and not later than 3 * T
   seconds, after the implementation left the session, where T is:

      T = 100 * S / ( 2 * (e-1.5) * B )





Perkins, et al.              Informational                     [Page 13]

RFC 3158                 RTP Testing Strategies              August 2001


   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 transmission of the RTCP packets is meant to verify that the
   implementation is ignoring non-BYE RTCP packets once it decides to
   leave the group.

2.4.6 Timing out members

   Active RTP participants are supposed to send periodic RTCP packets.
   When a participant leaves the session, they may send a BYE, however
   this is not required.  Furthermore, BYE reconsideration may cause a
   BYE to never be sent.  As a result, participants must time out other
   participants who have not sent an RTCP packet in a long time.
   According to the specification, participants who have not sent an
   RTCP packet in the last 5 intervals are timed out.  This test
   verifies that these timeouts are being performed correctly.

   The RTP implementation joins a session as a receiver.  The test
   instrument waits for the first RTCP packet from the implementation.
   Once it arrives, the test instrument sends 100 RTCP RR packets, each
   with a different SDES and SSRC, and notes the time.  This will cause
   the implementation to believe that there are now 101 group
   participants, causing it to increase its RTCP interval.  The test
   instrument continues to monitor the RTCP packets from the
   implementation.  As each RTCP packet is received, the time of its
   reception is noted, and the interval between RTCP packets is stored.
   The 100 participants spoofed by the test instrument should eventually
   time out at the RTP implementation.  This should cause the RTCP
   interval to be reduced to its minimum.

   The test is deemed successful if the interval between RTCP packets
   after the first is no less than:

      Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)

   and this minimum interval is sustained no later than Td seconds after
   the transmission of the 100 RR's, where Td is:

      Td = 7 * 101 * S / ( B * Fr )

   and the interval between RTCP packets after this point is no less
   than:

      Tf > 2.5 / (e-1.5)




Perkins, et al.              Informational                     [Page 14]

RFC 3158                 RTP Testing Strategies              August 2001


   For this test to work, B and S must be chosen so 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 interval for RTCP packets can be reduced for large
   session bandwidths.  The reduction applies to senders only.  The
   recommended algorithm for computing this minimum interval is 360
   divided by the RTP session bandwidth, in kbps.  For bandwidths larger
   than 72 kbps, this interval is less than 5 seconds.

   This test verifies the ability of an implementation to use a lower
   RTCP minimum interval when it is a sender in a high bandwidth
   session.  The test can only be run on implementations that support
   this reduction, since it is optional.

   The RTP implementation is configured to join the session as a sender.
   The session is configured to use 360 kbps.  If the recommended
   algorithm for computing the reduced minimum interval is used, the
   result is a 1 second interval.  If the RTP implementation uses a
   different algorithm, the session bandwidth should be set in such a
   way to cause the reduced minimum interval to be 1 second.

   Once joining the session, the RTP implementation should begin to send
   both RTP and RTCP packets.  The interval between RTCP packets is
   measured and stored until 100 intervals have been collected.

   The test is deemed successful 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.

3 RTP translators

   RTP translators should be tested in the same manner as end systems,
   with the addition of the tests described in this section.

   The architecture for testing RTP translators is shown in Figure 3.

                             +-----------------+
                    +--------+  RTP Translator +-----+
                    |        +-----------------+     |
                    |                                |
            +-------+--------+               +-------+--------+
            |     First RTP  |               |   Second RTP   |
            | implementation |               | implementation |
            +----------------+               +----------------+

              Figure 3:  Testing architecture for translators



Perkins, et al.              Informational                     [Page 15]

RFC 3158                 RTP Testing Strategies              August 2001


   The first RTP implementation is instructed to send data to the
   translator, which forwards the packets to the other RTP
   implementation, after translating then as desired.  It should be
   verified that the second implementation can playout the translated
   packets.

   It should be verified that the packets received by the second
   implementation have the same SSRC as those sent by the first
   implementation.  The CC should be zero and CSRC fields should not be
   present in the translated packets.  The other RTP header fields may
   be rewritten by the translator, depending on the translation being
   performed, for example

      o  the payload type should change if the translator changes the
         encoding of the data

      o  the timestamp may change if, for example, the encoding,
         packetisation interval or framerate is changed

      o  the sequence number may change if the translator merges or
         splits packets

      o  padding may be added or removed, in particular if the
         translator is adding or removing encryption

      o  the marker bit may be rewritten

   If the translator modifies the contents of the data packets it should
   be verified that the corresponding change is made to the RTCP
   packets, and that the receivers can correctly process the modified
   RTCP packets.  In particular

      o  the SSRC is unchanged by the translator

      o  if the translator changes the data encoding it should also
         change the octet count field in the SR packets

      o  if the translator combines multiple data packets into one it
         should also change the packet count field in SR packets

      o  if the translator changes the sampling frequency of the data
         packets it should also change the RTP timestamp field in the SR
         packets

      o  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



Perkins, et al.              Informational                     [Page 16]

RFC 3158                 RTP Testing Strategies              August 2001


         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)

      o  the translator should forward SDES CNAME packets

      o  the translator may forward other SDES packets

      o  the translator should forward BYE packets unchanged

      o  the translator should forward APP packets unchanged

   When the translator exits it should be verified to send a BYE packet
   to each receiver containing the SSRC of the other receiver.  The
   receivers should be verified to correctly process this BYE packet
   (this is different to the BYE test in section 2.3.3 since multiple
   SSRCs may be included in each BYE if the translator also sends its
   own RTCP information).

4 RTP mixers

   RTP mixers should be tested in the same manner as end systems, with
   the addition of the tests described in this section.

   The architecture for testing RTP mixers is shown in Figure 4.

   The first and second RTP implementations are instructed to send data
   packets to the RTP mixer.  The mixer combines those packets and sends
   them to the third RTP implementation.  The mixer should also process
   RTCP packets from the other implementations, and should generate its
   own RTCP reports.

            +----------------+
            |   Second RTP   |
            | implementation |
            +-------+--------+
                     |
                     |       +-----------+
                     +-------+ RTP Mixer +-----+
                     |       +-----------+     |
                     |                         |
            +-------+--------+         +-------+--------+
            |    First RTP   |         |    Third RTP   |
            | implementation |         | implementation |
            +----------------+         +----------------+

             Figure 4:  Testing architecture for mixers




Perkins, et al.              Informational                     [Page 17]

RFC 3158                 RTP Testing Strategies              August 2001


   It should be verified that the third RTP implementation can playout
   the mixed packets.  It should also be verified that

      o  the CC field in the RTP packets received by the third
         implementation is set to 2

      o  the RTP packets received by the third implementation contain 2
         CSRCs corresponding to the first and second RTP implementations

      o  the RTP packets received by the third implementation contain an
         SSRC corresponding to that of the mixer

   It should next be verified 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.

   It should be verified that the SR packets sent to the third
   implementation do not reference the first or second implementations,
   and vice versa.

   It should be verified that SDES CNAME information is forwarded across
   the mixer.  Other SDES fields may optionally be forwarded.

   Finally, one of the implementations should be quit, and it should be
   verified that the other implementations see the BYE packet.  This
   implementation should then be restarted and the mixer should be quit.
   It should be verified that the implementations see both the mixer and
   the implementations on the other side of the mixer quit (illustrating
   response to BYE packets containing multiple sources).

5 SSRC collision detection

   RTP has provision for the resolution of SSRC collisions.  These
   collisions occur when two different session participants choose the
   same SSRC.  In this case, both participants are supposed to send a
   BYE, leave the session, and rejoin with a different SSRC, but the
   same CNAME.  The purpose of this test is to verify that this function
   is present in the implementation.

   The test is straightforward.  The RTP implementation is made to join
   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 the RTCP packet.  The test instrument then
   generates an RTCP receiver report.  This receiver report contains an
   SDES chunk with an SSRC matching that of the RTP implementation, but
   with a different CNAME.  At this point, the implementation should




Perkins, et al.              Informational                     [Page 18]

RFC 3158                 RTP Testing Strategies              August 2001


   send a BYE RTCP packet (containing an SDES chunk with the old SSRC
   and CNAME), and then rejoin, causing it to send a receiver report
   containing an SDES chunk, but with a new SSRC and the same CNAME.

   The test is deemed successful 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.

6 SSRC Randomization

   According to the RTP specification, SSRC's are supposed to be chosen
   randomly and uniformly over a 32 bit space.  This randomization is
   beneficial for several reasons:

      o  It reduces the probability of collisions in large groups.

      o  It simplifies the process of group sampling [3] which depends
         on the uniform distribution of SSRC's across the 32 bit space.

   Unfortunately, verifying that a random number has 32 bits of uniform
   randomness requires a large number of samples.  The procedure below
   gives only a rough validation to the randomness used for generating
   the SSRC.

   The test runs as follows.  The RTP implementation joins the group as
   a receiver.  The test instrument waits for the first RTCP packet.  It
   notes the SSRC in this RTCP packet.  The test is repeated 2500 times,
   resulting in a collection of 2500 SSRC.

   The are then placed into 25 bins.  An SSRC with value X is placed
   into bin FLOOR(X/(2**32 / 25)).  The idea is to break the 32 bit
   space into 25 regions, and compute the number of SSRC in each region.
   Ideally, there should be 40 SSRC in each bin.  Of course, the actual
   number in each bin is a random variable whose expectation is 40.
   With 2500 SSRC, the coefficient of variation of the number of SSRC in
   a bin is 0.1, which means the number should be between 36 and 44.
   The test is thus deemed successful if each bin has no less than 30
   and no more than 50 SSRC.

   Running this test may require substantial amounts of time,
   particularly if there is no automated way to have the implementation
   join the session.  In such a case, the test can be run fewer times.
   With 26 tests, half of the SSRC should be less than 2**31, and the
   other half higher.  The coefficient of variation in this case is 0.2,
   so the test is successful if there are more than 8 SSRC less than
   2**31, and less than 26.





Perkins, et al.              Informational                     [Page 19]

RFC 3158                 RTP Testing Strategies              August 2001


   In general, if the SSRC is collected N times, and there are B bins,
   the coefficient of variation of the number of SSRC 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]).  There are no additional security considerations implied
   by the testing strategies described in this memo.

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.edu











Perkins, et al.              Informational                     [Page 20]

RFC 3158                 RTP Testing Strategies              August 2001


9 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.







































Perkins, et al.              Informational                     [Page 21]

RFC 3158                 RTP Testing Strategies              August 2001


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.



















Perkins, et al.              Informational                     [Page 22]