One document matched: draft-lennox-avt-rtp-layered-encoding-timestamps-00.txt
AVT J. Lennox
Internet-Draft Vidyo
Updates: 3550 (if approved) T. Schierl
Intended status: Standards Track Fraunhofer HHI
Expires: December 4, 2008 S. Ganesan
Motorola
June 2, 2008
Real-Time Transport Protocol (RTP) Timestamps for Layered Encodings
draft-lennox-avt-rtp-layered-encoding-timestamps-00
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 December 4, 2008.
Abstract
The Real-Time Transport Protocol (RTP) specification defines how
layered encodings can be sent over a layered transmission system. A
source can stripe the progressive layers of a hierarchically
represented signal across multiple RTP sessions, each carried on, for
example, its own multicast group. These layered encodings are given
special treatment in RTP, notably in that the same synchronization
source (SSRC) identifier space is used across the sessions of all
layers.
Lennox, et al. Expires December 4, 2008 [Page 1]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
The RTP protocol specification does not, however, explicitly state
how RTP timestamps are to be used with layered encodings. This
document updates the RTP specification to require that RTP timestamps
for layered encodings be synchronized, i.e. that every layer chooses
the same random initial value for the timestamp.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Normative Requirements . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Architectural Implications . . . . . . . . . . . . . . . . . . 4
6. Payload Design Considerations . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Lennox, et al. Expires December 4, 2008 [Page 2]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
1. Introduction
The Real-Time Transport Protocol (RTP) [RFC3550] specification
defines how layered encodings can be sent over a layered transmission
system. A source can stripe the progressive layers of a
hierarchically represented signal across multiple RTP sessions, each
carried on, for example, its own multicast group. These layered
encodings are given special treatment in RTP, notably in that the
same synchronization source (SSRC) identifier space is used across
the sessions of all layers.
The RTP protocol specification does not, however, explicitly state
how RTP timestamps are to be used with layered encodings. This
document updates the RTP specification to require that RTP timestamps
for layered encodings be synchronized, i.e. that every layer chooses
the same random initial value for the timestamp.
2. Terminology
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 RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
3. Normative Requirements
When a source is sent as a layered encoding transmitted on separate
RTP sessions (as defined in Section 2.4 of [RFC3550]), such that the
same synchronization source (SSRC) identifier is used on each
session, the same initial (random) RTP timestamp value MUST be used
for every layer.
(Since each layer's RTP timestamps are derived from the same media
clock, and so will advance at the same rate, this implies that RTP
packets will have equal timestamps if they are (logically) generated
at once, e.g., belong to the same video frame, as with packets on a
single session.)
4. Discussion
Speer and McCanne [I-D.speer-avt-layered-video] defined how layered
encoding support would be added to the original RTP specification
[RFC1889]. This work was adapted into the current RTP specification
when it was revised [RFC3550].
Lennox, et al. Expires December 4, 2008 [Page 3]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
This specification modified RTP so that the same synchronization
source (SSRC) identifier would be used on each session for a layered
encoding transmitted on multiple streams. As discussed in that
draft, the alternative would be to allocate each layer's SSRC
independently, and associate the streams using the canonical name
(CNAME) information sent periodically in RTCP source description
(SDES) packets, as RTP does to associate separate audio and video
streams from a single user. However, this alternative introduces
additional complexity, in that it forces each receiver to manage all
the CNAME/SSRC bindings; requires newly-arrived receivers to wait for
the source description packets before they can start decoding a
stream; and creates new error recovery conditions for dealing with
conflicting information that arrives on the different sessions.
Speer and McCanne specification's did not say anything about RTP
timestamps. However, as documented in McCanne's Ph.D. Thesis
[McCa96], vic [VIC], the primary implementation of layered encoding
of RTP, sent base and enhancement layers of a video stream with
synchronized RTP timestamps, and relied on this fact to associate the
frames when decoding them.
Absent payload-specific synchronization information, as with source
identifiers, the alternative for stream alignment would be to rely on
RTCP reports, in this case on the NTP timestamps carried in carried
in RTCP sender report (SR) packets. However, this would introduce
much the same problems as relying on CNAME-based synchronization for
the sources. It introduces significant additional complexity;
receivers must wait for the receipt of SR packets before they can
start decoding a stream; and conflicting information can arise from
the different sessions, particularly for sessions with long RTCP
reporting intervals if there is clock skew between a source's NTP and
media timestamps. This largely removes any advantage of SSRC
synchronization across the layers.
5. Architectural Implications
RTP timestamp randomization has two primary motivations: it improves
the probability of detection of SSRC collisions, and it provides
additional randomness for [RFC3550]-style packet encryption (a "weak
initialization vector", in the words of that RFC).
Synchronizing RTP timestamps across sessions does not harm SSRC
collision detection. As specified by [RFC3550], for layered sessions
the base layer's session is used for SSRC identifier allocation and
collision resolution. When two sources collide, they will collide on
every session layer on which they are being sent; and when a source
changes its SSRC following a collision, it will change it on every
Lennox, et al. Expires December 4, 2008 [Page 4]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
session.
The security implications of timestamp synchronization are discussed
in Section 7.
6. Payload Design Considerations
Depending on the payload, RTP timestamp synchronization may not be
sufficient to completely reconstruct the order in which packets sent
over several RTP sessions need to be decoded. In such cases, the
payload definition needs to specify how the decoding order of packets
is reconstructed.
Difficulties particularly arise if if a payload allows packets with a
given timestamp to be omitted on some sessions; if a payload has non-
trivial decoding order constraints for media with the same timestamp;
or if a payload supports a transmission order different from its
timestamp order, as is common with video formats.
7. Security Considerations
For [RFC3550]-style packet encryption, RTP timestamp randomization
contributes to a "weak initialization vector" for encrypted packets.
In particular, the timestamp, sequence number, and SSRC together
provide randomness to a session.
However, when timestamps and sequence numbers are aligned across
multiple sessions, for many payloads sequence numbers will also align
periodically (if packets are sent at different rates on each
session.) This introduces a weakness which can allow an attacker to
launch "two-time-pad" attacks against the bitstream. Thus, if
[RFC3550]-style RTP packet encryption is used to protect a layered
encoding, different encryption keys MUST be used on each RTP session
of the layered encoding.
For Secure RTP (SRTP) [RFC3711], similarly, a different SRTP master
key MUST be used for each RTP session. The key management mechanisms
Secure Descriptions for SDP [RFC4568], Key Management Extensions for
SDP and RTSP [RFC4567] combined with MIKEY [RFC3830], DTLS-SRTP
[I-D.ietf-sip-dtls-srtp-framework], and ZRTP
[I-D.zimmermann-avt-zrtp] all satisfy this requirement.
8. IANA Considerations
No action by IANA is required.
Lennox, et al. Expires December 4, 2008 [Page 5]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
9. References
9.1. 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", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
9.2. Informative References
[I-D.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-01 (work in progress),
February 2008.
[I-D.speer-avt-layered-video]
Speer, M. and S. McCanne, "RTP usage with Layered
Multimedia Streams", draft-speer-avt-layered-video-05
(work in progress), June 1997.
Expired draft.
[I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-06 (work in progress),
March 2008.
[McCa96] McCanne, S., "Scalable Compression and Transmission of
Internet Multicast Video", Report No. UCB/CSD-96-928,
December 1996.
Ph.D. Dissertation, University of California Berkeley.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
Lennox, et al. Expires December 4, 2008 [Page 6]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
August 2004.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[VIC] McCanne, S. and V. Jacobson, "vic: A Flexible Framework
for Packet Video", 1995.
ACM Multimedia, pp. 511-522
Authors' Addresses
Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Sixth Floor
Hackensack, NJ 07601
US
Email: jonathan@vidyo.com
Thomas Schierl
Fraunhofer HHI
Einsteinufer 37
D-10587 Berlin
Germany
Phone: +49-30-31002-227
Email: schierl@hhi.fhg.de
Sam Ganesan
Motorola
80 Central Street
Boxborough, MA 01719
US
Email: sam.ganesan@motorola.com
Lennox, et al. Expires December 4, 2008 [Page 7]
Internet-Draft RTP Timestamps for Layered Encodings June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Lennox, et al. Expires December 4, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 04:26:35 |