idnits 2.17.1 draft-ietf-xcon-conference-scenarios-03.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 671. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (March 28, 2005) is 6969 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-04 -- Obsolete informational reference (is this intentional?): RFC 2793 (ref. '2') (Obsoleted by RFC 4103) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON R. Even 3 Internet-Draft Polycom 4 Expires: September 26, 2005 N. Ismail 5 Cisco Systems, Inc. 6 March 28, 2005 8 Conferencing Scenarios 9 draft-ietf-xcon-conference-scenarios-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 26, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes multimedia conferencing scenarios. It 45 describes both basic and advance conferencing scenarios involving 46 voice, video, text and interactive text sessions. These conferencing 47 scenarios will help with the definition and evaluation of the 48 protocols being developed in the centralized conferencing XCON 49 working group. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Simple Conferencing scenarios . . . . . . . . . . . . . . . 3 55 2.1 Ad-hoc conference . . . . . . . . . . . . . . . . . . . . 4 56 2.2 Extension of a Point to point calls to a multipoint call . 4 57 2.3 Reserved conference . . . . . . . . . . . . . . . . . . . 4 58 3. Advanced Conferencing scenarios . . . . . . . . . . . . . . 5 59 3.1 Extending a point-to-point call to a multipoint call . . . 5 60 3.2 Lecture mode conferences . . . . . . . . . . . . . . . . . 5 61 3.3 Conference with simple and advanced participants . . . . . 5 62 3.4 A reserved or ad-hoc conference with conference-aware 63 participants. . . . . . . . . . . . . . . . . . . . . . . 6 64 3.5 Advanced conference features . . . . . . . . . . . . . . . 6 65 4. Scenarios for media policy control . . . . . . . . . . . . . 8 66 4.1 Video mixing scenarios . . . . . . . . . . . . . . . . . . 9 67 4.2 Typical video conferencing scenario . . . . . . . . . . . 10 68 4.3 Conference Sidebar scenario . . . . . . . . . . . . . . . 10 69 4.4 Coaching scenario . . . . . . . . . . . . . . . . . . . . 11 70 4.5 Presentation and QA session . . . . . . . . . . . . . . . 11 71 4.6 Presence-enabled ad-hoc conference . . . . . . . . . . . . 12 72 4.7 Group chat text conferencing . . . . . . . . . . . . . . . 12 73 4.8 Interactive text . . . . . . . . . . . . . . . . . . . . . 12 74 4.9 Moderated group chat . . . . . . . . . . . . . . . . . . . 13 75 4.10 Text sidebars . . . . . . . . . . . . . . . . . . . . . 13 76 4.11 Advanced media control features . . . . . . . . . . . . 13 77 5. Security Considerations . . . . . . . . . . . . . . . . . . 13 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 8. Informative References . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . 15 84 1. Introduction 86 This document describes multimedia conferencing scenarios. The 87 development of these conferencing scenarios is intended to help with 88 definition and evaluation of the requirements for the centralized 89 conferencing (XCON) working group. Although this document uses 90 definitions, conventions and architectures described in the SIP 91 Conferencing Framework document[1], these scenarios are not 92 SIP-specific. The document describes basic and advanced conferencing 93 scenarios. The advanced scenarios will assume that the endpoint 94 functionality is based on the future set of XCON protocols that will 95 be needed in order to participate in the conference and take 96 advantage of the conference functionality. However, note that many 97 of these features can be implemented today using an IVR or web 98 interface to control the conferencing application. 100 The entities comprising the conference will be the "focus" that is 101 the center point for signaling and the participants. A special 102 participant is the participant who initiated the conference. The 103 scenarios described are in order to demonstrate different 104 conferencing services. These conferencing services can be offered in 105 a multimedia environment that will benefit from having some support 106 in the endpoints that will enable more robust and easier to use 107 conferencing services. It will be up to the conferencing bridge 108 manufacturers and the service provider to decide what services can be 109 built and which services will be offered to the end users. 111 The scenarios will describe multimedia examples but they are 112 applicable to audio only as well as for audio and video conferences. 114 Multimedia conferences may include any combination of different media 115 types like audio, video, text, interactive text, or presentation 116 graphics. The conference scenarios are similar but the media 117 handling may be dependent on the media type. 119 2. Simple Conferencing scenarios 121 These scenarios enable a basic endpoint without any specific 122 conferencing extensions to create, join and participate in a 123 conference. The endpoint may use out of band signaling to 124 participate in a conference but this is not a mandatory requirement. 125 The focus will have all the functionality it needs in order to supply 126 the service offered to the participants. A typical minimum 127 requirement is that the participant support DTMF tones/signal or 128 provide voice responses to an IVR system. 130 2.1 Ad-hoc conference 132 A user has a service provisioned to him that enables him to start an 133 ad-hoc conference when he calls the focus. When the participant 134 wants to start a conference he calls the conference service. The 135 participant may be identified by different means including request 136 destination, authenticated identity, or an IVR system using DTMF. 137 The conference is created automatically with the predefined 138 functionality. The participant who has such a service notifies the 139 other participants how to call the conference via external means such 140 as instant message or email. The participant may have the 141 functionality of a focus and thus can create ad-hoc conference using 142 his own endpoint functionality. An example of such a conference is 143 an audio conference initiated by one of the participants who has a 144 conference service that enables him to start a conference when he 145 calls a specific URI. The conference may be created by the first 146 person calling this URI or it may be created only after the owner is 147 authenticated using an IVR system. In the latter case, the other 148 participants may get an announcement and are placed on hold if they 149 call the conference before the owner. 151 2.2 Extension of a Point to point calls to a multipoint call 153 This is a simple case. The initiating participant is in a call with 154 one party and wants to add another party to the call. The initiating 155 participant cannot provide the focus functionality on his endpoint 156 nor can the other participant. If neither also supports call 157 transfer, the only way to create this conference is by disconnecting 158 and using the methods described in 2.1. The information about the 159 conference will be conveyed in the point-to-point call. The focus 160 may support dial out, allowing the initiating participant to call the 161 third party. 163 2.3 Reserved conference 165 The reservation for this type of conference is typically done by an 166 out of band mechanism and in advance of the actual conference time. 167 The conference identification, which may be a URI or a phone number 168 with a pin number, is allocated by the reservation system. It is 169 sent to all participants using email, IM, etc. The participants join 170 using the conference identification. The conference identification 171 must be routable enabling the allocation of a focus with free 172 resources at the time when the conference will actually run. The 173 focus can also dial out to the conference participants. The 174 endpoints may not be aware that they are in a conference. The 175 participants may know via announcement from the conference that they 176 are in a conference and who the other participants are. 178 3. Advanced Conferencing scenarios 180 These scenarios will assume endpoints that support at least call 181 transfer service and a way to communicate information on events from 182 the focus to the endpoint. The focus has the ability to discover the 183 capabilities of the participants, to identify if they support call 184 transfer. This section will specify in each scenario the 185 dependencies. An advanced conference can be initiated only by an 186 endpoint that has advanced features, but some endpoints in the 187 conference may have less functionality. 189 3.1 Extending a point-to-point call to a multipoint call 191 The initiating participant is in a point-to-point call and want to 192 add a third participant. The initiating participant can start a 193 multipoint call on a conferencing bridge known to him. The extension 194 can be without consultation, which means that he moves the 195 point-to-point call to the focus and then adds the third party (this 196 can be done in various ways). Alternatively the extension can be 197 done with consultation, which means that he puts his current party on 198 hold, calls the third party and asks him to join the conference, and 199 then transfers all the participants to the conferencing bridge. 201 3.2 Lecture mode conferences 203 This conference scenario enables a conference with a lecturer who 204 presents a topic and can allow questions. The lecturer needs to know 205 who the participants are and to be able to give them the right to 206 speak. The right to speak can be based on floor control or an out of 207 band mechanism. 209 In general, the lecturer will be seen/heard by the conference 210 participants and often will share a presentation or application with 211 the other participants. 213 A participant joining this type of conference can get the identity of 214 the lecturer and often the identities of the audience participants. 216 This type of conference may have multiple media streams. For 217 example, if simultaneous language translation is available, a 218 participant will have the option of selecting the appropriate 219 language audio stream. Multiple video streams could include the 220 speaker's face and a whiteboard/demonstration stream. 222 3.3 Conference with simple and advanced participants 224 A focus can include participants that are a mix of simple and 225 advanced participants. Those participants may be basic participants 226 or the GW function may proxy the advanced functionality between the 227 different protocols and the focus. For example, an IVR system or a 228 web page interface can be used to provide additional functionality. 230 3.4 A reserved or ad-hoc conference with conference-aware participants. 232 The initiating participant will call the focus using, for example, a 233 unique identifier in order to start the conference. The focus may 234 use some authenticating method to qualify the participant. The other 235 participants may call the focus and join the conference. The focus 236 will be able to find the capabilities of the participants. In case 237 of a reserved conference the focus will start the conference at the 238 scheduled time. The participants may join by calling the conference 239 URI or the focus may call them. The conference may have privilege 240 levels associated with a specific conference or participant. The 241 privileges will be for the initiating participant and for a regular 242 participant; the initiating participant may delegate privileges to 243 the other participants. The privileges will allow functionality as 244 defined in the next section. 246 3.5 Advanced conference features 248 The following scenarios can be used in all the advanced conferencing 249 scenarios. In the examples given in this section, when referring to 250 a participant that has a functionality it means a participant with 251 the right privileges. These scenarios may be available in the 252 advanced conferencing scenarios and are common in many conferencing 253 applications. This is not a requirement list, rather some examples 254 of how specific functionality are being used in a conference. 256 Add Participants - A participant may add a new participant to the 257 focus. This can be done, for example, by instructing the focus to 258 call the participant or by the first participant calling the new 259 participant and pointing him to the conference. The participant may 260 delete participants from the focus if he can identify them. 262 Changing Devices/Modes - During the course of a conference, a 263 participant may switch between devices with different capabilities 264 while still remaining part of the conference. For example, a 265 participant may initially join using a mobile phone and then switch 266 to a desk top phone. Or a participant may join with a phone, 267 discover that the conference has video streams available, and switch 268 to a video phone. 270 Changing Media - During the conference a participant may be able to 271 select different media streams than the one he had when he joined the 272 conference. An example is a participant that initially joined the 273 conference as an audio participant. The participant was not able to 274 understand the conversation properly and he learned that there is 275 also an interactive text available, the participant asked to receive 276 also the text stream. The text sidebar may be using RFC 2973 277 interactive text. 279 Authenticate participants - A participant can authenticate other 280 participants who want to join the focus. This can be done implicitly 281 by assigning a password to the conference and letting the focus 282 authenticate the new participants or explicitly by directing the 283 authentication requests to the initiating participant who will 284 authenticate each user. 286 Controlling the presentation of media - During the conference the 287 participant may be able to manage whose media is being sent to each 288 participant. For example, the participant may be able to decide that 289 he wants to be the speaker and all the rest are listeners; he may 290 also specify whose media he wants to receive. The participant may be 291 able to mute a media stream during the conference. 293 Giving privileges - The participant may want, during the conference, 294 to give a privilege to another participant. The assigning of 295 privileges may be implicit when requested or explicit by asking the 296 participant to grant a privilege. 298 Side conferences or sidebars - The participant may want to create a 299 side conference that include some of the participants. When the side 300 conference is done the participants will return to the main 301 conference. A sidebar may have the same functionality as the main 302 conference. There can be some sidebars scenarios. The simple one 303 will be based on capabilities of two participants to have two calls 304 at the same time and they will have a point to point call in parallel 305 to the main conference. This is an end point implementation 306 specific, to decide if to mix both calls streams or to enable the 307 user to switch between them. The sidebar scenario that will use the 308 focus will use the same call he is in and let the focus create the 309 sidebar and compose the relevant sidebar stream mixes. These mixes 310 can include the main conference as an incoming stream to the mix. A 311 way to signal the creation of the sidebar and how to invite 312 participants and control the mixes should be available. For example, 313 participants in an audio sidebar can generally not be heard by the 314 rest of the conference. However, the main conference audio may be 315 mixed in the sidebar, but at a low volume, or in a different channel. 316 For example, a sidebar can have a different media type from the main 317 conference - a video call can have an audio sidebar where the other 318 participants can see the sidebar participants talking but can not 319 hear them; or an audio or video conference may have a text sidebar. 321 Focus information - When a participant joins the focus he is 322 announced to the participants. An announcement may be available when 323 he leaves the focus. The participants may query the focus for its 324 current participants. This presence information can be used by 325 applications. 327 Extending of a conference - Reserved conferences and ad-hoc 328 conferences may have a time limit. The focus will inform the 329 participants when the limit is approaching and may allow the 330 extension of the conference. 332 Adding and removing a media type to the conference - A participant 333 may want to start a data presentation during a conference. He may 334 want to distribute this new media to all the participants. The 335 participant will ask the focus to start the new media channel and to 336 allow him to send data in the new channel. 338 Audio-only participants - In a multimedia conference some of the 339 users who want to join may have no way to send and receive all the 340 media types. Typically they can send and receive audio. Such 341 participants will join the conference as audio-only participants. 342 The general case is that users may send and receive only part of the 343 media streams available in the multi media conference. 345 Passive participants - In a conference some participants may be 346 listeners to all or part of the media streams, but be invisible to 347 all the other participants. 349 Recorders - A recorder can be added to the conference. A recorder 350 can record all streams or a subset of the streams. A recorder is a 351 case of a passive participant. 353 Whisper/Private Message - A participant can send a one way message 354 (text, audio, or even some other media) to another participant that 355 is immediately rendered. This differs from a sidebar in that it is 356 immediate and creates no long-lived session. 358 4. Scenarios for media policy control 360 During a conference media streams may be controlled by authorized 361 users using either a media control protocol or a third party 362 application. This section will describe some typical media control 363 scenarios. The conference can be of any size starting from small 364 conferences (3-5 participants) through medium size of up to 16 365 participants and large conferences. Some of the media control 366 scenarios are typical to specific conference sizes. As a general 367 rule larger conferences scenarios tend to be more centrally managed 368 or structured. 370 The scenarios apply to audio conferences as well as to multimedia 371 conferences. There are some specific information about the mixed 372 video layout and about interactive text discussed bellow. 374 4.1 Video mixing scenarios 376 For video the user selects one of a set of pre-defined video 377 presentations offered by the server. Each video presentation is 378 identified by a textual description as well as an image specifying 379 how the presentation looks like on the screen. In this scenario by 380 choosing a video presentation the user chooses how many video streams 381 (participants) will be viewed at once and the layout of these video 382 streams on the screen. 384 The contents of each sub-window can be defined by a conference policy 385 or controlled by authorized participants. Other aspects like number 386 of different mixes in the conference and a custom mix for each 387 participant, these functionalities are applicable also to audio 388 mixing and are based on server capabilities and authorization. 390 The following are a list of typical video presentations; there are 391 other layouts available today in commercial products: 393 - Single view: This presentation typically shows the video of the 394 loudest speaker 396 - Dual View: This presentation shows two streams. If the streams are 397 to be multiplexed in one image (typical of centralized servers) the 398 multiplexing can be: 400 1. Side by side with no altered aspect ratio and hence blanking of 401 parts of the image might be necessary if the streams are to be 402 combined as one image. 404 2. Side by side windows with altered aspect ratios and hence 405 blanking parts of the image is not necessary. The mixer handles the 406 cropping of the images. 408 3. One above the other windows with no altered aspect ratio 410 4. One above the other windows with altered aspect ratio 412 - Quadrate view: This presentation shows 4 streams. If the streams 413 are to be multiplexed into one image (centralized server) they will 414 be arranged in a 2x2 style. Note that in this style the aspect 415 ratios are maintained. 417 - 9 sub-picture view: This presentation shows 9 streams. If the 418 streams are to be multiplexed in one image they will be arranged in a 419 3x3 style. In the multiplexing case cropping is performed under the 420 discretion of the mixer. 422 - 16 sub-picture view: This presentation shows 16 streams. If the 423 streams are to be multiplexed into one image they will be arranged in 424 a 4x4 style. In this style the aspect ratios are maintained and no 425 cropping or blanking is needed. 427 - 5+1 sub-picture view: This presentation shows 6 streams. If the 428 streams are to be multiplexed into one image then the pictures are 429 laid so that one sub-window occupies 4/9 of the screen while the 430 other five occupy 1/9 of the screen each. 432 4.2 Typical video conferencing scenario 434 In this scenario the audio is typically an n-1 audio mix. Every 435 participant will get a mixed audio of N loudest participants but his 436 own audio will not be part of the received mix. All the participants 437 will see the current speaker and he will see the previous speaker. 438 This mode is typical to small conference. 440 User with correct authorization can exclude one or more users from 441 the audio or video mix. An indication might be displayed to the 442 affected users indicating that they are not being seen/heard. 444 User with correct authorization can manipulate the gain level 445 associated with one or more audio streams in the mix. 447 4.3 Conference Sidebar scenario 449 An authorized user creates a side bar. The user selects whether the 450 sidebar should include the media from the main conference or not and 451 the audio gain level associated with the main conference audio. 453 A user invites participants to the sidebar and upon acceptance they 454 start receiving the sidebar media as specified by the sidebar 455 creator. If the new participant is not a participant of the 456 conference but rather just the sidebar the participant will only 457 receive the sidebar media without the media of the main conference if 458 it was part of the sidebar mix. 460 A user with the right authorization can move another participant into 461 the sidebar with no indication in which case the user will suddenly 462 start receiving the sidebar media. 464 Sidebar participants with the right authorization can select to hear 465 or not hear the main conference audio mixed with the sidebar audio 466 A participant can be a participant to more than one sidebar but can 467 only actively participate in one. 469 A participant can jump back and forth between the main conference and 470 one or more sidebars to actively participate. 472 4.4 Coaching scenario 474 This is a call center or a remote training session where there is a 475 supervisor who can monitor the conference. There are the supervised 476 users that may be the call center operators or the teachers. A 477 participant is the conference may be a supervised user or a 478 "customer". 480 The supervisor will be a hidden participant and will not be part of 481 the participant roster. 483 The supervised users might get an announcement/tone indicating that 484 the supervisor has joined. The other participants do not hear the 485 announcement. 487 The supervisor listens/sees to the session but can only be heard/seen 488 by the supervised user. 490 The supervisor can become a normal participant, in which case the 491 participants will see the supervisor as part of the roster and will 492 start hearing and seeing him. 494 4.5 Presentation and QA session 496 An example is an earning call scenario in which a group of presenters 497 deliver material to a group of people. After the presentation is 498 finished a QA session is opened. 500 The conference is created as a panel and the panel participants are 501 identified. Only their streams will be mixed. 503 After the end of the presentation the session chair changes the 504 conference type to normal and now streams from all users may be 505 mixed. 507 A floor control protocol can be used instead of changing the 508 conference type. The chair can grant the right to speak by adding 509 just the participant whose turn is to ask a question to the 510 conference mix. 512 4.6 Presence-enabled ad-hoc conference 514 A presence-enabled ad-hoc conference, sometimes described as "walkie 515 talkie" service, is a scenario in which a participant sends media to 516 the other participants of the conference after receiving a 517 confirmation of the other participants' availability. For example, a 518 participant presses a talk button, which checks the presence of the 519 participants to see if they are available for communication. If they 520 are, a confirmation tone is played and the participant can then talk, 521 which results in the media being sent to the other participants in 522 the conference. These types of conferences tend to be long lived, 523 hence the need for presence to ensure that the other participants are 524 still available. The ad-hoc nature of the conference means that the 525 participant list can be changed at any time. Floor control can be 526 used to allow other participants to speak, as the conference is 527 usually half-duplex in nature. 529 4.7 Group chat text conferencing 531 Group chat is a common scenario for text messaging in which a 532 participant joins (or enters) a chat room in which text messages from 533 participants are rendered in a single window and attributed to the 534 participant that sent the message. Changes in conference membership 535 are often announced in the text window itself (e.g. "Alice has just 536 entered the room. Bob has just departed."). Note that a real-time 537 transcription/closed captioning service can provide a similar window 538 in which audio media is converted into interactive text. "Nick 539 names" or aliases are often chosen by participants or assigned by the 540 focus and used as handles within the room. 542 4.8 Interactive text 544 Interactive text is using RTP to carry text one character at a time 545 providing real-time interactivity, as described in RFC2793[2]. The 546 interactive text session may be the main conference itself, or it may 547 be used in conjunction with other media types. Interactive text may 548 be used to represent the audio in the conference using some 549 translation services. There can be more than one such stream where 550 each text stream is in a different language. These text streams may 551 be used as subtitles to the audio stream. The translation from to 552 text to speech and back is done by transcoders. Those transcoder 553 have similar functionality to transcoders between different audio or 554 video algorithms. 556 The conference participants should be able to select to receive those 557 text streams with the conference audio or without it. 559 4.9 Moderated group chat 561 A moderated group chat scenario for text messaging is similar to 562 group chat but with all text messages sent to the group being 563 filtered/approved by a moderator. Note that the moderator can be a 564 human or an application. The moderator also often has the ability to 565 remove participants and provide feedback on their submissions (e.g. 566 provide warnings before removal). 568 4.10 Text sidebars 570 Interactive text or instant messaging sidebars are perhaps the most 571 common sidebars in conferences today. Often the text sessions are 572 separate from the conference. However, there are some advantages to 573 having text sessions be a sidebar and as a result a part of the main 574 conference. For example, a conference which is providing anonymity/ 575 aliases to participants can also provide anonymous/alias sidebars. A 576 text sidebar can also benefit from other security/logging/recording 577 services provided by the focus. 579 Another use of a text sidebar is a text-only conversation/discussion 580 between two or more conference participants who at the same time are 581 following the main conference. 583 4.11 Advanced media control features 585 The following features can be used in all the conferencing scenarios. 587 Announcement - The conference moderator may be able to play 588 announcements to all the conference participants. The announcement 589 may be pre-recorded or composed by the moderator before sending them. 590 The announcements may be text, audio or audio visual. An example is 591 a conference with several audio break-out sessions going on. At some 592 point in the time, the moderator wants to record an audio message 593 like "in 5 minutes, everyone please come back to the main meeting" 594 and then play that message to all of the breakout sessions. 596 5. Security Considerations 598 Conferences generally have authorization rules about who may or may 599 not join a conference, what type of media may or may not be used, 600 etc. This information, sometimes called the conference policy, is 601 used by the focus to admit or deny participation in a conference. 602 For the conference policy to be implemented, the focus needs to be 603 able to authenticate potential participants. The methods used will 604 depend on the signaling protocols used by the focus. This can 605 include a challenge/response mechanism, certificates, shared secret, 606 asserted identity, etc. These conference-specific security 607 requirements are discussed further in the XCON requirements and 608 framework documents. 610 6. IANA Considerations 612 There are no IANA considerations associated with this specification. 614 7. Acknowledgements 616 Thanks to Brian Rosen for contributing conferencing scenarios. 618 Thanks to Alan Johnston for going over the document and adding some 619 more scenarios; to Keith Lantz for carefully reading the document. 621 8 Informative References 623 [1] Rosenberg, J., "A Framework for Conferencing with the Session 624 Initiation Protocol", 625 draft-ietf-sipping-conferencing-framework-04 (work in progress), 626 October 2003. 628 [2] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, 629 May 2000. 631 Authors' Addresses 633 Roni Even 634 Polycom 635 94 Derech Em Hamoshavot 636 Petach Tikva 49130 637 Israel 639 EMail: roni.even@polycom.co.il 641 Nermeen Ismail 642 Cisco Systems, Inc. 643 170 West Tasman Drive 644 San Jose 95134 645 CA USA 647 EMail: nismail@cisco.com 649 Intellectual Property Statement 651 The IETF takes no position regarding the validity or scope of any 652 Intellectual Property Rights or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; nor does it represent that it has 656 made any independent effort to identify any such rights. Information 657 on the procedures with respect to rights in RFC documents can be 658 found in BCP 78 and BCP 79. 660 Copies of IPR disclosures made to the IETF Secretariat and any 661 assurances of licenses to be made available, or the result of an 662 attempt made to obtain a general license or permission for the use of 663 such proprietary rights by implementers or users of this 664 specification can be obtained from the IETF on-line IPR repository at 665 http://www.ietf.org/ipr. 667 The IETF invites any interested party to bring to its attention any 668 copyrights, patents or patent applications, or other proprietary 669 rights that may cover technology that may be required to implement 670 this standard. Please address the information to the IETF at 671 ietf-ipr@ietf.org. 673 Disclaimer of Validity 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 Copyright Statement 685 Copyright (C) The Internet Society (2005). This document is subject 686 to the rights, licenses and restrictions contained in BCP 78, and 687 except as set forth therein, the authors retain all their rights. 689 Acknowledgment 691 Funding for the RFC Editor function is currently provided by the 692 Internet Society.