RTP Header 12 Fixed byte mechanism diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v=2| p| X| CC | m| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Contributing Source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- V–version. Identifies the RTP version.
- RTP Version number
- P–padding. When set, the packet contains one or more additional padding octets at the end which is not part of the payload.
- is populated, and if set to allow padding, one or more bytes are populated at the end of the package, and those populated bytes are not part of the payload.
- X–extension bit. When set, the fixed header was followed by exactly one header extension, with a defined format.
- Expansion bit, if set to allow, after the fixed head structure (that is, after the 12 bytes of the package, before the payload) followed by an extension header structure, which is a defined format
- CSRC count (CC)-contains the number of CSRC identifiers that follow the fixed header.
- The number of data sources (that is, the number of sources), if there is only one source then the value at this time is 0.
- M–marker. The interpretation of the marker is defined to a profile. It is intended to allow significant events such as frame boundaries to being marked in the packet stream.
- identification, as defined in the document, that intentionally identifies important things such as the boundary (end or start) of a frame of data that is identified in the streaming media.
- Payload type–identifies The format of the RTP Payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through NON-RTP means.
- Payload, the payload of the RTP data (excluding the first 12 bytes), is determined by the specific application to determine the format and meaning of the payload. There is a table in the official documentation that shows the correspondence between the format code and the specific format, and the additional format code may not be defined in the RTP protocol.
- Sequence number–increments by one for each RTP data packet sent, and May is used by the receiver to detect packet loss a nd to restore packet sequence.
- The packet sequence number, which is sent by the RTP packet ordinal, is used by the receiving side to check for lost packets and to determine the order in which the packets are saved.
- Timestamp–reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must is derived from a clock, increments monotonically and linearly in time to allow Synchronizat Ion and jitter calculations.
- Timestamp, which records the sampling time of the first byte in the RTP packet, which must originate from a time increment and allow synchronization and computation.
- Ssrc–synchronization source. This identifier was chosen randomly, with the intent, no, and synchronization sources within the same RTP session would h Ave the same SSRC identifier.
- The synchronous identity, which is a random number, has only one synchronous identity in the same RTP session.
- Csrc–contributing Source Identifiers list. Identifies the contributing sources for the payload contained in this packet.
RTP Header Structure Analysis
