AVT D. Singer
Internet-Draft Apple Computer Inc.
Intended status: Standards Track H. Desineni
Expires: July 5, 2007 Qualcomm
January 2007
Transmission Time offsets in RTP streams
draft-ietf-avt-rtp-toffset-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Singer & Desineni Expires July 5, 2007 [Page 1]
Internet-Draft RTP Transmission Offsets January 2007
Abstract
This document describes a method to inform RTP clients when RTP
packets are transmitted at a time other than their 'nominal'
transmission time. It also provides a mechanism to provide improved
inter-arrival jitter reports from the clients, that take into account
the reported transmission times.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Transmission offset . . . . . . . . . . . . . . . . . . . . . 5
4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . 8
5. Signaling (setup) information . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Singer & Desineni Expires July 5, 2007 [Page 2]
Internet-Draft RTP Transmission Offsets January 2007
1. Introduction
In the RTP specification [RFC3550] 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:
o 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.
o 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.
o 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.
Singer & Desineni Expires July 5, 2007 [Page 3]
Internet-Draft RTP Transmission Offsets January 2007
2. Requirements notation
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 [RFC2119].
Singer & Desineni Expires July 5, 2007 [Page 4]
Internet-Draft RTP Transmission Offsets January 2007
3. Transmission offset
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):
o Take an RTP stream that has a recent RTCP sender report relating
RTP timestamp S0 to NTP timestamp N0;
o consider a packet sent after that with RTP timestamp S1.
Nominally this is sent at N1 = (N0 + RtoN(S1 - S0));
o 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 [hdrext]. 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:
Singer & Desineni Expires July 5, 2007 [Page 5]
Internet-Draft RTP Transmission Offsets January 2007
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
Singer & Desineni Expires July 5, 2007 [Page 6]
Internet-Draft RTP Transmission Offsets January 2007
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.)
Singer & Desineni Expires July 5, 2007 [Page 7]
Internet-Draft RTP Transmission Offsets January 2007
4. Extended Jitter Reports
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 Ri is the arrival time:
D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi))
= (Rj - (Sj + Oj)) - (Ri - (Si + Oi))
Singer & Desineni Expires July 5, 2007 [Page 8]
Internet-Draft RTP Transmission Offsets January 2007
5. Signaling (setup) information
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).
Singer & Desineni Expires July 5, 2007 [Page 9]
Internet-Draft RTP Transmission Offsets January 2007
6. Security Considerations
The given transmission offsets are only informative and it is hard to
see security considerations from associating them with media streams.
Singer & Desineni Expires July 5, 2007 [Page 10]
Internet-Draft RTP Transmission Offsets January 2007
7. IANA Considerations
The RTCP packet type used for the adjusted interarrival jitter needs
to be registered, in accordance with section 15 of [RFC3550]. 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.
Singer & Desineni Expires July 5, 2007 [Page 11]
Internet-Draft RTP Transmission Offsets January 2007
8. RFC Editor Considerations
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.
Singer & Desineni Expires July 5, 2007 [Page 12]
Internet-Draft RTP Transmission Offsets January 2007
9. Acknowledgments
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.
Singer & Desineni Expires July 5, 2007 [Page 13]
Internet-Draft RTP Transmission Offsets January 2007
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, STD 0064, July 2003.
[hdrext] Singer, D., "A general mechanism for RTP Header
Extensions", ID draft-ietf-avt-rtp-hdrext-08,
October 2006.
Singer & Desineni Expires July 5, 2007 [Page 14]
Internet-Draft RTP Transmission Offsets January 2007
Authors' Addresses
David Singer
Apple Computer Inc.
1 Infinite Loop
Cupertino, CA 95014
US
Phone: +1 408 996 1010
Email: singer@apple.com
Harikishan Desineni
Qualcomm
5775 Morehouse Drive
San Diego, CA 92121
US
Phone: +1 858 845 8996
Email: hd@qualcomm.com
Singer & Desineni Expires July 5, 2007 [Page 15]
Internet-Draft RTP Transmission Offsets January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Singer & Desineni Expires July 5, 2007 [Page 16]
