RTP Testing Strategies (RFC3158)

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