idnits 2.17.1 draft-johansson-avt-rtcp-avpf-non-compound-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 357: '...ound RTCP packet SHALL only be done in...' RFC 2119 keyword, line 359: '...compound packets SHALL NOT be sent unt...' RFC 2119 keyword, line 361: '...eedback messages MAY be sent as non-co...' RFC 2119 keyword, line 363: '...lar RTCP packet, MAY be sent as a non-...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 27, 2007) is 6147 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) == Outdated reference: A later version (-10) exists of draft-ietf-avt-avpf-ccm-07 == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-05 == Outdated reference: A later version (-10) exists of draft-ietf-avt-tfrc-profile-08 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Johansson 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track Ericsson AB 5 Expires: December 29, 2007 June 27, 2007 7 Support for non-compund RTCP in RTCP AVPF profile, opportunities and 8 consequences 9 draft-johansson-avt-rtcp-avpf-non-compound-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo discusses benefits and issues that arise when allowing RTCP 43 packets to be transmitted as non-compound packets, i.e. not follow 44 the rules of RFC 3550. Based on that analysis this memo proposes 45 changes to the rules to allow feedback messages to be sent as non- 46 compound RTCP packets when using the RTP AVPF profile (RFC 4585) 47 under certain conditions. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. RTCP Compound Packets . . . . . . . . . . . . . . . . . . . . 3 59 3. Benefits from non-compound packets . . . . . . . . . . . . . . 4 60 4. Issues with non-compound RTCP packets . . . . . . . . . . . . 6 61 4.1. Middle boxes . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Packet Validation . . . . . . . . . . . . . . . . . . . . 6 63 4.2.1. Old RTCP Receivers . . . . . . . . . . . . . . . . . . 6 64 4.2.2. Weakened Packet Validation . . . . . . . . . . . . . . 7 65 4.2.3. Bandwidth consideration . . . . . . . . . . . . . . . 7 66 4.2.4. Computation of avg_rtcp_size . . . . . . . . . . . . . 7 67 4.3. Header compression . . . . . . . . . . . . . . . . . . . . 7 68 4.4. RTP and RTCP multiplex on the same port . . . . . . . . . 7 69 5. Allowing non-compound RTCP packets . . . . . . . . . . . . . . 8 70 5.1. Usage of non-compound packets in AVPF . . . . . . . . . . 8 71 5.1.1. Verifying the delivery of non-compound packets . . . . 9 72 5.2. SDP Signalling Attribute . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . . . . 13 82 1. Introduction 84 In RTP [RFC3550] it is currently mandatory to always use RTCP 85 compound packets containing at least Sender Reports or Receiver 86 reports, and a SDES packet containing at least the CNAME item. There 87 are good reasons for this as discussed below (see Section 2). 88 However this do result in that the minimal RTCP packets are quite 89 large. The RTP profile AVPF [RFC4585] specifies new RTCP packet 90 types for feedback messages. Some of these feedback messages would 91 benefit from being possible to transmit with minimal delay and AVPF 92 do provide some mechanism to enable this. However for environments 93 with low-bitrate links this still consumes quite large amount of 94 resources and introduce extra delay in the time it takes to 95 completely send the compound packet in the network. There are also 96 other benefits as discussed in Section 3. 98 At least one application disregards the requirement in RTP and uses 99 non-compound packets when transmitting certain events, namely Open 100 Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC]. 101 The OMA POC service is primarily used over cellular links capable of 102 IP transport, such as the GSM GPRS. The use of non-compound RTCP is 103 also specified in [3GPP-MTSI]. 105 The use of non-compound packets is, however, not without issues. 106 This is discussed in Section 4. These issues needs to be considered 107 and is one motivation for this document. 109 In addition this document proposes how AVPF could be updated to allow 110 the transmission of non-compound packets in a way that would not 111 substantially affect the mechanisms that compound packets provide. 112 The connection to AVPF is motivated by the fact that non-compound 113 RTCP is mainly intended for event driven feedback purposes and that 114 the AVPF early and immediate modes makes this possible. 116 2. RTCP Compound Packets 118 Section 6.1 in RFC3550 [RFC3550] specifies that an RTCP packet must 119 be sent in a compound packet consisting of at least two individual 120 packets, first an Sender Report (SR) or Receiver Report (RR), 121 followed by an SDES packet containing at least a CNAME Item for the 122 transmitting source identifier (SSRC). Lets examine what these RTCP 123 packet types are used for. 125 1. The sender and receiver reports (see Section 6.4 of RFC 3550 126 [RFC3550]) provides the RTP session participant with the Sender 127 Source Identifier (SSRC) of all RTCP senders. Having all 128 participants send these packets periodically allows everyone to 129 determine the current number of participants. This information 130 is used in the transmission scheduling algorithm. Thus this is 131 particularly important for new participants so that they quickly 132 can establish a good estimate of the group size. Failure to do 133 this would result in RTCP senders consuming to much bandwidth. 135 2. The sender and receiver reports contain some basic statistics 136 usable for monitoring of the transport and thus enable 137 adaptation. These reports become more useful if sent regularly 138 as the receiver of a report can perform analysis to find trends 139 between the individual reports. When used for media transmission 140 adaptation the information become more useful the more frequently 141 it is received, at least until one report per round-trip time 142 (RTT) is achieved. Therefore there are most cases no reason to 143 not include the sender or receiver report in all RTCP packets. 145 3. The CNAME SDES item (See Section 6.5.1 of RFC 3550 [RFC3550]) 146 exist to allow receivers to determine which media flows that 147 should be synchronized with each other between different RTP 148 sessions carrying different media types. Thus it is important to 149 quickly receive this for each media sender in the session when 150 joining an RTP session. 152 4. Sender Reports (SR) is used in combination with the above SDES 153 CNAME mechanism to establish inter media synchronization. After 154 having determined which media streams should be synchronized 155 using the CNAME field, the receiver uses the Sender Report's NTP 156 and RTP timestamp fields to establish synchronization. 158 Reviewing the above it is obvious that both SR/RR and the CNAME is 159 very important for new session participants to be able to utilize any 160 received media and to avoid flooding the network with RTCP reports. 161 In addition if not sent regular the dynamic nature of the information 162 provided would make it less and less useful. 164 3. Benefits from non-compound packets 166 As mentioned in the introduction most advantages of using non- 167 compound packets exists in cases when the available RTCP bit-rate is 168 limited. This because non-compound packets will be substantially 169 smaller than a compound packet. A compound packet is forced to 170 contain both an RR or an SR and the CNAME SDES item. The RR 171 containing a report block for a single source is 32 bytes, an SR is 172 52 bytes. Both may be larger if they contain report blocks for 173 multiple sources. The SDES packet containing a CNAME item will be 10 174 bytes plus the CNAME string length. Here it is reasonable that the 175 CNAME string is at least 10 bytes to get a decent collision 176 resistance. And if the recommended form of user@host is used, then 177 most strings will be longer than 20 characters. Thus a non-compound 178 packets can become at least 70-80 bytes smaller than the equivalent 179 compound packet. 181 The following benefits exist for the smaller non-compound packets: 183 1. Shorter serialization time, i.e. the time it takes the link to 184 transmit the packet. For slower links this time can be 185 substantial. For example transmitting 120 bytes over an link 186 interface capable of 30 kbps takes 32 milliseconds (ms) assuming 187 uniform transmission rate. 189 2. For links where the packet loss rate grows with the packet size, 190 smaller packets will be less likely to be dropped. Example of 191 such links are radio links. In the cellular world there exist 192 links that are optimized to handle RTP packets with speech and 193 these packets common sizes, the rationale behind this is to be 194 able to increase the capacity and coverage for voice services. 195 Compound RTCP packets commonly are 2-3 times the size of a RTP 196 packet with compressed speech. If the speech packet over such a 197 bearer have a packet loss rate of p, then the RTCP packet will 198 experience 1- (1-p)^x where x is the number of fragments the 199 compound packet will be split on the link layer, i.e. 2 or 3 200 commonly. 202 3. In fixed links there are also benefits with sending feedback in 203 small non-compound RTCP. One such application is those that use 204 RTCP AVPF in early or immediate mode to send frequent event 205 driven feedback . Under these circumstances the use of non- 206 compound RTCP minimizes the risk that the RTCP bandwidth becomes 207 too high during periods of intense adaptation feedback signaling. 209 4. In cases when regular feedback is need, like in the profile under 210 development for TCP friendly rate control (TFRC) for RTP 211 [I-D.ietf-avt-tfrc-profile]. The size of compund RTCP can result 212 in very high bandwidth requirements for the feedback in case the 213 roundtrip time is short. For this particular application non- 214 compound RTCP gives a very substantial improvement. 216 In cases when non-compound packets carry important and time sensitive 217 feedback both shorter serialization time and the lower loss 218 probability are important to enable the best possible functionality. 219 Having a packet loss rate that is much higher for the feedback 220 packets compared to media packets is not advantageous when for 221 example trying to perform media adaptation to handle the e.g. changed 222 performance present at the cell border in cellular system. 224 For high bit-rate applications there is usually no problem of 225 supplying RTCP with sufficient bit-rates. When using AVPF one can 226 use the "trr-int" parameter to restrict the regular reporting 227 interval to approximately once per RTT or less often. As in most 228 cases there are no reasons to provide regular reports with higher 229 density than this. Any additional bandwidth can then be used for 230 feedback messages. The benefits of non-compound packets in this case 231 are limited, but exist, one typical example is video using generic 232 NACK in cases where where the RTT is low. Using non-compound packets 233 would reduce the total amount of bits used for RTCP. This is 234 primarily applicable if the number of non-compound packets is large. 235 This would also result in lower processing delay and less complexity 236 for the feedback packets as they do not need to query the RTCP 237 database to construct the right messages. 239 4. Issues with non-compound RTCP packets 241 This section describes some of the known issues with non-compound 242 RTCP packets 244 4.1. Middle boxes 246 Middle boxes in the network may discard RTCP packets that does not 247 follow the rules outlined in section 6.1 of RFC3550. The effect of 248 this might for instance be that compound RTCP packets makes its way 249 through while the non-compound feedback packets are lost. 251 4.2. Packet Validation 253 A non-compound packet will be discarded by the packet validation code 254 in Appendix A of RFC 3550 [RFC3550]. This has several impacts as 255 described in the following sub sections. 257 4.2.1. Old RTCP Receivers 259 Any RTCP receiver without updated packet validation code will discard 260 the non-compund packets. Thus these receivers will not see the 261 feedback contained in the these non-compound packets. The effect of 262 this depends on the type of feedback message and the role of the 263 receiver. For example this may cause complete function loss in the 264 case of attempting to use a non-compound NACK message (see Section 265 6.2.1 of RFC 4585 [RFC4585]) to non updated media sender in a session 266 using the retransmission scheme defined by RFC 4588 [RFC4588]. 268 This type of discarding would also effect the feedback suppression 269 defined in AVPF. The result would be a partitioning of the receivers 270 within the session between old ones only seeing the compound RTCP 271 feedback messages and the newer ones seeing both. Where the old ones 272 may send feedback messages for events already reported on in non- 273 compound packets. 275 4.2.2. Weakened Packet Validation 277 The packet validation code needs to be rewritten to accept non- 278 compound packets. One potential effect of this change is much weaker 279 validation that received packets actually are RTCP packets, and not 280 packets of some other type being wrongly delivered. Thus some 281 consideration should be done to ensure the best possible validation 282 is available. For example restricting non-compound packets to 283 contain only some specific RTCP packet types, that is preferably 284 signalled on a session basis. 286 4.2.3. Bandwidth consideration 288 The discarding of non-compound RTCP packets would effect the RTCP 289 transmission calculation in the following way; the avg_rtcp_size 290 value would become larger than for RTP receivers that exclude the 291 non-compound in this calculation (assuming that non-compound packets 292 are smaller than compound ones). Therefore these senders would 293 under-utilize the available bit-rate and send with a longer interval 294 than updated receivers. For most sessions this would should not be 295 an issue. However for sessions with a large portion of non-compound 296 packets may result in that the updated receivers time out non-updated 297 senders prematurely. 299 4.2.4. Computation of avg_rtcp_size 301 Long intervals between compund RTCP packets and many non-compound 302 RTCP packets inbetween may lead to a computation of the value 303 avg_rtcp_size that varies greatly over time. 305 4.3. Header compression 307 The classifiers for header compression algorithms such as RoHC 308 [RFC3095] and its profiles must be aware of the fact that, with the 309 proposed non-compound RTCP packets, the first RTCP packet type might 310 differ from 200 or 201. Otherwise they may wrongly classify the 311 packets as something else than RTCP. This may have impact on the 312 compression efficiency. 314 4.4. RTP and RTCP multiplex on the same port 316 In applications that multiplexes RTP and RTCP on the same port, as 317 defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to 318 ensure that the demultiplexing is done properly even though RTCP 319 packets are non-compound. 321 5. Allowing non-compound RTCP packets 323 Based on the above analysis it seems feasible to allow transmission 324 in RTCP under some restrictions. First of all it is important that 325 compound packets are regularly sent to ensure the feedback reporting 326 works. The tracking of session size and number of participants is 327 also important as this ensures that the RTCP bandwidth remain bounded 328 independent of the number of session participants. As the compound 329 packets also are used to establish the synchronization, any newly 330 joining participant in a session would need to receive a compound 331 packet from the media sender. In summary the regular usage of 332 compound packets must be maintained throughout the complete session. 333 Thus non-compound packets should be restricted to be used as extra 334 feedback packets sent in cases when a regular compound packet would 335 not have been sent. 337 If one is going to use non-compound packets it will be important to 338 verify that they actually reaches the session participants. As 339 outlined above in Section 4.1 and Section 4.2 packets may be 340 discarded along the path or in the end-point. The end-points can be 341 resolved by introducing signalling that inform if all session 342 participants are capable of non-compound packets or not. The 343 middlebox issue is more difficult and here one will be required to 344 use heuristics to determine if the non-compound packets are delivered 345 or not. However in many cases the feedback messages sent using non- 346 compound packets will result in either explicit or implicit 347 indications that they have been received. Example of such are the 348 RTP retransmission [RFC4588] that result from a NACK message 349 [RFC4585], the Temporary Maximum Media Bit-rate Notification message 350 resulting from a Temporary Maximum Media Bit-rate Request 351 [I-D.ietf-avt-avpf-ccm], or the presence of a Decoder Refresh Point 352 [I-D.ietf-avt-avpf-ccm] in the video media stream resulting from the 353 Full Intra Request sent. 355 5.1. Usage of non-compound packets in AVPF 357 The usage of non-compound RTCP packet SHALL only be done in RTP 358 sessions operating in AVPF [RFC4585] Early RTCP or Immediate feedback 359 mode. Non-compound packets SHALL NOT be sent until at least one 360 compound packet has been sent. In Immediate feedback mode all 361 feedback messages MAY be sent as non-compound packets. In early RTCP 362 mode a feedback message scheduled for transmission as an Early RTCP 363 packet, i.e. not a Regular RTCP packet, MAY be sent as a non-compound 364 packet. 366 In order to get as much as possible out of of the non-compound RTCP 367 concept, it is necessary to relax the sending rules in RFC 4585 368 [RFC4585] in such a way that it is possible to transmit more that one 369 early feedback RTCP between regular RTCP, presently this is 370 controlled by means of the allow_early flag which has the effect that 371 only one early feedback message is allowed between the regularly 372 scheduled RTCP. The proposed relaxation is reasonable as the size of 373 the non-compound RTCP is expected to be small compared to the regular 374 RTCP. The relaxation however needs to be done in a way that it is 375 both bandwidth conservative and robust/scalable for an increased 376 number of users. A possible outline of an algorithm that does this 377 overrides the allow_early flag to the value TRUE if the bandwith 378 consumed by non-compound RTCP is within some predefined limits, one 379 such limit may be that non-compound RTCP should not be allowed to 380 consume more than a predefiend fraction of the total RTCP bandwidth. 381 Another option may be to use the SDP attribute "trr-int" as limiting 382 factor. 384 The details of the algrithm that handles the relaxation of the 385 sending rules is TBD. 387 5.1.1. Verifying the delivery of non-compound packets 389 A proposed algorithm to detect consistent failure of delivery of non- 390 compound packets needs to be written. The details of this algorithm 391 is application dependent and therefore outside the scope of this 392 document. 394 If the verification fails it is strongly recommended that only 395 compound RTCP according to the rules outlined in RFC3550 is 396 transmitted. 398 5.2. SDP Signalling Attribute 400 We request to define the a "a=ncp" [RFC4566] attribute to indicate if 401 the session participant is capable of supporting non-compound 402 packets. It is a required that a participant that proposes the use 403 of non-compound RTCP itself supports the reception of non-compound 404 RTCP. 406 6. IANA Considerations 408 IANA will be required to register the SDP signalling attribute 409 defined in Section 5.2. 411 7. Security Considerations 413 The security considerations of RTP [RFC3550] and AVPF [RFC4585] will 414 apply also to non-compound packets. The reduction in validation 415 strength for received packets on the RTCP port may result in a higher 416 degree of acceptance of spurious data as real RTCP packets. This 417 vulnerability can mostly be addressed by usage of an security 418 mechanism that provide authentication, e.g. SRTP[RFC3711]. 420 8. Acknowledgements 422 The authors would like to thank all the people who gave feedback on 423 this document. 425 This document also contain some text copied from RFC 4585 [RFC4585] 426 and we take the opportunity to thank the author of said document. 428 9. References 430 9.1. Normative References 432 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 433 Jacobson, "RTP: A Transport Protocol for Real-Time 434 Applications", STD 64, RFC 3550, July 2003. 436 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 437 "Extended RTP Profile for Real-time Transport Control 438 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 439 July 2006. 441 9.2. Informative References 443 [3GPP-MTSI] 444 3GPP, "Specification : 3GPP TS 26.114 (v7.1.0 445 preliminary), http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/ 446 Specs_update_after_SA36/26114-710.zip", March 2007. 448 [I-D.ietf-avt-avpf-ccm] 449 Wenger, S., "Codec Control Messages in the RTP Audio- 450 Visual Profile with Feedback (AVPF)", 451 draft-ietf-avt-avpf-ccm-07 (work in progress), June 2007. 453 [I-D.ietf-avt-rtp-and-rtcp-mux] 454 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 455 Control Packets on a Single Port", 456 draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), 457 May 2007. 459 [I-D.ietf-avt-tfrc-profile] 460 Gharai, L., "RTP with TCP Friendly Rate Control", 461 draft-ietf-avt-tfrc-profile-08 (work in progress), 462 June 2007. 464 [OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over 465 Cellular User Plane, http://www.openmobilealliance.org/ 466 release_program/docs/PoC/V1_0_1-20061128-A/ 467 OMA-TS-PoC-UserPlane-V1_0_1-20061128-A.pdf", 468 November 2006. 470 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 471 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 472 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 473 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 474 Compression (ROHC): Framework and four profiles: RTP, UDP, 475 ESP, and uncompressed", RFC 3095, July 2001. 477 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 478 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 479 RFC 3711, March 2004. 481 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 482 Description Protocol", RFC 4566, July 2006. 484 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 485 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 486 July 2006. 488 Authors' Addresses 490 Ingemar Johansson 491 Ericsson AB 492 Laboratoriegrand 11 493 SE-971 28 Lulea 494 SWEDEN 496 Phone: +46 73 0783289 497 Email: ingemar.s.johansson (AT) ericsson.com 498 Magnus Westerlund 499 Ericsson AB 500 Torshamnsgatan 21-23 501 SE-164 83 Stockholm 502 SWEDEN 504 Phone: +46 8 7190000 505 Email: magnus.westerlund (AT) ericsson.com 507 Full Copyright Statement 509 Copyright (C) The IETF Trust (2007). 511 This document is subject to the rights, licenses and restrictions 512 contained in BCP 78, and except as set forth therein, the authors 513 retain all their rights. 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Intellectual Property 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org. 547 Acknowledgment 549 Funding for the RFC Editor function is provided by the IETF 550 Administrative Support Activity (IASA).