AVT D. Singer
Internet-Draft Apple Computer Inc.
Expires: February 16, 2007 August 15, 2006
Transmission Time offsets in RTP streams
draft-ietf-avt-rtp-toffset-00.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 February 16, 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.
Singer Expires February 16, 2007 [Page 1]
Internet-Draft RTP Transmission Offsets August 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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Singer Expires February 16, 2007 [Page 2]
Internet-Draft RTP Transmission Offsets August 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 transmission time from the original.
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.
Singer Expires February 16, 2007 [Page 3]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 4]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 5]
Internet-Draft RTP Transmission Offsets August 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.
There is an outstanding question: this extension permits recording in
a packet when its timing has been deliberately adjusted. It is
structurally possible to have more than one extension of the same
type in a packet, and therefore we could permit network elements also
to edit this into the packet (e.g. a traffic smoothing proxy). It
seems unlikely any such network element would, in fact, edit packets
like this (as byte-shuffling would be involved), but, should it be
permitted?
Singer Expires February 16, 2007 [Page 6]
Internet-Draft RTP Transmission Offsets August 2006
4. Extended Jitter Reports
If it is desired to send back jitter reports which do, in fact, take
into account the reported source jitter, and thus report the
perceived network jitter, an RTCP packet may be sent after the
reception report.
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 follow a receiver report, 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 Expires February 16, 2007 [Page 7]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 8]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 9]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 10]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 11]
Internet-Draft RTP Transmission Offsets August 2006
Appendix A. Acknowledgments
Ron Frederick, Colin Perkins, and Steve Casner all contributed
substantially to this document.
Singer Expires February 16, 2007 [Page 12]
Internet-Draft RTP Transmission Offsets August 2006
Appendix B. Change History
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.
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, August 2006.
Singer Expires February 16, 2007 [Page 13]
Internet-Draft RTP Transmission Offsets August 2006
Author's Address
David Singer
Apple Computer Inc.
1 Infinite Loop
Cupertino, CA 95014
US
Phone: +1 408 996 1010
Email: singer@apple.com
Singer Expires February 16, 2007 [Page 14]
Internet-Draft RTP Transmission Offsets August 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 Expires February 16, 2007 [Page 15]
