Table 2 defines this profile's static payload type values for the PT field of the RTP data header. A new RTP payload format specification may be registered with the IANA by name, and may also be assigned a static payload type value from the range marked in Section 3.
In addition, payload type values in the range 96-127 may be defined dynamically through a conference control protocol, which is beyond the scope of this document. For example, a session directory could specify that for a given session, payload type 96 indicates PCMU encoding, 8,000 Hz sampling rate, 2 channels. The payload type range marked 'reserved' has been set aside so that RTCP and RTP packets can be reliably distinguished (see Section "Summary of Protocol Constants" of the RTP protocol specification).
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, but multiple RTP sessions may be used in parallel to send multiple media. The payload types currently defined in this profile carry either audio or video, but not both. However, it is allowed to define payload types that combine several media, e.g., audio and video, with appropriate separation in the payload format. Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session. This set may, for example, be defined by the capabilities of the applications used, negotiated by a conference control protocol or established by agreement between the human participants.
Audio applications operating under this profile should, at minimum, be able to send and receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and successful negotation with a conference control protocol.
All current video encodings use a timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended rate for future video encodings used within this profile, other rates are possible. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet [15]. The timestamp resolution must also be sufficient for the jitter estimate contained in the receiver reports.
The standard video encodings and their payload types are listed in Table 2.
PT encoding audio/video clock rate channels
name (A/V) (Hz) (audio)
_______________________________________________________________
0 PCMU A 8000 1
1 1016 A 8000 1
2 G721 A 8000 1
3 GSM A 8000 1
4 unassigned A 8000 1
5 DVI4 A 8000 1
6 DVI4 A 16000 1
7 LPC A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
10 L16 A 44100 2
11 L16 A 44100 1
12 unassigned A
13 unassigned A
14 MPA A 90000 (see text)
15 G728 A 8000 1
16--23 unassigned A
24 unassigned V
25 CelB V 90000
26 JPEG V 90000
27 unassigned V
28 nv V 90000
29 unassigned V
30 unassigned V
31 H261 V 90000
32 MPV V 90000
33 MP2T AV 90000
34--71 unassigned ?
72--76 reserved N/A N/A N/A
77--95 unassigned ?
96--127 dynamic ?
Table 2: Payload types (PT) for standard audio and video encodings