Audio/Video Transport (avt)                              T. Taylor (Ed.)
Internet-Draft                                              P. Boudreaux
Expires: November 2, 2006                                         C. Chu
                                                             R. Rabipour
                                                                May 2006

                   Time Alignment Using RTCP Feedback

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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

   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",
   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

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 +

   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)
   |  .     |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

   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

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

   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

    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

   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

   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

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

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

      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
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8


   Paul Boudreaux
   2201 Lakeside Blvd
   Richardson, Texas  75083


   Chung-Cheung Chu
   2351 Boulevard Alfred-Nobel
   St. Laurent, Quebec  H4S 2A9


   Rafi Rabipour
   2351 Boulevard Alfred-Nobel
   St. Laurent, Quebec  H4S 2A9


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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Taylor (Ed.), et al.    Expires November 2, 2006               [Page 18]