0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... |If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself.
This is a baseclass, suitable for use by extending it with the appropriate extension based on the profile definition. The class defines methods for reading the static fields that are present in every extension, especially the {@link #length} field. No sub-header ID needs to be manually assignedsince Rtp specification only allows a single extension to exist within a header. Note that the profile specific 16-bit field has a getter method provided but is not marked with Field annotation. This provides a method for reading the raw 16-bit field value and allows the subclass to provide its own method that is profile specific and which possibly further breaks down the structure of this raw field into a sub-structure.
| |