RTP Profile for Audio and Video Conferences with Minimal Control
obsoletes
- rfc-1890 — RTP Profile for Audio and Video Conferences with Minimal Control
updated by
- rfc-5761 — Multiplexing RTP Data and Control Packets on a Single Port
- rfc-7007 — Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)
- rfc-8860 — Sending Multiple Types of Media in a Single RTP Session
also
- std-65
Extracted elements (30)
Default RTP/RTCP port numbers 5004/5005 were chosen above 5000 to accommodate Unix operating system port allocation practice, where ports below 1024 require privilege and ports 1024-5000 are automatically assigned by the OS.
The 90 kHz video timestamp clock rate was chosen because it yields exact integer timestamp increments for all common video frame rates (24, 25, 29.97, 30 Hz) and field rates (50, 59.94, 60 Hz), and provides adequate resolution for RTCP SR/NTP synchronization and jitter estimation.
The policy of no new static payload type assignments beyond Tables 4 and 5 was established to avoid the problem of defining acceptance criteria for static assignments and to encourage deployment of dynamic payload type mechanisms (SDP, H.323/H.245).
H263-1998 (RFC 2429) is RECOMMENDED over the original H263 (RFC 2190) for new implementations. RFC 2190 continues to be used by existing implementations and may be required for backward compatibility; implementations using 1998 H.263 features MUST use RFC 2429.
Some implementations of G726 payload formats packed samples into octets starting with the most significant bit rather than the least significant bit as specified. To resolve this, AAL2-G726-16/24/32/40 payload formats with MSB packing will be specified separately; static payload type 2 (G726-32) is deprecated.
The RTP clock rate for G722 is 8,000 Hz even though G.722 audio is actually sampled at 16,000 Hz, because the value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility.
A receiver SHOULD accept packets representing between 0 and 200 ms of audio data. The default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer.
Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4) to allow interoperability without format negotiation.
CNAME information MUST be sent every RTCP reporting interval; other SDES items SHOULD only be sent every third reporting interval, with NAME sent seven out of eight times within that slot and remaining SDES items cyclically taking the eighth slot.
G723 receivers MUST accept both 5.3 and 6.3 kb/s data rates and MUST accept SID frames unless restriction has been signaled. G729 receivers MUST accept comfort noise frames unless their use has been restricted by signaling.
No additional static payload types will be assigned beyond those defined in Tables 4 and 5 of this document. This policy avoids the problem of creating criteria for static assignments and encourages deployment of dynamic payload type mechanisms.
Payload types of different media types (audio, video, audio/video) SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel. An RTP source MAY change payload types within the same media type.
PCMA and PCMU MUST always be transmitted as 8-bit samples; the 56 kb/s and 48 kb/s modes of G.711 are not applicable to RTP. Each G.711 octet SHALL be octet-aligned in an RTP packet with the sign bit in the most significant bit position.
RTP data SHOULD be carried on an even UDP port number, and the corresponding RTCP packets SHOULD be carried on the next higher (odd) port number. Port numbers 5004 and 5005 are registered as the default pair for this profile.
RTP packets SHALL contain a whole number of audio frames, with frames inserted in age order so the oldest frame (played first) appears immediately after the RTP header. The RTP timestamp reflects the first sample of the first frame.
RTP receivers SHOULD monitor packet loss to ensure congestion is within acceptable parameters. Packet loss is acceptable only if a TCP flow across the same path would achieve average throughput not less than the RTP flow, requiring TCP-friendly congestion control or leaving the session if loss is unacceptably high.
Samples for all channels belonging to a single sampling instant MUST be within the same RTP packet. For sample-based encodings, samples from different channels at the same instant SHOULD be packed in consecutive octets (interleaved).
The first packet of a talkspurt (first packet after a silence period) SHOULD be distinguished by setting the RTP marker bit to one. Applications without silence suppression MUST set the marker bit to zero.
When RTP is carried over TCP or similar byte-stream protocols, the application MUST define its own method of delineating RTP and RTCP packets.
All video encodings under this profile use an RTP timestamp frequency of 90,000 Hz, chosen to yield exact integer increments for 24, 25, 29.97, and 30 Hz frame rates. The timestamp resolution MUST also be sufficient for the jitter estimate in RTCP receiver reports.
For video, the RTP marker bit SHOULD be set to one in the last packet of a video frame and zero otherwise, allowing receivers to detect frame boundaries without waiting for a timestamp change. If a video image spans multiple packets, all share the same timestamp.
The RTP/AVP profile reserves payload type numbers 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types; those needing more than 32 dynamic types MAY use codes below 96, preferring unassigned numbers.
The RTP clock rate used for generating timestamps is independent of the number of channels and equals the number of sampling periods per second. For multi-channel audio, information from lower-numbered channels precedes higher-numbered channels within RTP packets, following AIFF-C ordering conventions.
Table 4 defines static payload type (PT) assignments for audio encodings 0-23 (e.g., PT 0=PCMU, PT 3=GSM, PT 8=PCMA, PT 9=G722, PT 18=G729) plus dynamic-only entries. Table 5 assigns video and combined PTs 25-34 (e.g., PT 26=JPEG, PT 31=H261, PT 32=MPV, PT 33=MP2T). PT range 96-127 is reserved for dynamic use.
The RTP default security services defined in RFC 3550 are also the defaults under this profile. No additional security mechanisms or string-to-key mappings are specified by the RTP/AVP profile.
DVI4 packet header word per channel: int16 predict (predicted value of first sample in L16 format), uint8 index (stepsize table index), uint8 reserved (set to zero). Each subsequent octet contains two 4-bit samples, first sample in the four most significant bits.
G723 frame type is indicated by the two least significant bits of the first octet: 00=6.3 kb/s (24 octets), 01=5.3 kb/s (20 octets), 10=SID frame (4 octets), 11=reserved. Frames of different sizes may be freely intermixed.
G726 codewords are packed into octets with the first codeword's least significant bit aligned to the octet's least significant bit ('little-endian'); successive codewords pack from LSB upward, spanning octet boundaries. Packing MUST end with a completely filled final octet.
G728 four-vector frame (40 bits) is packed into 5 octets B1-B5 with the MSB of the frame in the MSB of B1 and the LSB in the LSB of B5 ('maintenance of bit significance'); B1 SHALL be placed first in the RTP packet.
GSM 06.10 RTP payload: every 160-sample frame is coded into a 33-octet buffer beginning with a 4-bit signature 0xD, followed by MSB-first encoding of the 76 frame fields listed in Table 2 (LARc coefficients, Nc, bc, Mc, xmaxc, xmc parameters for four sub-frames).