idnits 2.17.1 draft-taylor-avt-time-align-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6555 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport (avt) T. Taylor (Ed.) 3 Internet-Draft P. Boudreaux 4 Expires: November 2, 2006 C. Chu 5 R. Rabipour 6 Nortel 7 May 2006 9 Time Alignment Using RTCP Feedback 10 draft-taylor-avt-time-align-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 2, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This memo describes the use of RTCP-based feedback to reduce end-to- 44 end delay through the use of time alignment between the source and 45 receiver. 47 Time alignment is useful, for example, in certain gateway-to-gateway 48 scenarios and certain gateway-to-VoIP-terminal scenarios. It is the 49 ability for a receiver to request that the sender shift the time 50 reference for packetization by a specified amount. When a receiver 51 with strict packet timing limitations, e.g., due to a 3G UMTS Iu 52 interface, is connected to an sender at a peer endpoint capable of 53 responding to time alignment requests, e.g., with an AMR encoder 54 associated with a PCM interface to the PSTN, this allows the 55 endpoints to reduce delay in the speech path by as much as the 20 ms 56 frame-block duration, depending on the degree of misalignment in the 57 time reference. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Requirements and Applicability . . . . . . . . . . . . . . 3 64 2. Use of RTCP Feedback . . . . . . . . . . . . . . . . . . . . . 8 65 2.1. Signalling Considerations . . . . . . . . . . . . . . . . 8 66 2.2. Time Alignment Feedback Message Syntax . . . . . . . . . . 8 67 2.3. Time Alignment Behaviour . . . . . . . . . . . . . . . . . 10 68 2.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 10 69 2.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 11 70 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 Intellectual Property and Copyright Statements . . . . . . . . . . 18 79 1. Introduction 81 1.1. Terminology 83 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 84 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 85 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 87 In this document, "sender" and "receiver" always refer to the sender 88 and receiver of the packetized media flow. RTCP feedback messages 89 always pass in the reverse direction, from the receiver to the 90 sender. 92 1.2. Requirements and Applicability 94 Consider a situation where RTP packets are sent to a receiving 95 gateway (or possibly an user device) that is able to process these 96 packets only at a series of fixed instants in time. To simplify 97 subsequent discussion, let us call these the "acceptance times", and 98 the period between them (assumed to be constant) the "inter- 99 acceptance period". Of course, in steady state the inter-acceptance 100 period will equal the packetization period at the sender. Now if a 101 packet arrives just after an acceptance time, it will have to wait 102 for almost the entire length of the inter-acceptance period before it 103 can be processed. If, on the other hand, it arrives just before an 104 acceptance time, it will wait very little until it can be processed. 106 Suppose that the sender of these packets is able to adjust the time 107 at which it sends them. Suppose further that the receiver can ask 108 the sender to make such an adjustment, so that packets arrive at the 109 receiver as close to their acceptance times as possible. Then the 110 end-to-end delay entailed in delivery of the media flow will be 111 reduced compared with the situation where no adjustments are 112 possible. Averaged over a number of sessions, the reduction will 113 amount to half of an inter-acceptance period. For sessions at the 114 extreme, it will equal almost a whole inter-acceptance period. For 115 VoIP applications in particular, especially for wireless, this 116 reduction in end-to-end delay is significant. 118 This argument continues to hold even taking into account the effect 119 of jitter in real-life IP networks. The difference is that a packet 120 arriving at the receiver will on the average wait for at least the 121 duration of the jitter buffer before being accepted. If the sender 122 and receiver are not time-aligned, the packet will wait longer, until 123 the next acceptance time. This is illustrated in Figure 1. In this 124 figure, the horizontal axis shows successive acceptance times at the 125 receiver. The vertical axis shows successive packet generation times 126 at the sender. The line shows the trajectory of a given packet 127 through time. Here TO is the time it is sent, TA is the expected 128 time of arrival, and TB is the expected time for it to pass through 129 the jitter buffer. However, because of misalignment, it is not 130 actually accepted until TC. The amount TC-TB is the measure of 131 schedule misalignment between the sender and the receiver. 133 | Sender's 134 + packet 135 | schedule 136 | 137 | 138 | 139 + 140 | \ |Intended | | 141 | \ |jitter | | 142 | \ |buffer | ---- Misalignment 143 | \ |delay | / | 144 + \ |<------->|<->| 145 | \| | | 146 | |\ | | 147 | | \ | | 148 | | \ | | Receiver's 149 + | \ | | packet 150 | | \| | schedule 151 --------+-----|---+-----|---+---------+ 152 TO TA TB TC 154 Figure 1: Increase in end-to-end delay due to schedule misalignment 156 More formally, the time any individual packet waits at the receiver 157 before being accepted is given by: 159 (1) Total wait = Rand + Intended jitter buffer delay + 160 Misalignment 162 In this expression, Rand is a random jitter amount, positive or 163 negative depending on whether the packet arrives early or late, but 164 with average value zero. Rearranging (1) and averaging, we arrive at 165 an estimate (2) for the amount of misalignment between the sender and 166 the receiver. One statistical rule of thumb suggests that to obtain 167 a reasonably accurate estimate from (2) requires an average using the 168 observed total wait times for about thirty packets. 170 (2) Misalignment (estimated) = average (Total wait - Intended 171 jitter buffer duration) 173 Since Misalignment in the above expression is the average extra time 174 a packet has to wait beyond what was intended in setting the jitter 175 buffer, it would be eliminated if the sender shifted its schedule to 176 release its packets later by that amount. This is illustrated in 177 Figure 2. The old time trajectory is shown by dots, parallel to the 178 new one. Times TO', TA', and TB' are all increased relative to TO, 179 TA, and TB, by the amount of the adjustment. The result of the 180 adjustment is to make TB', the expected time of exit from the jitter 181 buffer, exactly equal to TC, the time the packet is accepted. 183 | Sender's 184 x packet 185 | schedule 186 | (x is old, + is new) 187 + 188 | \ 189 x \ 190 | . \ | Intended | 191 | . \ | jitter | 192 + . \ | buffer | 193 | . \ | delay | 194 x . \ |<-------->| 195 | . \ | 196 | . | \ | 197 + . \ | 198 | | . \ | Receiver's 199 x | . \ | packet 200 | | . \| schedule 201 --------+--------|+---------+---------+ 202 TO' TA' TB' = TC 204 Figure 2: Elimination of misalignment by schedule delay 206 Figure 2 showed alignment through a shift in packet scheduling at the 207 sender achieved by a delay in packet transmission. Assuming that the 208 sender maintains the packet size (i.e., the time period covered by a 209 single packet), this means that the sender actually discards a 210 portion of the media flow while it is forming the first packet of the 211 new schedule. For the receiving user, this may be perceptible as a 212 one-time impairment. 214 As an alternative to requesting a schedule delay, the receiver could 215 ask that the sending of packets be advanced, so that they are 216 received in time to be processed one acceptance time earlier than 217 they would be without the adjustment. This is illustrated in 218 Figure 3. A packet that would have been sent at time TO in the 219 unadjusted schedule is now sent at TO". It is expected to arrive at 220 TA", pass through the jitter buffer at TB", and immediately be 221 accepted. Note that the new acceptance time is TC", which is one 222 acceptance time earlier than the unadjusted TC. 224 | Sender's 225 x packet 226 | schedule 227 + (x = old, + = new) 228 | 229 | 230 x 231 | . |Intended| 232 + . | jitter | 233 |\ . | buffer | 234 | \ . delay | 235 x \ |<.----->| 236 | \ | . | 237 + \ . | 238 | | \ .| 239 | | \ |. Receiver's 240 x | \ | . packet 241 | | \| . schedule 242 --------+|--------+---------+---------+ 243 TO" TA" TB" = TC" TC 245 Figure 3: Elimination of misalignment by schedule advancement 247 Advancing the packet schedule may also cause a perceived impairment 248 for the receiving user, since to maintain a constant packet size the 249 sender will have to pad the first packet of the new schedule. As a 250 pragmatic matter, it is best to leave the decision whether to ask for 251 a one-time delay or a one-time advancement in packet scheduling to 252 the individual implementation. This memo assumes a convention that a 253 positive adjustment value requests a delay, while a negative one 254 requests that transmission be scheduled earlier. Following that 255 convention, the value of the required adjustment using schedule 256 advancement is given by: 258 (3) Adjustment for schedule advancement = Estimated misalignment - 259 Inter-acceptance period 261 where "Estimated misalignment" is given by (2) above. 263 Note that time alignment is an optimization that reduces delay by 264 adjusting the sender's packet transmission phase so that the packet 265 arrives just in time for consumption. When the delay statistics 266 change substantially during a call because of: 268 o a change in sender or receiver scheduling, perhaps due to mobile 269 handoff, or 271 o a change in the intended jitter buffer delay 273 then delay optimization will benefit from re-invocation of time 274 alignment. However, to avoid excessively repeated requests for time 275 alignment it is recommended to issue a new time alignment request 276 only after the delay/jitter statistics for the flow have stabilized. 278 In environments where the delay or jitter continuously varies, the 279 usefulness of time alignment is significantly reduced. In this case 280 the receiver will be out of alignment most of the time, and sent 281 requests may become dated even before the media sender has managed to 282 implement them. The time alignment procedure should include a means 283 for detecting this condition, to minimize the both the amount of 284 transmission impairment and the consumption of processing and network 285 resources due to the use of the time alignment procedure when this 286 procedure will be ineffective. 288 This memo proposes an adjustment signalling mechanism based on RTCP 289 feedback [6]. Because RTCP is typically transported unreliably, 290 individual feedback messages requesting time alignment may be lost. 291 Thus the receiver will have a need to repeat a request if it 292 determines that its previous attempt had no effect. However, the 293 previous paragraph pointed out that an additional adjustment may be 294 needed during the course of a call. This raises the possibility that 295 upon rare occasion the sender needs to distinguish between a 296 repetition of an earlier time alignment request that it has already 297 received and a new time alignment request. The mechanism must 298 therefore provide some means whereby different requests can be 299 distinguished. 301 As a final point, this discussion clearly applies only to the case of 302 point-to-point packet streams. Attempts to regulate a multicast 303 stream would enmesh the sender in a tangle of conflicting adjustment 304 requests from different receivers. If a sender determines that it is 305 involved in such a situation, the time alignment procedures should 306 allow it to ignore time alignment requests. 308 2. Use of RTCP Feedback 310 The time alignment process described in the preceding section 311 postulated a means whereby the receiver could indicate the amount of 312 a desired adjustment, positive or negative, to be applied to packet 313 scheduling at the sender. This memo proposes the use of the RTCP 314 feedback mechanism described in [6] to meet that requirement. The 315 use of this mechanism requires the definition of a new feedback 316 message format and a definition of the behaviour associated with such 317 reports. 319 2.1. Signalling Considerations 321 The mechanism defined in this memo is designed so that the receiver 322 can try to use it even if the sender does not support time alignment. 323 Of course, in that case the attempts will fail, but the mechanism is 324 designed for this possibility to cover the case where the sender and 325 receiver do not signal their capabilities to each other in advance of 326 the media connection. Where the Session Description Protocol (SDP) 327 [5] is used to establish the session description in advance of the 328 media flow, the receiver MUST follow the procedures specified in 329 section 4.2 of [6]. In support of those procedures, this document 330 extends the syntax of the "rtcp-fb" attribute using the notation of 331 section 3.3 of [4]: 333 rtcp-fb-val =/ "taln" 335 This conforms to the general syntax defined in section 4.2 of [6] 336 with 'rtcp-fb-id' set equal to "taln" and 'rtcp-fb-param' made empty. 338 2.2. Time Alignment Feedback Message Syntax 340 This section defines a new RTCP feedback message type based on 341 section 6 of [6]. 343 Time alignment is in principle a codec-independent procedure. Thus 344 this memo defines a transport layer feedback message. Figure 4 345 below, which is based on Figure 3 of [6], shows the packet format for 346 this message. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |V=2|P| FMT=2 | PT = 205 | length = 3 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | SSRC of packet sender (note) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | SSRC of media source | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Time Alignment Feedback Control Information (FCI) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Note: This is the SSRC of the "receiver" as the term is used in this 361 document. 363 Figure 4: Packet Format for Time Alignment Feedback Messages 365 Since this memo defines a transport layer feedback message, the 366 payload type (PT) field in the common RTCP header as shown in 367 Figure 4 MUST have the value 205 (RTPFB). This memo assigns the 368 value 2 to the FMT field, designating a Time Alignment feedback 369 message. The length field MUST have value 3, designating a total of 370 four 32-bit words. This provides for a single instance of the Time 371 Alignment Feedback Control Information, the format of which is shown 372 in Figure 5. This message does not contain padding, so the P field 373 MUST have value 0. The remaining header fields are as described in 374 [6]. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |S| sequence | reserved | amag (ms) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 5: Format of the Time Alignment Feedback Control Information 383 (FCI) 385 In Figure 5, S is the sign bit. If S is 0, the receiver is 386 requesting a one-time delay in packet scheduling at the sender. If S 387 is 1, the receiver is requesting a one-time advance in packet 388 scheduling. The 'sequence' field allows the sender to distinguish 389 between different Time Alignment requests, as described below. The 390 bits marked "reserved" in the Time Alignment FCI MUST be set to 0 by 391 the requesting entity (i.e., the receiver), and MUST be ignored by 392 the to which the request is directed (i.e., the sender). Finally, 393 the amag field in the Time Alignment FCI is a binary integer between 394 0 and 255 indicating the magnitude of the desired scheduling 395 adjustment, in 500 microsecond (0.5 millisecond) increments. 397 2.3. Time Alignment Behaviour 399 2.3.1. Sender Behaviour 401 This subsection assumes that the sender is able and willing to act 402 upon Time Alignment feedback messages. If it is not, it ignores 403 them, as specified in section 6.1 of [2] and section 4.2 of [6]. 405 The sender MUST save the value of the sequence number of the last 406 Time Alignment feedback message it acted on. 408 If a given Time Alignment feedback message is the first that the 409 sender has received for a given media flow, the sender delays or 410 advances its packetization schedule as requested, to the extent 411 possible. If a subsequent message is received, the sender MUST first 412 check the value of the sequence number of the new message. The 413 sender MUST ignore the message if the sequence number of that message 414 is less than or equal to the saved sequence number value. For saved 415 sequence number values near the upper limit of the range of the 416 sequence number field, the sender MUST apply wrap-around logic in 417 making this decision. 419 As indicated in Section 1.2, a delay in packetization implies that 420 some media content must be discarded before the initial packet of the 421 new schedule is generated. The RTP timestamps of that initial packet 422 of the new schedule and its successors MUST reflect the time at which 423 they should be played out relative to the preceding packets in the 424 same media flow. 426 For example, if a delay of 2 ms is requested and acted upon by 427 waiting 2 ms before starting to fill the initial packet of the new 428 schedule, the timestamp of that initial packet will be larger than 429 it would have been without the time adjustment by the equivalent 430 of 2 ms. At a timestamp rate of 8000 per second, for instance, 431 the timestamp of the initial packet and its successors is greater 432 by 16 than it would have been in the absence of the adjustment. 434 An advance in scheduling implies that the sender may have to add some 435 redundant (interpolated) content to the first packet sent according 436 to the new schedule to fill out the packet, depending on the specific 437 codec involved. This document does not specify whether the 438 interpolated content is added at the beginning or end of the packet, 439 but the timestamp of the initial and succeeding packets in either 440 case MUST reflect the time adjustment. 442 Codec-specific considerations may govern the decision on when the 443 sender makes the schedule change. For instance, the codec may 444 involve natural boundaries after which material may be added or 445 dropped as required. Codec-specific considerations may also require 446 adjustment of time related values within the payload. 448 2.3.2. Receiver Behaviour 450 Time Alignment feedback message sequence numbers MUST begin at 0 for 451 the first message of a media flow, incrementing by 1 for subsequent 452 adjustment requests. If the sequence number reaches the maximum 453 value of its range, the number sequence MUST be continued by starting 454 at 0 again. 456 The receiver MAY send an initial Time Alignment feedback message as 457 soon as it has formed a stable estimate of the value of Misalignment 458 as defined in Section 1.2 for the media flow, or it MAY wait to 459 incorporate the message in a compound RTCP packet at the regularly 460 scheduled time. After the initial Time Alignment feedback message 461 has been sent, the interval between consecutive Time Alignment 462 feedback messages MUST NOT be less than one second. In any case, the 463 receiver MUST comply with the rules for scheduling of RTCP feedback 464 messages as described in [6]. 466 When the receiver has sent a Time Alignment feedback message, it 467 SHOULD monitor for a packet scheduling change indicating that the 468 sender has acted on its request. If the receiver concludes that the 469 request was not honoured, possibly due to loss of the RTCP packet, it 470 MAY reissue the request. In this case, it MUST use the same sequence 471 number value as the original request. The receiver MUST NOT generate 472 more than three instances of a given request, since it is unlikely 473 under the stated timing rules that all three instances were lost in 474 transmission. 476 The receiver MAY continue to form new estimates of Misalignment 477 throughout the RTP session. Before further requests for time 478 alignment are issued, the estimate of Misalignment SHOULD pass two 479 tests. The first is whether the estimate is stable. This can be 480 tested by determining whether the difference between two estimates of 481 Misalignment based on independent samples is statistically 482 insignificant. If this test is passed, the second test is whether 483 the observed estimates are due to random effects only, or represent 484 true a true misalignment. This may be tested by determining whether 485 the difference between the estimate of Misalignment and zero is 486 statistically significant. If both these tests are passed, the 487 receiver MAY issue a new request based on an estimate of Misalignment 488 based on the combined sample. For a new request generated according 489 to these rules, the receiver MUST use an incremented value of the 490 sequence number as described above. 492 One possible measure of a statistically significant difference in 493 the above paragraph may be the latest estimate of packet jitter 494 multiplied by a suitable constant which itself is based on the 495 sample size used for each estimate of Misalignment. [The 496 necessary statistical calculations to implement this may be added 497 as an appendix in a later version of this document if this is seen 498 as desirable. It may make more sense to use the sample standard 499 deviation.] 501 3. Security Considerations 503 The protocol around Time Alignment feedback messages introduces no 504 new security threats not already presented by RTCP messages in 505 general. However, the Time Alignment procedure at the semantic level 506 introduces an opportunity for an attacker to degrade the quality of a 507 media flow. The lesser threat is that the attacker injects a series 508 of Time Alignment feedback messages into the RTCP stream, each 509 causing a momentary impairment in the media flow by requesting a 510 scheduling delay. The greater threat is that either through message 511 injection or modification of genuine messages the attacker causes the 512 end-to-end delay to increase rather than decrease. 514 These threats introduce a requirement for message authentication and 515 integrity protection of the Time Alignment feedback messages. For 516 this reason, applications using the Time Alignment procedure SHOULD 517 use SRTP [3] for protection of the RTCP stream. 519 Note that the method of key exchange for SRTP is still an open 520 question, and may vary with the specific application. In some 521 cases a method of protection other than SRTP may be more 522 appropriate. 524 4. IANA Considerations 526 This document registers an additional value "taln" as defined in this 527 document, for the attribute "rtcp-fb" as defined in [6]: 529 Value name: taln 531 Long name: Time alignment. 533 Reference: RFC XXXX. 535 The value "taln" has no additional arguments. 537 This document further registers the following format (FMT) value 538 within the subregistry corresponding to the RTCP control packet type 539 "RTPFB": 541 Name: Taln 543 Long name: Time Alignment. 545 Value: 2 547 Reference: RFC XXXX. 549 The Time Alignment format value requires that the packet contain a 550 single instance of the Time Alignment Feedback Control Information as 551 described in Section 2.2 of RFC XXXX. 553 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 554 the RFC number assigned to this document. 556 5. Acknowledgements 558 Richard Ejzak first raised the topic of time alignment in an earlier 559 Internet Draft. This contribution has borrowed some of his words. 561 6. References 563 6.1. Normative References 565 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 566 Levels", BCP 14, RFC 2119, March 1997. 568 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 569 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 570 RFC 3550, July 2003. 572 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 573 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 574 RFC 3711, March 2004. 576 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 577 Specifications: ABNF", RFC 4234, October 2005. 579 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 580 Description Protocol", RFC TBD. 582 [6] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 583 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 584 RFC TBD. 586 6.2. Informative References 588 [7] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, 589 Telephony Tones and Telephony Signals", RFC TBD. 591 Authors' Addresses 593 Tom Taylor 594 Nortel 595 1852 Lorraine Ave 596 Ottawa, Ontario K1H 6Z8 597 CA 599 Email: taylor@nortel.com 601 Paul Boudreaux 602 Nortel 603 2201 Lakeside Blvd 604 Richardson, Texas 75083 605 USA 607 Email: paulbx@nortel.com 609 Chung-Cheung Chu 610 Nortel 611 2351 Boulevard Alfred-Nobel 612 St. Laurent, Quebec H4S 2A9 613 Canada 615 Email: ccheung@nortel.com 617 Rafi Rabipour 618 Nortel 619 2351 Boulevard Alfred-Nobel 620 St. Laurent, Quebec H4S 2A9 621 Canada 623 Email: rabipour@nortel.com 625 Intellectual Property Statement 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the procedures with respect to rights in RFC documents can be 634 found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 Disclaimer of Validity 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Copyright Statement 661 Copyright (C) The Internet Society (2006). This document is subject 662 to the rights, licenses and restrictions contained in BCP 78, and 663 except as set forth therein, the authors retain all their rights. 665 Acknowledgment 667 Funding for the RFC Editor function is currently provided by the 668 Internet Society.