idnits 2.17.1 draft-wenger-avt-topologies-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 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 24, 2006) is 6547 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) -- No information found for draft-wenger-avt-avpf-ext - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Magnus Westerlund 3 INTERNET-DRAFT Ericsson 4 Expires: November 2006 Stephan Wenger 5 Nokia 7 May 24, 2006 9 RTP Topologies 10 draft-wenger-avt-topologies-00.txt> 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 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document disucsses multi-endpoint topologies commonly used in 42 RTP based environments. In particular, centralized topologies 43 commonly employed in the video conferencing industry are mapped to 44 the RTP terminology. 46 TABLE OF CONTENTS 48 1. Introduction....................................................3 49 2. Definitions.....................................................3 50 2.1. Glossary...................................................4 51 2.2. Terminology................................................4 52 2.3. Topologies.................................................5 53 2.3.1. Point to Point........................................5 54 2.3.2. Point to Multi-point using Multicast..................6 55 2.3.3. Point to Multipoint using the RFC 3550 translator.....7 56 2.3.4. Point to Multipoint using the RFC 3550 mixer model....9 57 2.3.5. Point to Multipoint using video switching MCU........11 58 2.3.6. Point to Multipoint using RTCP-terminating MCU.......12 59 2.3.7. Combining Topologies.................................13 60 3. Acknowledgements...............................................13 61 4. References.....................................................14 62 4.1. Normative references......................................14 63 4.2. Informative references....................................14 64 5. Authors' Addresses.............................................14 65 6. List of Changes relative to previous drafts....................15 66 1. Introduction 68 When working on the Codec Control Messages [CCM], we noticed a 69 considerable confusion in the community with respect to terms such as 70 MCU, mixer, and translator. In the process of writing, we became 71 increasingly unsure of our own understanding, and therefore added 72 what became the core of this draft to the CCM draft. Later, it was 73 found that this information has its own value, and was ''outsourced'' 74 from the CCM draft into the present memo. 76 It could be argued that this document clarifies and explains sections 77 of the RTP spec [RFC3550], and is therefore of informational nature. 78 In this case, the present memo may end up as an informational RFC. 80 When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was 81 developed, the main emphasis lied in the efficient support of point- 82 to-point and small multipoint scenarios without centralized 83 multipoint control. However, in practice, many small multipoint 84 conferences operate utilizing devices known as Multipoint Control 85 Units (MCUs). MCUs comprise mixers and translators (in RTP [RFC3550] 86 terminology), but also signalling support. Long standing experience 87 of the conversational video conferencing industry suggests that there 88 is a need for a few additional feedback messages, to efficiently 89 support MCU-based multipoint conferencing. Some of the messages have 90 applications beyond centralized multipoint, and this is indicated in 91 the description of the message. 93 Some of the messages defined here are forward only, in that they do 94 not require an explicit acknowledgement. Other messages require 95 acknowledgement, leading to a two way communication model that could 96 suggest to some to be useful for control purposes. It is not the 97 intention of this memo to open up the use of RTCP to generalized 98 control protocol functionality. All mentioned messages have 99 relatively strict real-time constraints and are of transient nature, 100 which make the use of more traditional control protocol means, such 101 as SIP re-invites, undesirable. Furthermore, all messages are of a 102 very simple format that can be easily processed by an RTP/RTCP 103 sender/receiver. Finally, all messages infer only to the RTP stream 104 they are related to, and not to any other property of a communication 105 system. 107 2. Definitions 108 2.1. Glossary 110 ASM - Asynchronous Multicast 111 AVPF - The Extended RTP Profile for RTCP-based Feedback 112 MCU - Multipoint Control Unit 113 PtM - Point to Multipoint 114 PtP - Point to Point 116 2.2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 Message: 123 Codepoint defined by this specification, of one of the 124 following types: 126 Request: 127 Message that requires Acknowledgement 129 Acknowledgment: 130 Message that answers a Request 132 Command: 133 Message that forces the receiver to an action 135 Indication: 136 Message that reports a situation 138 Notification: 139 See Indication. 141 Note that, with the exception of ''Notification'', this terminology 142 is in alignment with ITU-T Rec. H.245. 144 Decoder Refresh Point: 145 A bit string, packetised in one or more RTP packets, which 146 completely resets the decoder to a known state. Typical 147 examples of Decoder Refresh Points are H.261 Intra pictures 148 and H.264 IDR pictures. However, there are also much more 149 complex decoder refresh points. 151 Typical examples for "hard" decoder refresh points are Intra 152 pictures in H.261, H.263, MPEG 1, MPEG 2, and MPEG-4 part 2, 153 and IDR pictures in H.264. "Gradual" decoder refresh points 154 may also be used. While both "hard" and "gradual" decoder 155 refresh points are acceptable in the scope of this 156 specification, in most cases the user experience will 157 benefit from using a "hard" decoder refresh point. 159 A decoder refresh point also contains all header information 160 above the picture layer (or equivalent, depending on the 161 video compression standard) that is conveyed in-band. In 162 H.264, for example, a decoder refresh point contains 163 parameter set NAL units that generate parameter sets 164 necessary for the decoding of the following slice/data 165 partition NAL units (and that are not conveyed out of band). 166 To the best of the author's knowledge, the term "Decoder 167 Refresh Point" has been formally defined only in H.264; 168 hence we are referring here to this video compression 169 standard. 171 Decoding: 172 The operation of reconstructing the media stream. 174 Rendering: 175 The operation of presenting (parts of) the reconstructed 176 media stream to the user. 177 Stream thinning: 178 The operation of removing some of the packets from a media 179 stream. Stream thinning, preferably, is performed in a 180 media aware fashion implying that the media packets are 181 removed in the order of their relevance to the reproductive 182 quality. However even when employing media-aware stream 183 thinning, most media streams quickly lose quality when 184 subject to increasing levels of thinning. Media-unaware 185 stream thinning leads to even worse quality degradation. 187 2.3. Topologies 189 This subsection defines several basic topologies that are relevant 190 for codec control. The first four relate to the RTP system model 191 utilizing multicast and/or unicast, as envisioned in RFC 3550. The 192 last two topologies, in contrast, describe the widely deployed system 193 model as used in most H.323 video conferences, where both the media 194 streams and the RTCP control traffic terminate at the MCU. More 195 topologies can be constructed by combining any of the models, see 196 Section 2.3.7. 198 2.3.1. Point to Point 200 The Point to Point (PtP) topology (Figure 1) consists of two end- 201 points with unicast capabilities between them. Both RTP and RTCP 202 traffic are conveyed endpoint to endpoint using unicast traffic only 203 (even if this unicast traffic happens to be conveyed over an IP- 204 multicast address). 206 +---+ +---+ 207 | A |<------->| B | 208 +---+ +---+ 210 Figure 1 - Point to Point 212 The main property of this topology is that A sends to B and only B, 213 while B sends to A and only A. This avoids all complexities of 214 handling multiple endpoints and combining the requirements from them. 215 Do note that an endpoint may still use multiple RTP Synchronization 216 Sources (SSRCs) in an RTP session. 218 2.3.2. Point to Multi-point using Multicast 220 +-----+ 221 +---+ / \ +---+ 222 | A |----/ \---| B | 223 +---+ / Multi- \ +---+ 224 + Cast + 225 +---+ \ Network / +---+ 226 | C |----\ /---| D | 227 +---+ \ / +---+ 228 +-----+ 230 Figure 2 - Point to Multipoint using Multicast 232 We define Point to Multipoint (PtM) using multicast topology as a 233 transmission model in which traffic from any participant reaches all 234 the other participants, except for cases such as 235 o packet loss occurs, 236 o a participant participant does not wish to receive the traffic 237 from a certain other participant, and therefore has not 238 subscribed to the IP multicast group in question. 240 In this sense, "traffic" encompasses both RTP and RTCP traffic. The 241 number of participants can be between one and many -- as RTP and RTCP 242 scales to very large multicast groups (the theoretical limit of RTP 243 is approximately two billion participants). 245 This draft is primarily interested in the subset of multicast session 246 where the number of participants in the multicast group allows the 247 participants to use early or immediate feedback as defined in AVPF. 248 This document refers to those groups as as "small multicast groups". 250 2.3.3. Point to Multipoint using the RFC 3550 translator 252 Two main categories of Translators can be distinguished. 254 Transport Translators do not modify the media stream itself, but are 255 concerned with transport parameters. Transport parameters, in the 256 sense of this section, comprise the transport addresses to bridge 257 different domains, and the media packetization to allow other 258 transport protocols to be interconnected to a session (gateways). 260 Media Translators, in contrast, modify the media stream itself. This 261 process is commonly known as transcoding. The modification of the 262 media stream can be as small as removing parts of the stream, and can 263 go all the way to a full transcoding utilizing a different media 264 codec. Media translators are commonly used to connect entities 265 without a common interoperability point. 267 Stand-alone Media Translators are rare. Most commonly, a combination 268 of Transport and Media Translators are used to translate both the 269 media stream and the transport aspects of a stream between two 270 transport domains (or clouds). 272 Both Translator types share common attributes that separates them 273 from mixers. For each media stream that the translator receives, it 274 generates an individual stream in the other domain. However, a 275 translator maintains a complete view of all existing participants 276 between both domains. Therefore, the SSRC space is shared across the 277 two domains. 279 The RTCP translation process can be trivial, for example when 280 Transport translators just need to adjust IP addresses, and can be 281 quite complex in the case of media translators. See section 7.2 of 282 [RFC3550]. 284 +-----+ 285 +---+ / \ +------------+ +---+ 286 | A |<---/ \ | |<---->| B | 287 +---+ / Multi- \ | | +---+ 288 + Cast +->| Translator | 289 +---+ \ Network / | | +---+ 290 | C |<---\ / | |<---->| D | 291 +---+ \ / +------------+ +---+ 292 +-----+ 294 Figure 3 - Point to Multipoint using a Translator 296 Figure 3 depicts an example of a Transport Translator performing at 297 least IP address translation. It allows the (non multicast capable) 298 participants B and D to take part in a multicasted session by having 299 the translator forward their unicast traffic to the multicast 300 addresses in use, and vice versa. It must also forward B's traffic 301 to D and vice versa, to provide each of B and D with a complete view 302 of the session. 304 If B were behind a limited link, the translator may perform media 305 transcoding to allow the traffic received from the other participants 306 to reach B without overloading the link. 308 When in the example depicted in Figure 3 the translator acts only as 309 a Transport Translator, then the RTCP traffic can simply be 310 forwarded, similar to the media traffic. However, when media 311 translation occurs, the translator's task becomes substantially more 312 complex even with respect to the RTCP traffic. In this case, the 313 translator needs to rewrite B's RTCP receiver report, before 314 forwarding them to D and the multicast network. The rewriting is 315 needed as the stream received by B is not the same stream as the 316 other participants receive. For example, the number of packets 317 transmitted to B may be lower than what D receives, due to the 318 different media format. Therefore, if the receiver reports were 319 forwarded without changes, the extended highest sequence number would 320 indicate that B were substantially behind in reception -- while it 321 most likely it would not be. Therefore, the translator must translate 322 that number to a corresponding sequence number for the stream the 323 translator received. Similar arguments can be made for most other 324 fields in the RTCP receiver reports. 326 +---+ +------------+ +---+ 327 | A |<---->| Multipoint |<---->| B | 328 +---+ | Control | +---+ 329 | Unit | 330 +---+ | (MCU) | +---+ 331 | C |<---->| |<---->| D | 332 +---+ +------------+ +---+ 334 Figure 4 - MCU with RTP Translator (relay) with only unicast links 336 A common MCU scenario is the one depicted in Figure 4 - MCU with RTP 337 Translator (relay) with only unicast links. Herein, the MCU connects 338 multiple users of a conference through unicast. This can be 339 implemented using a very simple transport translator, which could be 340 called a relay. The relay forwards all traffic it receives, both RTP 341 and RTCP, to all other participants. In doing so, a multicast network 342 is emulated without relying on a multicast capable network structure. 344 2.3.4. Point to Multipoint using the RFC 3550 mixer model 346 A mixer is a middlebox that aggregates multiple RTP streams that are 347 part of a session, by mixing the media data and generating a new RTP 348 stream. One common application for a mixer is to allow a participant 349 to receive a session with a reduced amount of resources. 351 +-----+ 352 +---+ / \ +-----------+ +---+ 353 | A |<---/ \ | |<---->| B | 354 +---+ / Multi- \ | | +---+ 355 + Cast +->| Mixer | 356 +---+ \ Network / | | +---+ 357 | C |<---\ / | |<---->| D | 358 +---+ \ / +-----------+ +---+ 359 +-----+ 361 Figure 5 - Point to Multipoint using RFC 3550 mixer model 363 A mixer can be viewed as a device terminating the media streams 364 received from other session participants. Using the media data from 365 the received media streams, a mixer generates a media stream that is 366 sent to the session participant. 368 The content that the mixer provides is the mixed aggregate of what 369 the mixer receives from the PtP or PtM links, which are part of the 370 same conference session. 372 The mixer is the content source, as it mixes the content (often in 373 the uncompressed domain) and then encodes it for transmission to a 374 participant. The CC and CSRC fields in the RTP header are used to 375 indicate the contributors of to the newly generated stream. The 376 SSRCs of the to-be-mixed streams on the mixer input appear as the 377 CSRCs at the mixer output. That output stream uses a new SSRC that 378 identifies the Mixer. The CSRC are forwarded between the two domains 379 to allow for loop detection and identification of sources that are 380 part of the global session. 382 The mixer is responsible for generating RTCP packets in accordance 383 with its role. It is a receiver and should therefore send reception 384 reports for the media streams it receives. As a media sender itself 385 it should also generate sender report for those media streams sent. 386 The content of the SRs created by the mixer may or may not take into 387 account the situation on its receiving side. Similarly, the content 388 of RRs created by the mixer may or may not be based on the situation 389 on the mixer's sending side. This is left open to the 390 implementation. As specified in Section 7.3 of RFC 3550, a mixer 391 must not forward RTCP unaltered between the two domains. 393 The mixer depicted in Figure 5 has three domains that needs to be 394 separated; the multicast network, participant B and participant D. 395 The Mixer produces different mixed streams to B and D, as the one to 396 B may contain D and vice versa. However the mixer does only need one 397 SSRC in each domain that is the receiving entity and transmitter of 398 mixed content. 400 In the multicast domain the mixer does not provide a mixed view of 401 the other domains and only forwards media from B and D into the 402 multicast network using B's and D's SSRC. 404 The mixer is responsible for receiving the codec control messages and 405 handles them appropriately. The definition of "appropriate" depends 406 on the message itself and the context. In some cases, the reception 407 of a codec control message may result in the generation and 408 transmission of codec control messages by the mixer to the 409 participants in the other domain. In other cases, a message is 410 handled by the mixer itself and therefore not forwarded to any other 411 domains. 413 It should be noted that this form of mixing technology is not widely 414 deployed. Most multipoint video conferences used today employ one of 415 the models discussed in the next sections. 417 When replacing the multicast network in Figure 5 (to the left of the 418 mixer) with individual unicast links as depicted in Figure 6, the 419 mixer model is very similar to the one discussed in section 2.3.6 420 below. 422 +---+ +------------+ +---+ 423 | A |<---->| Multipoint |<---->| B | 424 +---+ | Control | +---+ 425 | Unit | 426 +---+ | (MCU) | +---+ 427 | C |<---->| |<---->| D | 428 +---+ +------------+ +---+ 430 Figure 6 - RTP Mixer with only unicast links 432 2.3.5. Point to Multipoint using video switching MCU 434 +---+ +------------+ +---+ 435 | A |------| Multipoint |------| B | 436 +---+ | Control | +---+ 437 | Unit | 438 +---+ | (MCU) | +---+ 439 | C |------| |------| D | 440 +---+ +------------+ +---+ 442 Figure 7 - Point to Multipoint using relaying MCU 444 This PtM topology is, today, perhaps the most widely deployed one. 445 It reflects today's lack of wide deployment of IP multicast 446 technologies on IP networks and the Internet, as well as the 447 simplicity of content switching when compared to content mixing. The 448 technology is commonly implemented in what is known as ''Video 449 Switching MCUs''. 451 A video switch MCU forwards to a participant a single media stream, 452 selected from the available streams. The criteria for selection are 453 often based on voice activity in the audio-visual conference, but 454 other conference management mechanisms (like explicit floor control) 455 are known to exist as well. 457 The video switching MCU may also perform media translation to modify 458 the content in bit-rate, encoding, resolution; however it still 459 indicates the original sender of the content through the SSRC. The 460 values of the CC and CSRC fields are retained. 462 RTCP Sender Reports are forwarded for the currently selected sender. 463 All RTCP receiver reports are freely forward between the 464 participants. In addition, the MCU may also originate RTCP control 465 traffic in order to control the session and/or report on status from 466 its viewpoint. 468 The video switching MCU has mostly the attributes of a translator. 469 However its stream selection is a mixing behaviour. This behaviour 470 has some RTP and RTCP issues associated with it. The suppression of 471 all but one media stream results in that most participants see only a 472 subset of the sent media streams at any given time; often a single 473 stream per conference. Therefore, RTCP receiver reports only report 474 on these streams. In consequence, the media senders that are not 475 currently forwarded receive a view of the session that indicates 476 their media streams disappearing somewhere en route. This makes the 477 use of RTCP for congestion control very problematic. To avoid these 478 issues the MCU needs to modify the RTCP RRs. 480 2.3.6. Point to Multipoint using RTCP-terminating MCU 482 +---+ +------------+ +---+ 483 | A |<---->| Multipoint |<---->| B | 484 +---+ | Control | +---+ 485 | Unit | 486 +---+ | (MCU) | +---+ 487 | C |<---->| |<---->| D | 488 +---+ +------------+ +---+ 490 Figure 8 - Point to Multipoint using content modifying MCU 492 In this PtM scenario, each participant runs an RTP point-to-point 493 session between itself and the MCU. The content that the MCU provides 494 to each participant is either: 496 a) A selection of the content received from the other participants, 497 or 499 b) The mixed aggregate of what the MCU receives from the other PtP 500 links, which are part of the same conference session. 502 In case a) the MCU may modify the content in bit-rate, encoding, 503 resolution. No explicit RTP mechanism is used to establish the 504 relationship between the original media sender and the version the 505 MCU sends. In other words, the outgoing session typically uses a 506 different SSRC, and may well use a different PT, even if this 507 different PT happens to be mapped to the same media type. (This is 508 the definition of this topology and distinguishes it from the 509 topologies previously discussed). 511 In case b) the MCU is the content source as it mixes the content and 512 then encodes it for transmission to a participant. The participant's 513 content that is included in the aggregated content is not indicated 514 through any explicit RTP mechanism. For example, regardless of the 515 number of streams that are aggregated, in the MCU generated streams 516 CC is zero and therefore no CSRC fields are present. 518 The MCU is responsible for receiving the codec control messages and 519 handle them appropriately. In some cases, the reception of a codec 520 control message may result in the generation and transmission of 521 codec control messages by the MCU to some or all of the other 522 participants. 524 An MCU may transparently relay some codec control messages and 525 intercept, modify, and (when appropriate) generate codec control 526 messages of its own and transmit them to the media senders. 528 The main feature that sets this topology apart from what RFC 3550 529 describes, is the lack of an explicit RTP level indication of all 530 participants. If one were using the mechanisms available in RTP and 531 RTCP to signal this explicitly, the topology would follow the 532 approach of an RTP mixer. The lack of explicit indication has at 533 least the following potential problems: 535 1) Loop detection cannot be performed on the RTP level. When 536 carelessly connecting two misconfigured MCUs, a loop could be 537 generated. 538 2) There is no information about active media senders available in 539 the RTP packet. As this information is missing, receivers 540 cannot use it. It also deprive the participant's clients 541 information about who are actively sending in a machine usable 542 way. Thus preventing clients from doing indication of currently 543 active speakers in user interfaces, etc. 545 2.3.7. Combining Topologies 547 Topologies can be combined and linked to each other using mixers or 548 translators. Care must however be taken to how the SSRC space is 549 handled, mixers separate the SSRC space into two parts, while 550 translators maintain the space across themselves. Any hybrid, like 551 the video switching MCU, 2.3.5, requires considerable afterthought on 552 how RTCP is dealt with. 554 3. Security Considerations 556 This document does not specify any protocol mechanisms and should not 557 have any security issues 559 4. IANA considerations 561 None 563 5. Acknowledgements 565 The authors would like to thank N.N. 567 6. References 569 6.1. Normative references 571 None. 573 6.2. Informative references 575 [CCM] Wenger, S., Chandra, U., Westerlund, M, Burman, B., ''Codec 576 Control Messages in the Audio-Visual Profile with Feedback 577 (AVPF)'', draft-wenger-avt-avpf-ext-04.txt, Work in 578 Progress, May 2006 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 582 Jacobson, "RTP: A Transport Protocol for Real-Time 583 Applications", STD 64, RFC 3550, July 2003. 584 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J., 585 ''Extended RTP Profile for Real-time Transport Control 586 Protocol (RTCP)-Based Feedback (RTP/AVPF)'', RFC 4585, July 587 2006 589 Any 3GPP document can be downloaded from the 3GPP web server, 590 "http://www.3gpp.org/", see specifications. 592 7. Authors' Addresses 594 Magnus Westerlund 595 Ericsson Research 596 Ericsson AB 597 SE-164 80 Stockholm, SWEDEN 599 Phone: +46 8 7190000 600 EMail: magnus.westerlund@ericsson.com 602 Stephan Wenger 603 Nokia Corporation 604 P.O. Box 100 605 FIN-33721 Tampere 606 FINLAND 608 Phone: +358-50-486-0637 609 EMail: stewe@stewe.org 611 8. List of Changes relative to previous drafts 613 Full Copyright Statement 615 Copyright (C) The Internet Society (2006). 617 This document is subject to the rights, licenses and restrictions 618 contained in BCP 78, and except as set forth therein, the authors 619 retain all their rights. 621 This document and the information contained herein are provided on an 622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 624 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 625 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 626 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 Intellectual Property Statement 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org. 653 Acknowledgment 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society. 658 RFC Editor Considerations 660 The RFC editor is requested to replace all occurrences of XXXX with 661 the RFC number this document receives.