Transmission Time Offsets in RTP Streams
Extracted elements (16)
Negative offset values are permitted because the sign depends on the choice of initial RTP-to-NTP mapping. Without scanning an entire stream, it is not possible to guarantee a mapping that keeps all offsets positive, so the specification allows both positive and negative values.
Source jitter and network jitter are separated by defining the IJ RTCP packet: the standard RFC 3550 receiver report jitter includes source-introduced jitter (from traffic smoothing or reordering), while the IJ packet allows reporting only the network-induced component.
The specification only communicates the relationship between relative transmission times and relative RTP timestamps; it does not define an absolute transmission timestamp. This avoids requiring synchronization to absolute wall-clock time at the sender.
When the toffset extension is in effect for a stream, the offset MAY be omitted for packets sent at their nominal time (offset = 0). The implied transmission offset of an untagged packet is 0 if the extension is in effect, or unknown if the extension is not declared/negotiated.
If present, the IJ RTCP packet MUST be placed after a receiver report inside a compound RTCP packet, and MUST have the same RC (reception report count) value as the accompanying receiver report.
Intermediate network nodes that are not the source of the RTP session MUST NOT add the transmission offset extension and MUST NOT alter an existing transmission offset value already present in a packet.
Jitter calculations performed by an RTP client MUST NOT use transmission offsets. The standard jitter formula must continue to operate on raw reception times to maintain consistency, since the sender cannot always know whether offsets have been taken into account by the receiver.
A 24-bit signed integer RTP header extension (toffset) carries the transmission offset O for each packet. When added to the RTP timestamp S1, it yields the effective transmission time T1 = S1 + O1. The offset is defined as the NTP-to-RTP-scale difference between the actual send time and the nominal send time derived from the most recent RTCP sender report.
A new RTCP packet type 'IJ' (PT=195) is defined to report inter-arrival jitter excluding source-introduced jitter. It contains one 32-bit inter-arrival jitter value per reception report entry, calculated using effective transmission times T=S+O rather than raw RTP timestamps.
The URI for declaring the toffset header extension in an SDP extmap attribute is 'urn:ietf:params:rtp-hdrext:toffset'. No additional setup attributes are required.
IANA registered a new RTCP Control Packet type: abbreviation 'IJ', name 'Extended inter-arrival jitter report', value 195, reference RFC 5450. Added to the RTCP Control Packet types subregistry of the RTP Parameters registry.
IANA registered a new RTP Compact Header Extension URI: 'urn:ietf:params:rtp-hdrext:toffset' with description 'Transmission Time offsets'. Added to the RTP Compact Header Extensions subregistry of the RTP Parameters registry.
Malicious senders or in-transit packet tamperers could inject implausible offset values that confuse receivers or produce misleading jitter reports that in turn mislead the sender. Both sender and receiver should guard against denial-of-service or other problems arising from such manipulation.
The transmission offsets are informative only. The underlying security considerations of RFC 3550 apply, and since offsets do not control media playout directly, the direct security risk from the extension itself is limited.
The IJ RTCP packet has a standard RTCP header (V=2, P, RC, PT=195, length) followed by RC repetitions of a 32-bit inter-arrival jitter field. The jitter formula is D(i,j) = (Rj - (Sj+Oj)) - (Ri - (Si+Oi)), replacing the RFC 3550 formula.
The transmission offset extension block is a 32-bit field: a 4-bit ID, a 3-bit length field with value 2 (indicating 3 bytes follow), and a 24-bit signed integer transmission offset. Carried using the general RTP header extension mechanism of RFC 5285.