The default encryption algorithm is the Data Encryption Standard
(DES) algorithm in cipher block chaining (CBC) mode, as described in
Section 1.1 of RFC 1423 [21], except that padding to a multiple of 8
octets is indicated as described for the P bit in Section 5.1. The
initialization vector is zero because random values are supplied in
the RTP header or by the random prefix for compound RTCP packets. For
details on the use of CBC initialization vectors, see [22].
Implementations that support encryption should always support the DES
algorithm in CBC mode as the default to maximize interoperability.
This method is chosen because it has been demonstrated to be easy and
practical to use in experimental audio and video tools in operation
on the Internet. Other encryption algorithms may be specified
dynamically for a session by non-RTP means.
As an alternative to encryption at the RTP level as described above,
profiles may define additional payload types for encrypted encodings.
Those encodings must specify how padding and other aspects of the
encryption should be handled. This method allows encrypting only the
data while leaving the headers in the clear for applications where
that is desired. It may be particularly useful for hardware devices
that will handle both decryption and decoding.
9.2 Authentication and Message Integrity
Authentication and message integrity are not defined in the current
specification of RTP since these services would not be directly
feasible without a key management infrastructure. It is expected that
authentication and integrity services will be provided by lower layer
protocols in the future.
Schulzrinne, et al Standards Track [Page 50]
RFC 1889 RTP January 1996
10. RTP over Network and Transport Protocols
This section describes issues specific to carrying RTP packets within
particular network and transport protocols. The following rules apply
unless superseded by protocol-specific definitions outside this
specification.
RTP relies on the underlying protocol(s) to provide demultiplexing of
RTP data and RTCP control streams. For UDP and similar protocols, RTP
uses an even port number and the corresponding RTCP stream uses the
next higher (odd) port number. If an application is supplied with an
odd number for use as the RTP port, it should replace this number
with the next lower (even) number.
RTP data packets contain no length field or other delineation,
therefore RTP relies on the underlying protocol(s) to provide a
length indication. The maximum length of RTP packets is limited only
by the underlying protocols.
If RTP packets are to be carried in an underlying protocol that
provides the abstraction of a continuous octet stream rather than
messages (packets), an encapsulation of the RTP packets must be
defined to provide a framing mechanism. Framing is also needed if the
underlying protocol may contain padding so that the extent of the RTP
payload cannot be determined. The framing mechanism is not defined
here.
A profile may specify a framing method to be used even when RTP is
carried in protocols that do provide framing in order to allow
carrying several RTP packets in one lower-layer protocol data unit,
such as a UDP packet. Carrying several RTP packets in one network or
transport packet reduces header overhead and may simplify
synchronization between different streams.
11. Summary of Protocol Constants
This section contains a summary listing of the constants defined in
this specification.
