RTP Profile for Audio and Video Conferences with Minimal Control
obsoleted by
- rfc-3551 — RTP Profile for Audio and Video Conferences with Minimal Control
Extracted elements (30)
Default port numbers 5004/5005 were chosen to lie above 5000 to accommodate Unix OS port allocation practice: ports below 1024 require privileged processes, and ports 1024–5000 are automatically assigned by the OS.
Pass phrases are recommended to be restricted to ASCII letters, digits, hyphens, and white space to reduce transcription errors when conveying keys by phone, fax, telex, or email.
Video timestamp clock rate of 90 kHz was chosen because it yields exact integer timestamp increments for 24, 25, 29.97, and 30 Hz frame rates and 50, 59.94, 60 Hz field rates. Using the video frame rate directly (15–30 Hz) is insufficient for synchronization accuracy in RTCP SR/RR jitter estimates.
A single fixed RTP port pair cannot be required under this profile because multiple applications may run on the same host and some operating systems do not allow multiple processes to use the same UDP port with different multicast addresses.
DVI4 as defined in this profile differs from IMA ADPCM in two ways: the header contains the predicted value rather than the first sample value, and DVI4 uses only an even number of compressed samples per block (no header-embedded first sample), unlike IMA ADPCM blocks.
A minimum length of 16 key characters (after whitespace normalization) SHOULD be enforced by the application for pass phrases; applications MUST allow up to 256 characters of input.
A receiver SHOULD accept packets representing between 0 and 200 ms of audio data; this restriction allows reasonable buffer sizing at the receiver.
An RTP source emits a single RTP payload type at any given time; the interleaving of several RTP payload types in a single RTP session is not allowed. Multiple RTP sessions may be used in parallel to send multiple media.
Applications SHOULD NOT assume that the RTP header X bit is always zero and SHOULD be prepared to ignore the header extension. Any future extension definition must allow identification of multiple different extensions via the first 16 bits.
Audio applications operating under this profile SHOULD, at minimum, be able to send and receive payload types 0 (PCMU) and 5 (DVI4) to allow interoperability without format negotiation.
Audio channels are numbered left-to-right starting at one, and information from lower-numbered channels precedes that from higher-numbered channels in RTP audio packets.
CNAME SDES information MUST be sent every RTCP reporting interval, while other SDES items should be sent only every fifth reporting interval.
For applications using silence suppression, the first packet of a talkspurt (first packet after a silence period) MUST be distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero.
For frame-based audio codecs, the channel order is defined for the whole block: for two-channel audio, the encoded frame for the left channel precedes that for the right channel. All frame-oriented audio codecs should be able to encode and decode several consecutive frames within a single packet.
For sample-based encodings producing one or more octets per sample, samples from different channels at the same sampling instant are packed in consecutive octets (left then right for stereo). Multi-octet encodings are transmitted in network byte order (most significant octet first).
Payload type values in the range 96–127 may be defined dynamically through a conference control protocol beyond the scope of this document. Values 72–76 are reserved so that RTCP and RTP packets can be reliably distinguished.
RTP data MUST be carried on an even UDP port number and the corresponding RTCP packets MUST be carried on the next higher (odd) port number, following the RTP protocol definition.
Samples for all channels belonging to a single sampling instant MUST be within the same packet. The default packetization interval should have a duration of 20 ms unless otherwise noted for the specific encoding.
The RTP clock rate used for generating RTP timestamps equals the number of sampling periods per second, independent of the number of channels and the encoding. For N-channel encodings, each sampling period generates N samples.
All current video encodings use a timestamp frequency of 90,000 Hz (same as MPEG presentation timestamp frequency). 90 kHz is the recommended rate for future video encodings under this profile.
GSM denotes the European GSM 06.10 provisional standard (prI-ETS 300 036) for full-rate speech transcoding based on RPE/LTP coding at 13 kb/s, assigned payload type 3 at 8000 Hz clock rate.
MPA (MPEG-I or MPEG-II audio) uses a clock rate of 90,000 Hz as payload type 14; sampling rate and channel count are contained in the payload itself. MPEG-I supports 32000, 44100, and 48000 Hz sampling rates.
New RTP payload format encodings may be registered with IANA by providing: encoding name and RTP timestamp clock rate, change control authority, operating parameters, reference description, contact information for proprietary encodings, and optionally a static payload type value.
Table 2 defines static RTP payload type (PT) assignments 0–33 for this profile, covering PCMU (0), GSM (3), DVI4 (5,6), PCMA (8), G722 (9), L16 (10,11), MPA (14), G728 (15), CelB (25), JPEG (26), nv (28), H261 (31), MPV (32), MP2T (33). Range 96–127 is dynamic; 72–76 reserved.
A user-provided pass phrase is hashed with MD5 to a 16-octet digest; an n-bit encryption key is extracted from the first n bits of the digest. For multi-key schemes totaling ≤128 bits (e.g., triple DES), keys are extracted in order from that digest.
The encryption algorithm is specified as a prefix to the pass phrase (characters before the first slash '/'). If no slash is present, DES-CBC is assumed as default. The algorithm specifier is case sensitive and should be drawn from RFC 1423 or IANA-registered identifiers.
L16 denotes uncompressed audio using 16-bit signed two's complement representation with 65535 equally divided steps from -32768 to 32767, transmitted in network byte order.
L8 denotes linear audio using 8-bit precision with an offset of 128 (most negative signal encoded as zero). PCMU and PCMA (G.711) encode audio as 8 bits per sample after logarithmic (mu-law or A-law) scaling.
The DVI4 header word per channel consists of: int16 'predict' (predicted value of first sample from the previous block, in L16 format), u_int8 'index' (current index into stepsize table), and u_int8 'reserved' (set to zero by sender, ignored by receiver).
VDVI is a variable-rate version of DVI4 using Huffman-like encoding of the 4-bit DVI4 codewords into variable-length bit patterns ranging from 2 bits (codeword 0 → '00') to 8 bits (codeword 15 → '11111111'), for single-channel operation only.