Transmission Time offsets in RTP streams

In the RTP specification network jitter calculations are based on the presumption that packets are transmitted essentially in accordance with their RTP timestamps. This must be true, of course, on average over longer time intervals, as the client is playing the packets out according to those timestamps. However, for individual packets, this may under some circumstances not be true: When the data rate of the stream is bursty, such as with video where I-frames may be significantly larger than P or B frames, traffic smoothing may need to be applied to maintain an appropriate data rate. In video which has forward decode dependencies, frames may need to be transmitted in decoding order (the sequence number order) but with, of course, presentation timestamps. Under these circumstances the transmission time of a frame sent early in sequence does not correspond to its RTP timestamp. When re-transmissions are sent, the re-transmitted packet clearly has a different actual transmission time from the original, even though they share the same timestamp. Under some circumstances it can help the receiver, or intermediate network elements, to know the actual transmission time of the packet. This RTP header extension element allows the communication of this information. The RTP specification does not define a transmission timestamp, and nor does this specification. This specification merely provides information on the relationship between the relative transmission times and relative RTP timestamps. This specification allows the transmitter to indicate to the receiver any known variation between the spacing of transmission times and the spacing of RTP timestamps; any unreported variation introduced at or after the point of measurement of the transmission time will be treated as network jitter by the receiver. The definition of the point where the transmission time is measured or defined is left to the transmitter, though it should, of course, be consistent from packet to packet. This information can also be of use to report the inter-arrival jitter caused by the network, excluding that introduced by the source. A new RTCP packet is defined to enable this reporting.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Classically a pair of RTP packets with timestamps S2 and S1 are transmitted with a time interval between them of (S2 - S1). This specification permits sending an offset value O in each packet, O1 and O2. One characteristic of these offsets is that the original transmission interval can be deduced to be (S2 + O2) - (S1 + O1). More precisely, the offset is defined as follows (with the function RtoN converting from RTP to NTP times, and NtoR doing the reverse): Take an RTP stream that has a recent RTCP sender report relating RTP timestamp S0 to NTP timestamp N0; consider a packet sent after that with RTP timestamp S1. Nominally this is sent at N1 = (N0 + RtoN(S1 - S0)); If it was actually sent at a different time, Na, then the offset value O1 is O1 = NtoR(Na - N1). The transmission time is signalled to the receiver in-band using The IETF Generic RTP header extension . The payload of this extension (the transmitted value) is a 24-bit signed integer. When added to the RTP timestamp of the packet, it represents the “effective” RTP transmission time of the packet, on the RTP timescale. The reported transmission time T1 of a packet with timestamp S1 and an offset of O1, from the above equations, is T1 = S1+O1 (though of course the transmission time values only have meaning when two or more are compared).

The form of the transmission offset extension block is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 | transmission offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field takes the value 2 to indicate that 3 bytes follow. The sign of the offset value depends greatly on the choice of the initial mapping of RTP to NTP times. In general, without scanning a stream entirely it is not possible to ensure that this mapping would keep all the offsets positive; therefore this specification allows negative values. Imagine a stream with the following timestamps and sizes in bytes:

200 2kb 300 4kb 400 2kb 500 12kb 600 ...effective end of stream This has 20KB spread over 400 time units, i.e. on average 1 kb per 20 time-units. We traffic-smooth this, and establish that given a transmission time of x for the first packet, we would transmit the following packets at the given intervals later:

x + 000 2kb x + 040 4kb x + 120 2kb x + 160 12kb x + 400 ...effective end of stream The choice of x is esssentially arbitrary: only relative values of timestamps matter. Now, let's say I claim on the first packet that it went out *at* its RTP timestamp, i.e. with an offset of 0, i.e. x is 200. Then the offset values are

0 -60 -80 -140 This is because in this case, I traffic-smooth this because conceptually I think of sending the small packets 'early'. But since only the relative values are significant, it is just as valid to say x is 400, whereupon the offset values are

200 140 120 60 In a stream where this extension is not in effect (i.e. not declared or negotiated), the actual transmission offset is therefore unknown. However, when the extension is in effect for the stream, it MAY be omitted in those packets for which the offset is 0 (zero); that is, packets sent at their nominal time do not need this extension tagging. Therefore the implied transmission time of an un-tagged RTP packet depends on whether the extension is in effect for the stream (and therefore the transmission offset is 0) or not (whereupon the transmission offset is unknown). The jitter calculations performed by an RTP client MUST NOT use these transmission offsets. In general, the sender (or intermediate network elements doing RTP analysis) cannot always know whether the offsets have been taken into account or not, and for consistency therefore, the jitter calculation should continue to operate on the 'raw' reception times. However, see the section on extended jitter reports, below. There are no extension attributes defined for this extension. It is structurally possible to have more than one extension of the same type in a packet. However, this extension is only defined for the source to report, and intermediate network nodes that are not the source of the RTP session MUST NOT add this extension (whether or not it was previously present) and MUST NOT alter the existing transmission offset value in a packet, if the extension is already present. (Of course, it is clear that network elements that terminate an RTP flow, and are the source for a new RTP flow, can add a transmission offset extension header to the RTP packets of the new flow, if desired.)

The inter arrival jitter computed as defined in Sec 6.4.1 of RFC3550 provides inter-arrival jitter reports which include any source-introduced jitter (transmission time offsets). If it is desired to indicate the actual network jitter, excluding the source-introduced jitter, the new RTCP packet type defined here may be used.

It has the following form: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ hdr |V=2|P| RC | PT=IJ=195 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If present, this RTCP packet must be placed after a receiver report (inside a compound RTCP packet), and MUST have the same value for RC as the receiver report. The content is exactly that number of interarrival jitter calculations, calculated using the same formula as for sender and receiver reports, but taking into account the transmission offsets for the streams (if any); that is, using the values T1=S1+O1, T2 etc. as defined above, instead of S1, S2 etc.. (If no transmission offset information is given for a stream, then the value of interarrival jitter in this packet and in the receiver report will be identical). Precisely, the replacement equation for the equation in the RTP specification is, where Rj is the most recent arrival time:

D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi)) = (Rj - (Sj + Oj)) - (Ri - (Si + Oi))

The URI for declaring this header extension in an extmap attribute is “urn:ietf:params:rtp-hdrext:toffset”. There is no additional setup information needed for this extension (no extensionattributes).

The given transmission offsets are only informative and it is hard to see security considerations from associating them with media streams.

The RTCP packet type used for the adjusted interarrival jitter needs to be registered, in accordance with section 15 of . The abbreviation is "IJ", the full name is "Extended inter-arrival jitter report", the suggested value is 195, and the specification is this document. The name toffset needs to be registered into the rtp-hdrext section of the urn:ietf: namespace, referring to RFCxxxx.

The reference to an Internet Draft needs to be updated to the RFC when it is published (which should be before this draft). RFCxxxx in the IANA considerations needs to be updated with the number of this RFC.

Ron Frederick, Colin Perkins, and Steve Casner all contributed substantially to this document, and their help and contributions helped turn an idea into a specification.