RFC 1890 (rfc1890) - Page 2 of 18
RTP Profile for Audio and Video Conferences with Minimal Control
Alternative Format: Original Text Document
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 here. 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 specification. 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 identified. 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
