idnits 2.17.1 draft-ietf-xcon-conference-scenarios-00.txt: -(295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 125 has weird spacing: '... system using...' == Line 197 has weird spacing: '...ntation or ap...' == Line 211 has weird spacing: '...include parti...' == Line 345 has weird spacing: '...out the mixed...' == Line 565 has weird spacing: '...amework for C...' -- 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 (November 2003) is 7461 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 (-05) exists of draft-ietf-sipping-conferencing-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '1') Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON R. Even 2 Internet-Draft Polycom 3 Expires: May 1, 2004 N. Ismail 4 Cisco Systems, Inc. 5 November 2003 7 Conferencing Scenarios 8 draft-ietf-xcon-conference-scenarios-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 1, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes SIP conferencing scenarios. It will describe 40 basic and advance conferencing scenarios. These conferencing 41 scenarios will help with definition and evaluation of the 42 requirements for SIP conferencing framework and the protocol 43 associated with the framework. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Simple Conferencing scenarios . . . . . . . . . . . . . . . 3 49 2.1 Ad-hoc conference . . . . . . . . . . . . . . . . . . . . . 3 50 2.2 Extension of a Point to point calls to a multipoint call . . 4 51 2.3 Reserved conference . . . . . . . . . . . . . . . . . . . . 4 52 3. Advanced Conferencing scenarios . . . . . . . . . . . . . . 4 53 3.1 Extending a point-to-point call to a multipoint call . . . . 5 54 3.2 Lecture mode conferences . . . . . . . . . . . . . . . . . . 5 55 3.3 Conference with non-SIP participants . . . . . . . . . . . . 5 56 3.4 A reserved or ad-hoc conference with conference aware 57 participants. . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.5 Advanced conference features . . . . . . . . . . . . . . . . 6 59 4. Scenarios for media policy control . . . . . . . . . . . . . 8 60 4.1 Video mixing scenarios . . . . . . . . . . . . . . . . . . . 8 61 4.2 Typical video conferencing scenario . . . . . . . . . . . . 9 62 4.3 Conference Sidebar scenario . . . . . . . . . . . . . . . . 10 63 4.4 Coaching scenario . . . . . . . . . . . . . . . . . . . . . 10 64 4.5 Presentation and QA session . . . . . . . . . . . . . . . . 11 65 4.6 Presence enabled ad-hoc conference . . . . . . . . . . . . . 11 66 4.7 Group chat text conferencing . . . . . . . . . . . . . . . . 11 67 4.8 Moderated group chat . . . . . . . . . . . . . . . . . . . . 12 68 4.9 Text sidebars . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.10 Advanced media control features . . . . . . . . . . . . . . 12 70 5. Security Considerations . . . . . . . . . . . . . . . . . . 12 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . 14 76 1. Introduction 78 This document describes SIP conferencing scenarios. The development 79 of these conferencing scenarios is intended to help with definition 80 and evaluation of the requirements for the centralized conferencing 81 (XCON) working group. This document uses definitions, conventions 82 and architectures described in the SIP Conferencing Framework 83 document[1]. The document describes basic and advance conferencing 84 scenarios. The advanced scenarios will assume that the endpoint 85 functionality is based on the future set of XCON protocols that will 86 be needed in order to participate in the conference and take 87 advantage of the conference functionality. However, note that many 88 of these features can be implemented today using an IVR or web 89 interface to control the conferencing application. 91 The entities composing the conference will be the "focus" that is the 92 center point for signaling and the participants. A special 93 participant is the participant who initiated the conference. The 94 scenarios described are to demonstrate different conferencing 95 services that can be offered in the SIP environment that will benefit 96 from having some support in the UAs that will enable more robust and 97 easier to use conferencing services. It will be up to the 98 conferencing bridge manufacturers and the service provider to decide 99 what services can be built and which services will be offered to the 100 end users. 102 The scenarios will describe multimedia examples but they are 103 applicable to audio only as well as for audio and video conferences. 105 2. Simple Conferencing scenarios 107 These scenarios will assume a UA that support basic SIP functionality 108 as described in RFC3261[2] and RFC3264 [3] . The reason for these 109 scenarios is to enable a basic UA without any specific conferencing 110 extensions to create, join and participate in a conference. The UA 111 may use an out of band signaling to participate in a conference but 112 this is not a mandatory requirement. The focus will have all the 113 functionality it needs in order to supply the service offered to the 114 participants. A typical minimum requirement is that the participant 115 support DTMF tones/signal or provide voice responses to an IVR 116 system.. 118 2.1 Ad-hoc conference 120 A user has a service provisioned to him that enables him to start an 121 ad-hoc conference when he calls the focus. When the participant 122 wants to start a conference he calls the conference service. The 123 participant may be identified by different means including the 124 Request-URI or To header fields, the Contact or From header fields or 125 an IVR system using DTMF. The conference is created automatically 126 with the predefined functionality. The participant who has such a 127 service notifies the other participants how to call the conference 128 via external means such as instant message or email. The participant 129 may have the functionality of a focus and thus can create ad-hoc 130 conference using his own UA functionality. An example of such a 131 conference is an audio conference initiated by one of the 132 participants who has a conference service that enables him to start a 133 conference when he calls a specific URI. The conference may be 134 created by the first person calling this URI or it may be created 135 only after the owner is authenticated using an IVR system, the other 136 participants may get an announcement and are placed on hold if they 137 call the conference before the owner. 139 2.2 Extension of a Point to point calls to a multipoint call 141 This is a simple case. The initiating participant is in a call with 142 one party and wants to add another party to the call. The initiating 143 participant cannot provide the focus functioality on his UA nor can 144 the other participant. If neither also support call transfer, the 145 only way to create this conference is by disconnecting and using the 146 methods desribed in 2.1. The information about the conference will 147 be conveyed in the point-to-point call. The focus may support dial 148 out allowing the initiating participant to call the third party. 150 2.3 Reserved conference 152 The reservation for this type of conference is typically done by out 153 of band mechanism and in advance of the actual conference time. The 154 conference identification, which may may be a URI or a phone number 155 with a pin number, is allocated by the reservation system. It is 156 sent to all participants using email, IM, etc. The participants join 157 using the conference identification. The conference identification 158 must be routable enabling the allocation of a focus with free 159 resources at the time when the conference will actually run. The 160 focus can also dial out to the conference participants. The 161 endpoints may not be aware that they are in a conference. The 162 participants may know via announcement from the conference that they 163 are in a conference and who are the other participants 165 3. Advanced Conferencing scenarios 167 These scenarios will assume endpoints that support at least call 168 transfer service and a way to communicate information on events from 169 the focus to the UA. The focus has the ability to discover the 170 capabilities of the participants, to identify if they support the 171 call transfer. This section will specify in each scenario the 172 dependencies. An advance conference can be initiated by a UA that 173 has advanced features but some UAs in the conference may have lesser 174 functionality. 176 3.1 Extending a point-to-point call to a multipoint call 178 The initiating participant is in a point-to-point call and want to 179 add a third participant. The initiating participant can start a 180 multipoint call on a conferencing bridge known to him. The extension 181 can be without consultation, which means that he moves the 182 point-to-point call to the focus and then adds the third party (this 183 can be done in various ways). The extension can be done with 184 consultation, which means that he puts his current party on hold 185 calls, the third party and asks him to join the conference and then 186 transfers all the participants to the conferencing bridge. 188 3.2 Lecture mode conferences 190 This conference scenario enables a conference with a lecturer that 191 present a topic and can allow questions. The lecturer needs to know 192 who are the participants and to be able to give them the right to 193 speak. The right to speak can be based on floor control but can also 194 be based on out of band mechanism. 196 In general, the lecturer will be seen/heard by the conference 197 participants and often will share a presentation or application with 198 the other participants. 200 A participant joining this type of conference can get the identity of 201 the lecturer and often the identities of the audience participants. 203 This type of conference may have multiple media streams. For 204 example, if simultaneous language translation is available, a 205 participant will have the option of selecting the appropriate 206 language audio stream. Multiple video streams could include the 207 speaker���s face and a whiteboard/demonstration stream. 209 3.3 Conference with non-SIP participants 211 A focus can include participants that are not SIP UAs that are 212 joining the focus via a gateway function. Those participants may be 213 basic participants or the GW function will proxy the advanced 214 functionality between the different protocols and the SIP focus. 215 For example, an IVR system or a web page interface can be used to 216 provide additional functionality. 218 3.4 A reserved or ad-hoc conference with conference aware participants. 220 The initiating participant will call the focus using for example a 221 unique identifier in order to start the conference. The focus may 222 use some authenticating method to qualify the participant. The other 223 participants may call the focus and join the conference. The focus 224 will be able to find the capabilities of the participants. In case 225 of a reserved conference the focus will start the conference at the 226 scheduled time. The participants may join by call the conference URI 227 or the focus may call them. The conference may have privilege levels 228 associated with a specific conference or participant. The privileges 229 will be for the initiating participant and for a regular participant; 230 the initiating participant may delegate privileges to the other 231 participants. The privileges will allow functionality as defined in 232 the next section. 234 3.5 Advanced conference features 236 The following scenarios can be used in all the advance conferencing 237 scenarios. In the examples given in this section, when referring to 238 a participant that has a functionality it means a participant with 239 the right privileges. These scenarios may be available in the 240 advanced conferencing scenarios and are common in many conferencing 241 applications. These are not a requirement list but some examples of 242 how specific functionality is being used in a conference. 244 Add Participants - A participant may add a new participant to the 245 focus. This can be done, for example, by instructing the focus to 246 call the participant or by the participant calling the participant 247 and pointing him to the conference. The participant may delete 248 participants from the focus if he can identify them. 250 Changing Devices/Modes ��� During the course of a conference, a 251 participant may switch between devices with different capabilities 252 while still remaining part of the conference. For example, a 253 participant may initially join using a mobile phone then switch to a 254 desk top phone. Or a participant may join with a phone, discover 255 that the conference has video streams available, and switch to a 256 video phone. 258 Authenticate participants - A participant can authenticate 259 participants that want to join the focus. This can be done 260 implicitly by assigning a password to the conference and letting the 261 focus authenticate the new participants or explicitly by directing 262 the authentication requests to the initiating participant who will 263 authenticate each user. 265 Controlling the presentation of media - during the conference the 266 participant may be able to manage whose media is being sent to each 267 participant. For example the participant may be able to decide that 268 he wants to be the speaker and all the rest are listeners he may also 269 specify whose media he wants to receive. The participant may be able 270 to mute a media stream during the conference. 272 Giving privileges - the participant may want, during the conference, 273 to give a privilege to another participant. The assigning of 274 privileges may be implicit when requested or explicit by asking the 275 participant to grant a privilege. 277 Side conferences or sidebars - the participant may want to create a 278 side conference that include some of the participants and when the 279 side conference is done the participants will return to the main 280 conference. A side bar may have the same functionality as the main 281 conference. There can be some sidebars scenarios. The simple one 282 will be based on capabilities of two participants to have two calls 283 at the same time and they will have a point to point call in parallel 284 to the main conference, it is an end point implementation to decide 285 if to mix both calls streams or to enable the user to switch between 286 them. The sidebar scenario that will use the focus will use the same 287 call he is in and let the focus create the sidebar and compose the 288 relevant sidebar stream mixes. These mixes can include the main 289 conference as an incoming stream to the mix. The way to signal the 290 creation of the sidebar and how to invite participants and control 291 the mixes should be available. For example, participants in an audio 292 sidebar can generally not be heard by the rest of the conference. 293 However, the main conference audio may be mixed in the sidebar, but 294 at a low volume, or in a different channel. A sidebar can be a 295 different media type from the main conference ��� a video call can 296 have an audio sidebar where the other participants can see the 297 sidebar participants talking but can not hear them. Or an audio or 298 video conference may have a text sidebar. 300 Focus information - When a participant joins the focus he is 301 announced to the participants. An announcement may be available when 302 he leaves the focus. The participants may query the focus for its 303 current participants. This presence information can be used by 304 applications. 306 Extending of a conference - Reserved conferences and ad-hoc 307 conferences may have a time limit. The focus will inform the 308 participants when the limit is close and may allow the extension of 309 the conference. 311 Adding and removing a media type to the conference - a participant 312 may want to start a power point presentation during a conference. He 313 may want to distribute this new media to all the participants. The 314 participant will request from the focus to start the new media 315 channel and to allow him to send data in the new channel. 317 Audio only participants - In a multimedia conference some of the 318 users who wants to join has no way to send and receive all the media. 319 Typically they can send and receive audio. Such participants will 320 join the conference as audio only participants. The general case is 321 that users may send and receive only part of the media streams 322 available in the multi media conference. 324 Passive participants - In a conference some participants may be 325 listeners to all or part of the media streams. They may be invisible 326 to all the other participants. 328 Recorders - A recorder can be added to the conference. A recorder 329 can record all streams or a subset of the streams. A recorder is a 330 case of a passive participant. 332 4. Scenarios for media policy control 334 On going conferences media streams may be controlled by authorized 335 users using either a media control protocol or a third party 336 application. This section will describe some typical media control 337 scenarios. The conference can be of any size starting from small 338 conferences (3-5 participants) through medium size of up to 16 339 participants and large conferences. Some of the media control 340 scenarios are typical to specific conference size. As a general rule 341 larger conferences scenarios tend to be more centrally managed or 342 structured. 344 The scenarios apply to audio conferences as well as to multimedia 345 conferences. There are some specific information about the mixed 346 video layout discussed bellow. 348 4.1 Video mixing scenarios 350 For video the user selects one of a set of pre-defined video 351 presentations offered by the server. Each video presentation is 352 identified by a textual description as well as an image specifying 353 how the presentation looks like on the screen. In this scenario by 354 choosing a video presentation the user chooses how many video streams 355 (participants) will be viewed at once and the layout of these video 356 streams on the screen. 358 The contents of each sub-window can be defined by a conference policy 359 or controlled by authorized participants. In other aspects like 360 number of different mixes in the conference and a custom mix for each 361 user, these functionality are similar to audio mixing and are based 362 on server capabilities and authorization. 364 Note that for non-centralized mixing if the endpoint mixer does not 365 support the media presentation of the conference, the participant can 366 get the default media presentation offered by the endpoint mixer. 368 The following are a list of typical video presentations; there are 369 other layouts available today in commercial products: 371 - Single view: This presentation typically shows the video of the 372 loudest speaker 374 - Dual View: This presentation shows two streams. If the streams are 375 to be multiplexed in one image (typical of centralized servers) the 376 multiplexing can be: 378 1. Side by side with no altered aspect ratio and hence blanking of 379 parts of the image might be necessary if the streams are to be 380 combined as one image. 382 2. Side by side windows with altered aspect ratios and hence 383 blanking parts of the image is not necessary. The mixer handles the 384 cropping of the images. 386 3. One above the other windows with no altered aspect ratio 388 4. One above the other windows with altered aspect ratio 390 - Quadrate view: This presentation shows 4 streams. If the streams 391 are to be multiplexed into one image (centralized server) they will 392 be arranged in a 2x2 style. Note that in this style the aspect 393 ratios are maintained. 395 - 9 sub-picture view: This presentation shows 9 streams. If the 396 streams are to be multiplexed in one image they will be arranged in a 397 3x3 style. In the multiplexing case cropping is performed under the 398 discretion of the mixer. 400 - 16 sub-picture view: This presentation shows 16 streams. If the 401 streams are to be multiplexed into one image they will be arranged in 402 a 4x4 style. In this style the aspect ratios are maintained and no 403 cropping or blanking is needed. 405 - 5+1 sub-picture view: This presentation shows 6 streams. If the 406 streams are to be multiplexed into one image then the pictures are 407 laid so that one sub-window occupies four ninth of the screen while 408 the other five occupy a ninth of the screen each. 410 4.2 Typical video conferencing scenario 412 In this scenario the audio is typically an n-1 audio mixing. Every 413 participant will get a mixed audio of N loudest participants but his 414 own audio will not be part of the received mix. All the participants 415 will see the current speaker and he will see the previous speaker. 416 This mode is typical to small conference. 418 User with correct authorization can exclude one or more users from 419 the audio or video mix. An indication might be displayed to the 420 affected users indicating that they are not being seen/heard. 422 User with correct authorization can manipulate the gain level 423 associated with one or more audio streams in the mix. 425 4.3 Conference Sidebar scenario 427 An authorized user creates a side bar. The user selects whether the 428 sidebar should include the media from the main conference or not and 429 the audio gain level associated with the main conference audio. 431 User invites participants to the sidebar and upon acceptance they 432 start receiving the sidebar media as specified by the sidebar 433 creator. If the new participant is not a participant of the 434 conference but rather just the sidebar the participant will only 435 receive the sidebar media without the media of the main conference 436 being mixed. 438 User with the right authorization can move another participant into 439 the sidebar with no indication in which case the user will suddenly 440 start receiving the sidebar media. 442 Sidebar participants with the right authorization can select to hear 443 or not hear the main conference audio mixed with the sidebar audio 445 A participant can be a participant to more than one sidebar but can 446 only actively participate in one. 448 A participant can jump back and forth between the main conference and 449 one or more sidebars to actively participate. 451 4.4 Coaching scenario 453 This is a call center or a remote training session where there is a 454 supervisor that can monitor. There are the supervised users that may 455 be the call center operators or the teachers 457 The supervisor will be a hidden participant and will not be part of 458 the participant roster. 460 The supervised users might get an announcement/tone indicating that 461 the supervisor has joined. The other participants do not hear the 462 announcement. 464 Supervisor listens/sees to the session but can only be heard/seen by 465 the supervised user. 467 Supervisor can become a normal participant in which case the 468 participants will see the supervisor as part of the roster and will 469 start hearing and seeing him. 471 4.5 Presentation and QA session 473 An example is a panel earning call scenario in which a group of 474 presenters deliver material to a group of people. After the 475 presentation is finished a QA session is opened. 477 The conference is created as a panel and the panel participants are 478 identified. Only their streams will be mixed. 480 After the end of the presentation the session chair changes the 481 conference type to normal and now streams from all users may be 482 mixed. 484 A floor control protocol can be used instead of changing the 485 conference type. The chair can grant the right to speak by adding 486 just the participant whose turn is to ask a question to the 487 conference mix. 489 4.6 Presence enabled ad-hoc conference 491 A presence enabled ad-hoc conference, sometimes described as Push To 492 Talk (PTT) is a scenario in which a participant sends media to the 493 other participants of the conference after receiving a confirmation 494 of the other participants availability. For example, as implemented 495 in cell phones, a participant presses a talk button which checks the 496 presence of the participants to see if they are available for 497 communication. If they are, a confirmation tone is played and the 498 participant can then talk, which results in the media being sent to 499 the other participants in the conference. These types of conferences 500 tend to be long lived, hence the need for presence to ensure that the 501 other participants are still available. The ad-hoc nature of the 502 conference means that the participant list can be changed at any 503 time. 505 4.7 Group chat text conferencing 507 Group chat is a common scenario for text messaging in which a 508 participant joins (or enters) a chat room in which text messages from 509 participants are rendered in a single window and attributed to the 510 participant that sent the message. Changes in conference membership 511 are often announced in the text window itself (e.g. "Alice has just 512 entered the room. Bob has just departed.") Note that a real-time 513 transcription/closed captioning service can provide a similar window 514 in which audio media is converted to text. 516 4.8 Moderated group chat 518 A moderated group chat scenario for text messaging is similar to 519 group chat but with all text messages sent to the group being 520 filtered/approved by a moderator. Note that the moderator can be a 521 human or an application. The moderator also often has the ability to 522 remove participants and provide feedback on their submissions (e.g. 523 provide warnings before removal). 525 4.9 Text sidebars 527 Text or instant messaging sidebars are perhaps the most common 528 sidebars in conferences today. Often the text sessions are separate 529 from the conference. However, there are some advantages to having 530 text sessions be a sidebar and as a result a part of the main 531 conference. For example, a conference which is providing anonymity/ 532 aliases to participants can also provide anonymous/alias sidebars. A 533 text sidebar can also benefit from other security/logging/recording 534 services provided by the focus. 536 4.10 Advanced media control features 538 The following features can be used in all the conferenceing 539 scenarios. 541 Announcement - The conference moderator may be able to play 542 announcments to all the conference participants. The announcement 543 may be pre-recorded or composed by the moderator before sending them. 544 The annoucments may be text, audio or audio visual. An example is a 545 conference with several audio break out sessions going on. At some 546 point in the time, the moderator wants to record an audio message 547 like "in 5 minutes, everyone please come back to the main meeting" 548 and then play that message to all of the breakout sessions. 550 5. Security Considerations 552 No specific security considerations for this draft. Security 553 consideration will be available in the relevant drafts that will 554 compose the suggested solution 556 6. Acknowledgements 558 Thanks to Brian Rosen for contributing conferencing scenarios. 560 Thanks to Alan Johnston for going over the document and adding some 561 more scenarios. 563 References 565 [1] Rosenberg, J., "A Framework for Conferencing with the Session 566 Initiation Protocol", draft- 567 ietf-sipping-conferencing-framework-01 (work in progress), 568 October 2003. 570 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 571 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 572 Session Initiation Protocol", RFC 3261, June 2002. 574 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 575 Session Description Protocol (SDP)", RFC 3264, June 2002. 577 Authors' Addresses 579 Roni Even 580 Polycom 581 94 Derech Em Hamoshavot 582 Petach Tikva 49130 583 Israel 585 EMail: roni.even@polycom.co.il 587 Nermeen Ismail 588 Cisco Systems, Inc. 589 170 West Tasman Drive 590 San Jose 95134 591 CA USA 593 EMail: nismail@cisco.com 595 Intellectual Property Statement 597 The IETF takes no position regarding the validity or scope of any 598 intellectual property or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; neither does it represent that it 602 has made any effort to identify any such rights. Information on the 603 IETF's procedures with respect to rights in standards-track and 604 standards-related documentation can be found in BCP-11. Copies of 605 claims of rights made available for publication and any assurances of 606 licenses to be made available, or the result of an attempt made to 607 obtain a general license or permission for the use of such 608 proprietary rights by implementors or users of this specification can 609 be obtained from the IETF Secretariat. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights which may cover technology that may be required to practice 614 this standard. Please address the information to the IETF Executive 615 Director. 617 Full Copyright Statement 619 Copyright (C) The Internet Society (2003). All Rights Reserved. 621 This document and translations of it may be copied and furnished to 622 others, and derivative works that comment on or otherwise explain it 623 or assist in its implementation may be prepared, copied, published 624 and distributed, in whole or in part, without restriction of any 625 kind, provided that the above copyright notice and this paragraph are 626 included on all such copies and derivative works. However, this 627 document itself may not be modified in any way, such as by removing 628 the copyright notice or references to the Internet Society or other 629 Internet organizations, except as needed for the purpose of 630 developing Internet standards in which case the procedures for 631 copyrights defined in the Internet Standards process must be 632 followed, or as required to translate it into languages other than 633 English. 635 The limited permissions granted above are perpetual and will not be 636 revoked by the Internet Society or its successors or assignees. 638 This document and the information contained herein is provided on an 639 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 640 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 641 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 642 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 643 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Acknowledgement 647 Funding for the RFC Editor function is currently provided by the 648 Internet Society.