Struct bt_avdtp::RtpHeader

pub struct RtpHeader(/* private fields */);

RTP Packet header as described in https://tools.ietf.org/html/rfc1889 Section 5.1

RTP, the real-time transport protocol, provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.

Implementations

impl RtpHeader

pub const LENGTH: usize = 12usize

The minimum length of an RTP Header in bytes. This is the length of the header, if there are no extension fields or csrc fields.

pub fn new(buf: &[u8]) -> Result<Self, RtpError>

Parse and validate an RTP Packet from a buffer of bytes. Only packets that do not contain extension fields or csrc fields will be parsed. This is done because we do not currently use the aformentioned fields and a fixed size header is guaranteed when headers to not contain them.

pub fn sequence_number(&self) -> u16

The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does.

pub fn timestamp(&self) -> u32

The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.3.1). The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or may be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for fixed-rate audio the timestamp clock would likely increment by one for each sampling period. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent.

The initial value of the timestamp is random, as for the sequence number. Several consecutive RTP packets may have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets may contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.)