Audio/Video Transport (avt) T. Taylor (Ed.)
Internet-Draft P. Boudreaux
Expires: November 2, 2006 C. Chu
R. Rabipour
Nortel
May 2006
Time Alignment Using RTCP Feedback
draft-taylor-avt-time-align-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 November 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes the use of RTCP-based feedback to reduce end-to-
end delay through the use of time alignment between the source and
receiver.
Time alignment is useful, for example, in certain gateway-to-gateway
scenarios and certain gateway-to-VoIP-terminal scenarios. It is the
Taylor (Ed.), et al. Expires November 2, 2006 [Page 1]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
ability for a receiver to request that the sender shift the time
reference for packetization by a specified amount. When a receiver
with strict packet timing limitations, e.g., due to a 3G UMTS Iu
interface, is connected to an sender at a peer endpoint capable of
responding to time alignment requests, e.g., with an AMR encoder
associated with a PCM interface to the PSTN, this allows the
endpoints to reduce delay in the speech path by as much as the 20 ms
frame-block duration, depending on the degree of misalignment in the
time reference.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements and Applicability . . . . . . . . . . . . . . 3
2. Use of RTCP Feedback . . . . . . . . . . . . . . . . . . . . . 8
2.1. Signalling Considerations . . . . . . . . . . . . . . . . 8
2.2. Time Alignment Feedback Message Syntax . . . . . . . . . . 8
2.3. Time Alignment Behaviour . . . . . . . . . . . . . . . . . 10
2.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 10
2.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Taylor (Ed.), et al. Expires November 2, 2006 [Page 2]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
1. Introduction
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
In this document, "sender" and "receiver" always refer to the sender
and receiver of the packetized media flow. RTCP feedback messages
always pass in the reverse direction, from the receiver to the
sender.
1.2. Requirements and Applicability
Consider a situation where RTP packets are sent to a receiving
gateway (or possibly an user device) that is able to process these
packets only at a series of fixed instants in time. To simplify
subsequent discussion, let us call these the "acceptance times", and
the period between them (assumed to be constant) the "inter-
acceptance period". Of course, in steady state the inter-acceptance
period will equal the packetization period at the sender. Now if a
packet arrives just after an acceptance time, it will have to wait
for almost the entire length of the inter-acceptance period before it
can be processed. If, on the other hand, it arrives just before an
acceptance time, it will wait very little until it can be processed.
Suppose that the sender of these packets is able to adjust the time
at which it sends them. Suppose further that the receiver can ask
the sender to make such an adjustment, so that packets arrive at the
receiver as close to their acceptance times as possible. Then the
end-to-end delay entailed in delivery of the media flow will be
reduced compared with the situation where no adjustments are
possible. Averaged over a number of sessions, the reduction will
amount to half of an inter-acceptance period. For sessions at the
extreme, it will equal almost a whole inter-acceptance period. For
VoIP applications in particular, especially for wireless, this
reduction in end-to-end delay is significant.
This argument continues to hold even taking into account the effect
of jitter in real-life IP networks. The difference is that a packet
arriving at the receiver will on the average wait for at least the
duration of the jitter buffer before being accepted. If the sender
and receiver are not time-aligned, the packet will wait longer, until
the next acceptance time. This is illustrated in Figure 1. In this
figure, the horizontal axis shows successive acceptance times at the
receiver. The vertical axis shows successive packet generation times
at the sender. The line shows the trajectory of a given packet
Taylor (Ed.), et al. Expires November 2, 2006 [Page 3]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
through time. Here TO is the time it is sent, TA is the expected
time of arrival, and TB is the expected time for it to pass through
the jitter buffer. However, because of misalignment, it is not
actually accepted until TC. The amount TC-TB is the measure of
schedule misalignment between the sender and the receiver.
| Sender's
+ packet
| schedule
|
|
|
+
| \ |Intended | |
| \ |jitter | |
| \ |buffer | ---- Misalignment
| \ |delay | / |
+ \ |<------->|<->|
| \| | |
| |\ | |
| | \ | |
| | \ | | Receiver's
+ | \ | | packet
| | \| | schedule
--------+-----|---+-----|---+---------+
TO TA TB TC
Figure 1: Increase in end-to-end delay due to schedule misalignment
More formally, the time any individual packet waits at the receiver
before being accepted is given by:
(1) Total wait = Rand + Intended jitter buffer delay +
Misalignment
In this expression, Rand is a random jitter amount, positive or
negative depending on whether the packet arrives early or late, but
with average value zero. Rearranging (1) and averaging, we arrive at
an estimate (2) for the amount of misalignment between the sender and
the receiver. One statistical rule of thumb suggests that to obtain
a reasonably accurate estimate from (2) requires an average using the
observed total wait times for about thirty packets.
(2) Misalignment (estimated) = average (Total wait - Intended
jitter buffer duration)
Taylor (Ed.), et al. Expires November 2, 2006 [Page 4]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
Since Misalignment in the above expression is the average extra time
a packet has to wait beyond what was intended in setting the jitter
buffer, it would be eliminated if the sender shifted its schedule to
release its packets later by that amount. This is illustrated in
Figure 2. The old time trajectory is shown by dots, parallel to the
new one. Times TO', TA', and TB' are all increased relative to TO,
TA, and TB, by the amount of the adjustment. The result of the
adjustment is to make TB', the expected time of exit from the jitter
buffer, exactly equal to TC, the time the packet is accepted.
| Sender's
x packet
| schedule
| (x is old, + is new)
+
| \
x \
| . \ | Intended |
| . \ | jitter |
+ . \ | buffer |
| . \ | delay |
x . \ |<-------->|
| . \ |
| . | \ |
+ . \ |
| | . \ | Receiver's
x | . \ | packet
| | . \| schedule
--------+--------|+---------+---------+
TO' TA' TB' = TC
Figure 2: Elimination of misalignment by schedule delay
Figure 2 showed alignment through a shift in packet scheduling at the
sender achieved by a delay in packet transmission. Assuming that the
sender maintains the packet size (i.e., the time period covered by a
single packet), this means that the sender actually discards a
portion of the media flow while it is forming the first packet of the
new schedule. For the receiving user, this may be perceptible as a
one-time impairment.
As an alternative to requesting a schedule delay, the receiver could
ask that the sending of packets be advanced, so that they are
received in time to be processed one acceptance time earlier than
they would be without the adjustment. This is illustrated in
Figure 3. A packet that would have been sent at time TO in the
Taylor (Ed.), et al. Expires November 2, 2006 [Page 5]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
unadjusted schedule is now sent at TO". It is expected to arrive at
TA", pass through the jitter buffer at TB", and immediately be
accepted. Note that the new acceptance time is TC", which is one
acceptance time earlier than the unadjusted TC.
| Sender's
x packet
| schedule
+ (x = old, + = new)
|
|
x
| . |Intended|
+ . | jitter |
|\ . | buffer |
| \ . delay |
x \ |<.----->|
| \ | . |
+ \ . |
| | \ .|
| | \ |. Receiver's
x | \ | . packet
| | \| . schedule
--------+|--------+---------+---------+
TO" TA" TB" = TC" TC
Figure 3: Elimination of misalignment by schedule advancement
Advancing the packet schedule may also cause a perceived impairment
for the receiving user, since to maintain a constant packet size the
sender will have to pad the first packet of the new schedule. As a
pragmatic matter, it is best to leave the decision whether to ask for
a one-time delay or a one-time advancement in packet scheduling to
the individual implementation. This memo assumes a convention that a
positive adjustment value requests a delay, while a negative one
requests that transmission be scheduled earlier. Following that
convention, the value of the required adjustment using schedule
advancement is given by:
(3) Adjustment for schedule advancement = Estimated misalignment -
Inter-acceptance period
where "Estimated misalignment" is given by (2) above.
Note that time alignment is an optimization that reduces delay by
adjusting the sender's packet transmission phase so that the packet
Taylor (Ed.), et al. Expires November 2, 2006 [Page 6]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
arrives just in time for consumption. When the delay statistics
change substantially during a call because of:
o a change in sender or receiver scheduling, perhaps due to mobile
handoff, or
o a change in the intended jitter buffer delay
then delay optimization will benefit from re-invocation of time
alignment. However, to avoid excessively repeated requests for time
alignment it is recommended to issue a new time alignment request
only after the delay/jitter statistics for the flow have stabilized.
In environments where the delay or jitter continuously varies, the
usefulness of time alignment is significantly reduced. In this case
the receiver will be out of alignment most of the time, and sent
requests may become dated even before the media sender has managed to
implement them. The time alignment procedure should include a means
for detecting this condition, to minimize the both the amount of
transmission impairment and the consumption of processing and network
resources due to the use of the time alignment procedure when this
procedure will be ineffective.
This memo proposes an adjustment signalling mechanism based on RTCP
feedback [6]. Because RTCP is typically transported unreliably,
individual feedback messages requesting time alignment may be lost.
Thus the receiver will have a need to repeat a request if it
determines that its previous attempt had no effect. However, the
previous paragraph pointed out that an additional adjustment may be
needed during the course of a call. This raises the possibility that
upon rare occasion the sender needs to distinguish between a
repetition of an earlier time alignment request that it has already
received and a new time alignment request. The mechanism must
therefore provide some means whereby different requests can be
distinguished.
As a final point, this discussion clearly applies only to the case of
point-to-point packet streams. Attempts to regulate a multicast
stream would enmesh the sender in a tangle of conflicting adjustment
requests from different receivers. If a sender determines that it is
involved in such a situation, the time alignment procedures should
allow it to ignore time alignment requests.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 7]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
2. Use of RTCP Feedback
The time alignment process described in the preceding section
postulated a means whereby the receiver could indicate the amount of
a desired adjustment, positive or negative, to be applied to packet
scheduling at the sender. This memo proposes the use of the RTCP
feedback mechanism described in [6] to meet that requirement. The
use of this mechanism requires the definition of a new feedback
message format and a definition of the behaviour associated with such
reports.
2.1. Signalling Considerations
The mechanism defined in this memo is designed so that the receiver
can try to use it even if the sender does not support time alignment.
Of course, in that case the attempts will fail, but the mechanism is
designed for this possibility to cover the case where the sender and
receiver do not signal their capabilities to each other in advance of
the media connection. Where the Session Description Protocol (SDP)
[5] is used to establish the session description in advance of the
media flow, the receiver MUST follow the procedures specified in
section 4.2 of [6]. In support of those procedures, this document
extends the syntax of the "rtcp-fb" attribute using the notation of
section 3.3 of [4]:
rtcp-fb-val =/ "taln"
This conforms to the general syntax defined in section 4.2 of [6]
with 'rtcp-fb-id' set equal to "taln" and 'rtcp-fb-param' made empty.
2.2. Time Alignment Feedback Message Syntax
This section defines a new RTCP feedback message type based on
section 6 of [6].
Time alignment is in principle a codec-independent procedure. Thus
this memo defines a transport layer feedback message. Figure 4
below, which is based on Figure 3 of [6], shows the packet format for
this message.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 8]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=2 | PT = 205 | length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender (note) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Alignment Feedback Control Information (FCI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: This is the SSRC of the "receiver" as the term is used in this
document.
Figure 4: Packet Format for Time Alignment Feedback Messages
Since this memo defines a transport layer feedback message, the
payload type (PT) field in the common RTCP header as shown in
Figure 4 MUST have the value 205 (RTPFB). This memo assigns the
value 2 to the FMT field, designating a Time Alignment feedback
message. The length field MUST have value 3, designating a total of
four 32-bit words. This provides for a single instance of the Time
Alignment Feedback Control Information, the format of which is shown
in Figure 5. This message does not contain padding, so the P field
MUST have value 0. The remaining header fields are as described in
[6].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| sequence | reserved | amag (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of the Time Alignment Feedback Control Information
(FCI)
In Figure 5, S is the sign bit. If S is 0, the receiver is
requesting a one-time delay in packet scheduling at the sender. If S
is 1, the receiver is requesting a one-time advance in packet
scheduling. The 'sequence' field allows the sender to distinguish
between different Time Alignment requests, as described below. The
bits marked "reserved" in the Time Alignment FCI MUST be set to 0 by
the requesting entity (i.e., the receiver), and MUST be ignored by
the to which the request is directed (i.e., the sender). Finally,
the amag field in the Time Alignment FCI is a binary integer between
0 and 255 indicating the magnitude of the desired scheduling
adjustment, in 500 microsecond (0.5 millisecond) increments.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 9]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
2.3. Time Alignment Behaviour
2.3.1. Sender Behaviour
This subsection assumes that the sender is able and willing to act
upon Time Alignment feedback messages. If it is not, it ignores
them, as specified in section 6.1 of [2] and section 4.2 of [6].
The sender MUST save the value of the sequence number of the last
Time Alignment feedback message it acted on.
If a given Time Alignment feedback message is the first that the
sender has received for a given media flow, the sender delays or
advances its packetization schedule as requested, to the extent
possible. If a subsequent message is received, the sender MUST first
check the value of the sequence number of the new message. The
sender MUST ignore the message if the sequence number of that message
is less than or equal to the saved sequence number value. For saved
sequence number values near the upper limit of the range of the
sequence number field, the sender MUST apply wrap-around logic in
making this decision.
As indicated in Section 1.2, a delay in packetization implies that
some media content must be discarded before the initial packet of the
new schedule is generated. The RTP timestamps of that initial packet
of the new schedule and its successors MUST reflect the time at which
they should be played out relative to the preceding packets in the
same media flow.
For example, if a delay of 2 ms is requested and acted upon by
waiting 2 ms before starting to fill the initial packet of the new
schedule, the timestamp of that initial packet will be larger than
it would have been without the time adjustment by the equivalent
of 2 ms. At a timestamp rate of 8000 per second, for instance,
the timestamp of the initial packet and its successors is greater
by 16 than it would have been in the absence of the adjustment.
An advance in scheduling implies that the sender may have to add some
redundant (interpolated) content to the first packet sent according
to the new schedule to fill out the packet, depending on the specific
codec involved. This document does not specify whether the
interpolated content is added at the beginning or end of the packet,
but the timestamp of the initial and succeeding packets in either
case MUST reflect the time adjustment.
Codec-specific considerations may govern the decision on when the
sender makes the schedule change. For instance, the codec may
involve natural boundaries after which material may be added or
Taylor (Ed.), et al. Expires November 2, 2006 [Page 10]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
dropped as required. Codec-specific considerations may also require
adjustment of time related values within the payload.
2.3.2. Receiver Behaviour
Time Alignment feedback message sequence numbers MUST begin at 0 for
the first message of a media flow, incrementing by 1 for subsequent
adjustment requests. If the sequence number reaches the maximum
value of its range, the number sequence MUST be continued by starting
at 0 again.
The receiver MAY send an initial Time Alignment feedback message as
soon as it has formed a stable estimate of the value of Misalignment
as defined in Section 1.2 for the media flow, or it MAY wait to
incorporate the message in a compound RTCP packet at the regularly
scheduled time. After the initial Time Alignment feedback message
has been sent, the interval between consecutive Time Alignment
feedback messages MUST NOT be less than one second. In any case, the
receiver MUST comply with the rules for scheduling of RTCP feedback
messages as described in [6].
When the receiver has sent a Time Alignment feedback message, it
SHOULD monitor for a packet scheduling change indicating that the
sender has acted on its request. If the receiver concludes that the
request was not honoured, possibly due to loss of the RTCP packet, it
MAY reissue the request. In this case, it MUST use the same sequence
number value as the original request. The receiver MUST NOT generate
more than three instances of a given request, since it is unlikely
under the stated timing rules that all three instances were lost in
transmission.
The receiver MAY continue to form new estimates of Misalignment
throughout the RTP session. Before further requests for time
alignment are issued, the estimate of Misalignment SHOULD pass two
tests. The first is whether the estimate is stable. This can be
tested by determining whether the difference between two estimates of
Misalignment based on independent samples is statistically
insignificant. If this test is passed, the second test is whether
the observed estimates are due to random effects only, or represent
true a true misalignment. This may be tested by determining whether
the difference between the estimate of Misalignment and zero is
statistically significant. If both these tests are passed, the
receiver MAY issue a new request based on an estimate of Misalignment
based on the combined sample. For a new request generated according
to these rules, the receiver MUST use an incremented value of the
sequence number as described above.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 11]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
One possible measure of a statistically significant difference in
the above paragraph may be the latest estimate of packet jitter
multiplied by a suitable constant which itself is based on the
sample size used for each estimate of Misalignment. [The
necessary statistical calculations to implement this may be added
as an appendix in a later version of this document if this is seen
as desirable. It may make more sense to use the sample standard
deviation.]
Taylor (Ed.), et al. Expires November 2, 2006 [Page 12]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
3. Security Considerations
The protocol around Time Alignment feedback messages introduces no
new security threats not already presented by RTCP messages in
general. However, the Time Alignment procedure at the semantic level
introduces an opportunity for an attacker to degrade the quality of a
media flow. The lesser threat is that the attacker injects a series
of Time Alignment feedback messages into the RTCP stream, each
causing a momentary impairment in the media flow by requesting a
scheduling delay. The greater threat is that either through message
injection or modification of genuine messages the attacker causes the
end-to-end delay to increase rather than decrease.
These threats introduce a requirement for message authentication and
integrity protection of the Time Alignment feedback messages. For
this reason, applications using the Time Alignment procedure SHOULD
use SRTP [3] for protection of the RTCP stream.
Note that the method of key exchange for SRTP is still an open
question, and may vary with the specific application. In some
cases a method of protection other than SRTP may be more
appropriate.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 13]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
4. IANA Considerations
This document registers an additional value "taln" as defined in this
document, for the attribute "rtcp-fb" as defined in [6]:
Value name: taln
Long name: Time alignment.
Reference: RFC XXXX.
The value "taln" has no additional arguments.
This document further registers the following format (FMT) value
within the subregistry corresponding to the RTCP control packet type
"RTPFB":
Name: Taln
Long name: Time Alignment.
Value: 2
Reference: RFC XXXX.
The Time Alignment format value requires that the packet contain a
single instance of the Time Alignment Feedback Control Information as
described in Section 2.2 of RFC XXXX.
NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 14]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
5. Acknowledgements
Richard Ejzak first raised the topic of time alignment in an earlier
Internet Draft. This contribution has borrowed some of his words.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 15]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC TBD.
[6] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
RFC TBD.
6.2. Informative References
[7] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC TBD.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 16]
Internet-Draft Time Alignment Using RTCP Feedback May 2006
Authors' Addresses
Tom Taylor
Nortel
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
CA
Email: taylor@nortel.com
Paul Boudreaux
Nortel
2201 Lakeside Blvd
Richardson, Texas 75083
USA
Email: paulbx@nortel.com
Chung-Cheung Chu
Nortel
2351 Boulevard Alfred-Nobel
St. Laurent, Quebec H4S 2A9
Canada
Email: ccheung@nortel.com
Rafi Rabipour
Nortel
2351 Boulevard Alfred-Nobel
St. Laurent, Quebec H4S 2A9
Canada
Email: rabipour@nortel.com
Taylor (Ed.), et al. Expires November 2, 2006 [Page 17]
Internet-Draft Time Alignment Using RTCP Feedback May 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.
Taylor (Ed.), et al. Expires November 2, 2006 [Page 18]