Next: , Previous: RTP Sessions, Up: Using ccRTP

4.2 Payload Types and Formats

In the context of RTP, an RTP payload type is a 7-bit numeric identifier that identifies a payload format. For payload types, GNU ccRTP defines the integer type PayloadType. ccRTP also defines The enumerated type StaticPayloadType, as the enumeration of the RTP Payload Types statically assigned for standard audio and video formats.

These codes were initially specified in RFC 1890, “RTP Profile for Audio and Video Conferences with Minimal Control” (AVP profile), superseded by RFC 3550, and are registered as MIME types in RFC 3555. Codes below 96 may be assigned statically, although the default bindings for many of them are already reserverd. Codes in the range 96-127 are assigned dinamically by means outside of the RTP profile or protocol specification.

See the “RTP Parameters” list at IANA Note however that registering static payload types is now considered a deprecated practice in favor of dynamic payload type negotiation.

The properties of a payload format that, as an RTP stack, ccRTP takes into account are the payload type (numeric identifier) and the RTP clock rate. Other properties, such as MIME type, number of audio channels, “ptime” and “maxptime” are not considered. These are only of interest for higher level protocols, such as SDP and H.245.

GNU ccRTP defines a hierarchy of payload format classes. Its root is PayloadFormat, which is a base class for StaticPayloadFormat and DynamicPayloadFormat.

Static payload format objects are built from a static payload code. These are defined in the enumerated type StaticPayloadType. The following example constructs a StaticPayloadFormat object corresponding to the payload type 0 (statically bounded to PCMA in RFC 3551):

     StaticPayloadType pt = sptPCMU;
     StaticPayloadFormat* spf = new StaticPayloadFormat(pt);

Of course, we could have said:

     StaticPayloadFormat* spf = new StaticPayloadFormat(sptPCMA);

StaticPayloadFormat objects build like the ones above hold the necessary parameters so that the RTP stack can handle incoming and outgoing packets.

Regarding dynamic payload formats, a call to DynamicPayloadFormat::DynamicPayloadFormat(100,90000) like the following:

     DynamicPayloadFormat* dpf = new DynamicPayloadFormat(100,90000);

Will construct a dynamic payload format object that ties together the '100' payload type numeric identifier and an RTP clock rate of 90 Khz. Note that the numeric identifier does not have to be in the dynamic range. The static payload types are default bindings and MAY be overriden, thus, DynamicPayloadFormat(0,90000) is a valid construct provided 0 has been established as the payload type through a previous negotiation process1.

Whether and how the payload has been negotiated is outside of the scope of RTP and ccRTP, so applications must choose between StaticPayloadFormat and DynamicPayloadFormat accordingly to their multimedia session control mechanisms.


[1] Despite the fact that RFC 3551 defines a static binding of the 0 code to mu-law PCM at 8Khz.