Payload types: Assuming that a payload type field is included, the
profile will usually define a set of payload formats (e.g.,
media encodings) and a default static mapping of those formats
to payload type values. Some of the payload formats may be
defined by reference to separate payload format specifications.
For each payload type defined, the profile must specify the RTP
timestamp clock rate to be used (Section 5.1).
RTP data header additions: Additional fields may be appended to the
fixed RTP data header if some additional functionality is
required across the profile's class of applications independent
of payload type (Section 5.3).
Schulzrinne, et al Standards Track [Page 53]
RFC 1889 RTP January 1996
RTP data header extensions: The contents of the first 16 bits of the
RTP data header extension structure must be defined if use of
that mechanism is to be allowed under the profile for
implementation-specific extensions (Section 5.3.1).
RTCP packet types: New application-class-specific RTCP packet types
may be defined and registered with IANA.
RTCP report interval: A profile should specify that the values
suggested in Section 6.2 for the constants employed in the
calculation of the RTCP report interval will be used. Those are
the RTCP fraction of session bandwidth, the minimum report
interval, and the bandwidth split between senders and receivers.
A profile may specify alternate values if they have been
demonstrated to work in a scalable manner.
SR/RR extension: An extension section may be defined for the RTCP SR
and RR packets if there is additional information that should be
reported regularly about the sender or receivers (Section 6.3.3).
SDES use: The profile may specify the relative priorities for RTCP
SDES items to be transmitted or excluded entirely (Section
6.2.2); an alternate syntax or semantics for the CNAME item
(Section 6.4.1); the format of the LOC item (Section 6.4.5); the
semantics and use of the NOTE item (Section 6.4.7); or new SDES
item types to be registered with IANA.
Security: A profile may specify which security services and
algorithms should be offered by applications, and may provide
guidance as to their appropriate use (Section 9).
String-to-key mapping: A profile may specify how a user-provided
password or pass phrase is mapped into an encryption key.
Underlying protocol: Use of a particular underlying network or
transport layer protocol to carry RTP packets may be required.
Transport mapping: A mapping of RTP and RTCP to transport-level
addresses, e.g., UDP ports, other than the standard mapping
defined in Section 10 may be specified.
