AVT D. Singer Internet-Draft Apple Computer Inc. Expires: June 4, 2007 H. Desineni Qualcomm December 1, 2006 Transmission Time offsets in RTP streams draft-ietf-avt-rtp-toffset-03.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 June 4, 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 June 4, 2007 [Page 1] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 2] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 3] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 4] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 5] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 6] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 7] Internet-Draft RTP Transmission Offsets December 2006 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 June 4, 2007 [Page 8] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 9] Internet-Draft RTP Transmission Offsets December 2006 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 this specification. Singer & Desineni Expires June 4, 2007 [Page 10] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 11] Internet-Draft RTP Transmission Offsets December 2006 Appendix A. 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 June 4, 2007 [Page 12] Internet-Draft RTP Transmission Offsets December 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. o Sept 2006: 01 Improved wording of some sections, co-author added. o Oct 2006: 02 Changed to URI signalling. o Dec 2006: 03 Changed to URN signalling. 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-06, October 2006. Singer & Desineni Expires June 4, 2007 [Page 13] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 14] Internet-Draft RTP Transmission Offsets December 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 June 4, 2007 [Page 15]