AVT O. Levin
Internet-Draft Z. Vax
Expires: April 30, 2009 Microsoft Corporation
October 27, 2008
Extensions to RTCP Feedback Mechanism for Burst Streaming
draft-levin-avt-rtcp-burst-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 April 30, 2009.
Abstract
This document defines extensions to the "RTCP-Based Feedback"
[RFC4585] to reduce synchronization time when an RTP receiver joins a
multicast stream at a random point in time.
Levin & Vax Expires April 30, 2009 [Page 1]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 4
5. Burst Mechanism Description . . . . . . . . . . . . . . . . . 6
6. Burst Mechanism Example Flow . . . . . . . . . . . . . . . . . 7
7. The RTCP Extensions: New Transport Layer Feedback Messages . . 9
7.1. Lack of Synch Indication (LSI) . . . . . . . . . . . . . . 9
7.1.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 9
7.1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Burst Bandwidth Indication (BBI) . . . . . . . . . . . . . 10
7.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 10
7.2.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. Synch Completed Indication (SCI) . . . . . . . . . . . . . 11
7.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 11
7.3.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Establishing the Retransmission RTP Session with Burst
using SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. New Transport Layer Feedback Messages . . . . . . . . . . 12
9.2. New SDP attributes . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informational References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Levin & Vax Expires April 30, 2009 [Page 2]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
1. 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 "Key words for use in
RFCs to Indicate Requirement Levels " [RFC2119].
2. Introduction
Sections 4 and 5 of "Unicast-Based Rapid Synchronization with RTP
Multicast Sessions" [I-D.versteeg-avt-rapid-synchronization-for-rtp]
describe possible reasons for a synchronization delay while joining a
multimedia stream in a random point in time. Over the years,
different techniques have been developed in the industry in order to
cope with these problems. Today, organizations such as DVB and ATIS
are standardizing applications and topologies in the IPTV arena that
require a smooth user experience while joining a multimedia multicast
stream at a random point in time.
We believe that the IETF needs to define a set of standard tools to
be used by these and other applications, while deferring the
application framework to other standardization bodies. We believe
that the required tools can be built as extensions to existing RTP
and RTCP mechanisms.
Specifically, this document proposes extensions to "RTCP-Based
Feedback" [RFC4585] to reduce synchronization time when an RTP
receiver joins a multicast stream at a random point in time. The
defined mechanism relies on the definitions and the mechanisms
introduced in "RTP Retransmission Payload Format" [RFC4588] and "RTCP
Extensions for Single-Source Multicast Sessions with Unicast
Feedback" [I-D.ietf-avt-rtcpssm].
3. Definitions
The following terms are used in this document:
Media Session: Media session as defined in "RTP: A Transport
Protocol for Real-Time Applications" [RFC3550].
Original Stream: The one-to-many RTP stream of single source
multicast (SSM) RTP packets to which an RTP receiver joins at a
random point in time.
Levin & Vax Expires April 30, 2009 [Page 3]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Feedback Target: (Unicast RTCP) feedback target as defined in "RTCP
Extensions for Single-Source Multicast Sessions with Unicast
Feedback" [I-D.ietf-avt-rtcpssm].
Retransmission Packet: A "retransmission packet" as defined in "RTP
Retransmission Payload Format" [RFC4588].
Burst Packet: An RTP packet constructed according to definitions of
"RTP Retransmission Payload Format" [RFC4588] and generated upon a
request from the receiver as defined in this document.
Retransmission Stream: The stream of retransmission and burst
packets associated with the original multicast stream and
transmitted in a separate unicast RTP session in accordance with
standard RTP rules.
Burst Stream: The stream of burst packets associated with the
original multicast stream and typically transmitted at an
accelerated rate. A burst stream is a logical subset of a
retransmission stream (i.e., transmitted in the same RTP session).
Retransmission Source: The RTP/RTCP endpoint generating
retransmission stream that can be triggered and controlled by
mechanisms defined in "RTP Retransmission Payload Format"
[RFC4588] and in this document.
Media and Reference Information: Media and reference information is
a media stream containing the media content and the metadata about
it sufficient to reconstruct and use the content in the context of
a specific application. The meaning, format, and the size of this
information are specific to the application and are out of scope
of this document.
Nominal Original Bandwidth: The actual bitrate of the original
multicast stream. The burst mechanism defined in this document
assumes that the nominal bandwidth of the original multicast
stream is lower than the maximum bandwidth that the receiver can
accommodate for incoming traffic.
Maximal Burst Bandwidth: The maximal bitrate for the unicast burst
stream, which is also the maximum bitrate that the receiver can
accommodate for incoming traffic.
4. Architectural Assumptions
The burst mechanism defined in this document assumes that a receiver
Levin & Vax Expires April 30, 2009 [Page 4]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
can accommodate an incoming media and reference information stream at
a bandwidth higher than the nominal bandwidth of the original
multicast stream.
The burst mechanism defined in this document is performed on the
transport layer, i.e., it is independent of the particular codec or
application in use.
The burst mechanisms defined in this document MUST support an
architecture where the original multicast source, its feedback
target, and the retransmission source are logical entities that are
either collocated, or implemented by different physical entities in
the network. The communications between these logical entities are
out of scope for this document.
The mechanism defined in this document builds on the existing IETF
mechanisms as described in this section below:
The retransmission source and the receiver both support "RTP
Retransmission Payload Format" [RFC4588]. Specifically, they support
the session multiplexing mode as required for the multicast case.
The receiver learns about the addresses of the multicast source and
the RTP session used for sending the retransmission stream by out-of-
band means (e.g., SDP).
A unicast RTCP session is signaled out-of-band and used for sending
feedback messages to the original multicast stream in accordance with
the concepts defined in "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm].
Specifically, this unicast session is used for sending NACK messages
to trigger retransmission of the original packets over a separate
unicast RTP session as defined in "RTP Retransmission Payload Format"
[RFC4588].
The same unicast RTCP session between the receiver and the feedback
target is used for sending the new RTCP feedback primitives as
defined in this document to trigger and control the burst stream of
packets.
The same unicast retransmission RTP session is used to carry the
burst stream of packets that are formatted according to "RTP
Retransmission Payload Format" [RFC4588] from the retransmission
source to the receiver.
The retransmission stream carrying both burst and retransmission
packets MUST comply with "RTP Retransmission Payload Format"
[RFC4588]. Specifically, the sequence number has the standard RTP
definition, i.e., it MUST be one higher than the sequence number of
Levin & Vax Expires April 30, 2009 [Page 5]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
the preceding packet sent in the retransmission stream; the
retransmission packet timestamp MUST be set to the original
timestamp, i.e., to the timestamp of the original multicast packet.
5. Burst Mechanism Description
The set of tools defined in this document is designed to facilitate a
simple "burst mechanism" as described below:
Before joining the original multicast media session, a new receiver
learns about the addresses of the multicast source, its feedback
target, and the RTP session used for sending retransmission packets
by out-of-band means (e.g., SDP).
The receiver indicates that it needs to receive media and reference
information "as soon as possible" within the bandwidth limits (i.e.,
maximal burst bandwidth) known to the receiver by sending a new RTCP
Feedback "Lack of Synchronization Indication" (LSI) to the feedback
target.
Upon receiving the indication, the feedback target calculates the
actual burst rate based on the received value and its own local
policy and sends a new RTCP Feedback "Burst Bandwidth Indication"
(BBI) containing the expected bandwidth to the receiver.
Then the retransmission source proceeds to stream the media and
reference information of the indicated original stream using the
retransmission packet format at an accelerated rate (i.e. at the rate
indicated in the BBI, which is some rate higher than the nominal
original bandwidth).
Note that as a general rule, if the streaming rate needs to be
adjusted according to the retransmission local policy, the feedback
target first sends a new RTCP Feedback BBI containing the updated
bandwidth and then the retransmission source proceeds to stream at
the newly indicated bitrate.
Once the information in the burst stream matches the information
being streamed in the original stream (i.e. the burst stream "catches
up" with the original multicast media session), the feedback target
sends a new RTCP Feedback BBI and the retransmission source drops to
the nominal original bandwidth or a lower rate, subject to local
application policy.
At any stage, the receiver can join the original multicast stream and
ask to terminate the burst stream by sending a new RTCP Feedback
"Synchronization Completed Indication" (SCI) to the feedback target.
Levin & Vax Expires April 30, 2009 [Page 6]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
6. Burst Mechanism Example Flow
Figures 1 and 2 below show an example of how a simple burst mechanism
can be implemented using the extensions defined in this document.
The flow can be tailored to various applications' needs and
constraints, which are out of scope for this document. Figure 2 also
illustrates how the burst stream can be followed by retransmission
packets, and then the client can close both the retransmission and
the original sessions by sending RTCP BYE packets to each.
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
, +-----------+ +--------------+ ,
, |Feedback | |Retransmission| ,
, |Target | |Source | ,
, +-----------+ +--------------+ ,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
^ * .
| * .
| * .
| * v
+---------+ +--------+ +--------+ +---------+
| | | | | |.....>| |
|Multicast| | Router | | Router | |Receiver |
|Source | | | | |******| |
| |- - ->| |- - ->| |- - ->| |
| | | | | |<=====| |
+---------+ +--------+ +--------+ +---------+
Key:
- - -> Multicast RTP
****** Unicast RTCP
.....> Unicast RTP
=====> IGMP
Figure 1: Example of the Burst Mechanism Topology
Levin & Vax Expires April 30, 2009 [Page 7]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Multicast Feedback Retransmission Router Receiver
Source Target Source
| | | | |
| RTP multicast original session (at nominal bitrate) |
|==========================================>| |
| | | | |
| |RTCP Feedback LSI (maximal bitrate) |
| |<-------------------------------------------|
| | | | |
| |RTCP Feedback BBI (actual bitrate) |
| |------------------------------------------->|
| | | | |
| | RTP unicast burst (at actual bitrate)|
| | |=================================>|
| | | | |
| |RTCP Feedback BBI (new bitrate) |
| |------------------------------------------->|
| | | | |
| | |RTP unicast (at new bitrate) |
| | |=================================>|
| | | | |
| | | | IGMP Join |
| | | |<------------|
| | | | |
| RTP multicast original session (at nominal bitrate) |
|==========================================>|============>|
| | | | |
| |RTCP Feedback SCI | |
| |<-------------------------------------------|
| | | | |
| | |RTCP Feedback NACK | |
| |<-------------------------------------------|
| | | | |
| | RTP unicast retransmission packet(s)|
| | |=================================>|
| | | | |
| | |RTCP BYE | |
| | |<---------------------------------|
| | | | |
| | |RTCP BYE | |
| |<-------------------------------------------|
| | | | |
Figure 2: Example of the Use of the Burst Mechanism
Levin & Vax Expires April 30, 2009 [Page 8]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
7. The RTCP Extensions: New Transport Layer Feedback Messages
7.1. Lack of Synch Indication (LSI)
The LSI FB message is identified by PT=RTPFB and FMT=2.
There MUST be exactly one LSI contained in the FCI field.
7.1.1. Semantics
With the Lack of Sync Indication, a receiver can inform a feedback
target that it will be joining the original multicast media session
and therefore it needs to receive media and reference information
over the retransmission RTP session at an accelerated rate.
The LSI includes a Bitrate value which identifies the maximum bitrate
that the receiver will accommodate for the incoming unicast burst
stream.
7.1.2. Format
The Lack of Synch Indication uses additional FCI fields, the contents
of which are depicted in Figure 3. The length of the FB message MUST
be set to 3+n, with n being the number of 32-bit words comprising the
"Extensions" contained in the LSI field. If the "Extensions" does
not fall on a 32-bit boundary, then the last word MUST be padded to
the boundary using further bits set to 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Syntax of the Lack of Synch Indication (LSI)
Bitrate: 32 bits - Bitrate indicated by the receiver in bits per
second - this is the maximum bitrate of RTP stream it can
accommodate.
Levin & Vax Expires April 30, 2009 [Page 9]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Extensions: Optional extended parameters encoded using Type/Length/
Value (TLV) elements as described below:
Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
Length: A two-octet field that indicates the length of the Value
field.
Value: Variable sized set of octets that contains the specific
value for the parameter.
7.2. Burst Bandwidth Indication (BBI)
The BBI FB message is identified by PT=RTPFB and FMT=3.
There MUST be exactly one BBI contained in the FCI field.
7.2.1. Semantics
When the streaming rate needs to be changed due to a target feedback
local policy, the target feedback first sends BBI message containing
an updated bandwidth and then the retransmission source proceeds with
the streaming accordingly.
7.2.2. Format
The Burst Bandwidth Indication uses additional FCI fields, the
content of which are depicted in Figure 4. The length of the FB
message MUST be set to 3+n, with n being the number of 32-bit words
comprising the "Extensions" contained in the BBI field. If the
"Extensions" does not fall on a 32-bit boundary, then the last word
MUST be padded to the boundary using further bits set to 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax of the Burst Bandwidth Indication (BBI)
Levin & Vax Expires April 30, 2009 [Page 10]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Bitrate: 32 bits - Bitrate indicated by the sender in bits per
second - this is the actual bitrate of the RTP stream that
follows.
Extensions: Optional extended parameters encoded using Type/Length/
Value (TLV) elements as described below:
Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
Length: A two-octet field that indicates the length of the Value
field.
Value: Variable sized set of octets that contains the specific
value for the parameter.
7.3. Synch Completed Indication (SCI)
The SCI FB message is identified by PT=RTPFB and FMT=4.
There MUST be exactly one SCI contained in the FCI field.
7.3.1. Semantics
The receiver sends this indication to the feedback target to indicate
that the burst stream can be terminated.
7.3.2. Format
The Synch Completed Indication uses additional FCI fields, the
content of which are depicted in Figure 5. The length of the FB
message MUST be set to 2+n, with n being the number of 32-bit words
comprising the "Extensions" contained in the SCI field. If the
"Extensions" does not fall on a 32-bit boundary, then the last word
MUST be padded to the boundary using further bits set to 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax of the Synch Completed Indication (SCI)
Levin & Vax Expires April 30, 2009 [Page 11]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Extensions: Optional extended parameters encoded using Type/Length/
Value (TLV) elements as described below:
Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
Length: A two-octet field that indicates the length of the Value
field.
Value: Variable sized set of octets that contains the specific
value for the parameter.
8. Establishing the Retransmission RTP Session with Burst using SDP
This section will specify one of the possible ways to use an "out-of-
band" signaling to establish the retransmission RTP Session with
burst as defined in this document.
One method is to use the SDP definitions introduced in "RTP
Retransmission Payload Format" [RFC4588] and "RTCP Extensions for
Single-Source Multicast Sessions with Unicast Feedback"
[I-D.ietf-avt-rtcpssm], and new SDP attributes (if needed) for the
burst mechanism defined in this document.
9. IANA Considerations
9.1. New Transport Layer Feedback Messages
Three new RTCP Transport Layer Feedback Messages will be registered
through this document: "Lack of Synch Indication" (LSI), "Burst
Bandwidth Indication" (BBI), and "Synch Completed Indication" (SCI).
9.2. New SDP attributes
New SDP attributes will be registered through this document (if
needed) for the "out-of-band" signaling specific to the mechanism
defined in this document.
10. Security Considerations
Security considerations presented in "Why RTP Does Not Mandate a
Single Security Mechanism" [I-D.ietf-avt-srtp-not-mandatory] apply to
the mechanism defined in this document.
Levin & Vax Expires April 30, 2009 [Page 12]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
The new protocols' extensions don't introduce security considerations
beyond those presented in "RTP: A Transport Protocol for Real-Time
Applications" [RFC3550], "RTCP-Based Feedback" [RFC4585] and "RTCP
Extensions for Single-Source Multicast Sessions with Unicast
Feedback" [I-D.ietf-avt-rtcpssm].
The normal RTP security mechanism (defined in Section 9 of "RTP: A
Transport Protocol for Real-Time Applications" [RFC3550]) and
"Extended Secure RTP Profile for RTCP-Based Feedback" [RFC5124] apply
to the extensions defined in this document.
11. Acknowledgements
The authors would like to thank Majd Bakar and Guy Hirson for their
contribution to this document.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
Levin & Vax Expires April 30, 2009 [Page 13]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
(work in progress), January 2008.
12.2. Informational References
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[I-D.versteeg-avt-rapid-synchronization-for-rtp]
Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based
Rapid Synchronization with RTP Multicast Sessions",
draft-versteeg-avt-rapid-synchronization-for-rtp-00 (work
in progress), July 2008.
[I-D.ietf-avt-rtcp-guidelines]
Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)",
draft-ietf-avt-rtcp-guidelines-00 (work in progress),
July 2008.
[I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a
Single Security Mechanism",
draft-ietf-avt-srtp-not-mandatory-00 (work in progress),
July 2008.
Authors' Addresses
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425-722-2225
Email: oritl@microsoft.com
Levin & Vax Expires April 30, 2009 [Page 14]
Internet-Draft Extensions to RTCP for Burst Stream October 2008
Zeev Vax
Microsoft Corporation
1065 La Avenida St
Mountain View, CA 94043
USA
Phone: +1 650-693-2353
Email: zeevvax@microsoft.com
Levin & Vax Expires April 30, 2009 [Page 15]
Internet-Draft Extensions to RTCP for Burst Stream October 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.
Levin & Vax Expires April 30, 2009 [Page 16]