RTP Testing Strategies
RFC 3158

Document Type RFC - Informational (August 2001; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3158 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text