AVT D. Singer
Internet-Draft Apple Computer Inc.
Expires: March 14, 2007 H. Desineni
Qualcomm
September 10, 2006
Transmission Time offsets in RTP streams
draft-ietf-avt-rtp-toffset-01.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 March 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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.
Singer & Desineni Expires March 14, 2007 [Page 1]
Internet-Draft RTP Transmission Offsets September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Transmission offset . . . . . . . . . . . . . . . . . . . . . 5
4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . 7
5. Signaling (setup) information . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Singer & Desineni Expires March 14, 2007 [Page 2]
Internet-Draft RTP Transmission Offsets September 2006
1. Introduction
In the RTP specification [RFC3550] it is implied 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.
It 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 March 14, 2007 [Page 3]
Internet-Draft RTP Transmission Offsets September 2006
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 March 14, 2007 [Page 4]
Internet-Draft RTP Transmission Offsets September 2006
3. Transmission offset
Classically a pair of RTP packets with timestamps R2 and R1 are
transmitted with a time interval between them of (R2 - R1). 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 (R2 + O2) - (R1 + 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 R0 to NTP timestamp N0;
o consider a packet sent after that with RTP timestamp R1.
Nominally this is sent at N1 = (N0 + RtoN(R1 - R0));
o If it was actually sent at a different time, Na, then the offset
value is 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 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.
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,
Singer & Desineni Expires March 14, 2007 [Page 5]
Internet-Draft RTP Transmission Offsets September 2006
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.)
Singer & Desineni Expires March 14, 2007 [Page 6]
Internet-Draft RTP Transmission Offsets September 2006
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. This new
RTCP packet may be placed after the reception report inside a
compound RTCP packet.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This RTCP packet must be placed after a receiver report (inside a
compound RTCP packet), and MUST have the same value as the receiver
report for RC. 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). (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).
Singer & Desineni Expires March 14, 2007 [Page 7]
Internet-Draft RTP Transmission Offsets September 2006
5. Signaling (setup) information
The name is "org.ietf.avt.rtp.toffset/082006". There is no
additional setup information needed for this extension (no
extensionattributes).
Singer & Desineni Expires March 14, 2007 [Page 8]
Internet-Draft RTP Transmission Offsets September 2006
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 March 14, 2007 [Page 9]
Internet-Draft RTP Transmission Offsets September 2006
7. IANA Considerations
The registration of this extenstion within the IETF/IANA space is as
documented above. The registered name is "org.ietf.avt.rtp.toffset/
082006", associated with this specification.
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.
Singer & Desineni Expires March 14, 2007 [Page 10]
Internet-Draft RTP Transmission Offsets September 2006
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).
Singer & Desineni Expires March 14, 2007 [Page 11]
Internet-Draft RTP Transmission Offsets September 2006
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 March 14, 2007 [Page 12]
Internet-Draft RTP Transmission Offsets September 2006
o August 2006: 00 Initial version, split from the document
draft-ietf-avt-rtp-hdrext-03, where it had lived unil then.
Substantial improvements in the documentation and explanation.
o Sept 2006: 01 Improved wording of some sections, co-author added.
9. 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-04,
September 2006.
Singer & Desineni Expires March 14, 2007 [Page 13]
Internet-Draft RTP Transmission Offsets September 2006
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 March 14, 2007 [Page 14]
Internet-Draft RTP Transmission Offsets September 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Singer & Desineni Expires March 14, 2007 [Page 15]
