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