rfc3158.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

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.