RTP Profile for Audio and Video Conferences with Minimal Control
RFC 1890

Document Type RFC - Proposed Standard (January 1996; No errata)
Obsoleted by RFC 3551
Author Henning Schulzrinne 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1890 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                Audio-Video Transport Working Group
Request for Comments: 1890                                H. Schulzrinne
Category: Standards Track                                      GMD Fokus
                                                            January 1996

    RTP Profile for Audio and Video Conferences with Minimal Control

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This memo describes a profile for the use of the real-time transport
   protocol (RTP), version 2, and the associated control protocol, RTCP,
   within audio and video multiparticipant conferences with minimal
   control. It provides interpretations of generic fields within the RTP
   specification suitable for audio and video conferences.  In
   particular, this document defines a set of default mappings from
   payload type numbers to encodings.

   The document also describes how audio and video data may be carried
   within RTP. It defines a set of standard encodings and their names
   when used within RTP. However, the encoding definitions are
   independent of the particular transport mechanism used. The
   descriptions provide pointers to reference implementations and the
   detailed standards. This document is meant as an aid for implementors
   of audio, video and other real-time multimedia applications.

1.  Introduction

   This profile defines aspects of RTP left unspecified in the RTP
   Version 2 protocol definition (RFC 1889). This profile is intended
   for the use within audio and video conferences with minimal session
   control. In particular, no support for the negotiation of parameters
   or membership control is provided. The profile is expected to be
   useful in sessions where no negotiation or membership control are
   used (e.g., using the static payload types and the membership
   indications provided by RTCP), but this profile may also be useful in
   conjunction with a higher-level control protocol.

Schulzrinne                 Standards Track                     [Page 1]
RFC 1890                       AV Profile                   January 1996

   Use of this profile occurs by use of the appropriate applications;
   there is no explicit indication by port number, protocol identifier
   or the like.

   Other profiles may make different choices for the items specified

2.  RTP and RTCP Packet Forms and Protocol Behavior

   The section "RTP Profiles and Payload Format Specification"
   enumerates a number of items that can be specified or modified in a
   profile. This section addresses these items. Generally, this profile
   follows the default and/or recommended aspects of the RTP

   RTP data header: The standard format of the fixed RTP data header is
        used (one marker bit).

   Payload types: Static payload types are defined in Section 6.

   RTP data header additions: No additional fixed fields are appended to
        the RTP data header.

   RTP data header extensions: No RTP header extensions are defined, but
        applications operating under this profile may use such
        extensions. Thus, applications should not assume that the RTP
        header X bit is always zero and should be prepared to ignore the
        header extension. If a header extension is defined in the
        future, that definition must specify the contents of the first
        16 bits in such a way that multiple different extensions can be

   RTCP packet types: No additional RTCP packet types are defined by
        this profile specification.

   RTCP report interval: The suggested constants are to be used for the
        RTCP report interval calculation.

   SR/RR extension: No extension section is defined for the RTCP SR or
        RR packet.

   SDES use: Applications may use any of the SDES items described.
        While CNAME information is sent every reporting interval, other
        items should be sent only every fifth reporting interval.

   Security: The RTP default security services are also the default
        under this profile.

Schulzrinne                 Standards Track                     [Page 2]
RFC 1890                       AV Profile                   January 1996

   String-to-key mapping:  A user-provided string ("pass phrase") is
        hashed with the MD5 algorithm to a 16-octet digest. An n-bit key
        is extracted from the digest by taking the first n bits from the
        digest. If several keys are needed with a total length of 128
        bits or less (as for triple DES), they are extracted in order
        from that digest. The octet ordering is specified in RFC 1423,
Show full document text