Connected: An Internet Encyclopedia
2. RTP and RTCP Packet Forms and Protocol Behavior
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1890
Prev: 1. Introduction
Next: 3. Registering Payload Types
2. RTP and RTCP Packet Forms and Protocol Behavior
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.
- 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,
Section 2.2. (Note that some DES implementations require that
the 56-bit key be expanded into 8 octets by inserting an odd
parity bit in the most significant bit of the octet to go with
each 7 bits of the key.)
It is suggested that pass phrases are restricted to ASCII letters,
digits, the hyphen, and white space to reduce the the chance of
transcription errors when conveying keys by phone, fax, telex or
email.
The pass phrase may be preceded by a specification of the encryption
algorithm. Any characters up to the first slash (ASCII 0x2f) are
taken as the name of the encryption algorithm. The encryption format
specifiers should be drawn from RFC 1423 or any additional
identifiers registered with IANA. If no slash is present, DES-CBC is
assumed as default. The encryption algorithm specifier is case
sensitive.
The pass phrase typed by the user is transformed to a canonical form
before applying the hash algorithm. For that purpose, we define
return, tab, or vertical tab as well as all characters contained in
the Unicode space characters table. The transformation consists of
the following steps: (1) convert the input string to the ISO 10646
character set, using the UTF-8 encoding as specified in Annex P to
ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO
8859-1 characters do); (2) remove leading and trailing white space
characters; (3) replace one or more contiguous white space characters
by a single space (ASCII or UTF-8 0x20); (4) convert all letters to
lower case and replace sequences of characters and non-spacing
accents with a single character, where possible. A minimum length of
16 key characters (after applying the transformation) should be
enforced by the application, while applications must allow up to 256
characters of input.
- Underlying protocol
- The profile specifies the use of RTP over
unicast and multicast UDP. (This does not preclude the use of
these definitions when RTP is carried by other lower-layer
protocols.)
- Transport mapping
- The standard mapping of RTP and RTCP to
transport-level addresses is used.
- Encapsulation
- No encapsulation of RTP packets is specified.
Next: 3. Registering Payload Types
Connected: An Internet Encyclopedia
2. RTP and RTCP Packet Forms and Protocol Behavior