doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4597.txt b/doc/rfc/rfc4597.txt
new file mode 100644
index 0000000..8c6ae4c
--- /dev/null
+++ b/doc/rfc/rfc4597.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                            R. Even
+Request for Comments: 4597                                       Polycom
+Category: Informational                                        N. Ismail
+                                                     Cisco Systems, Inc.
+                                                               July 2006
+
+
+                         Conferencing Scenarios
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes multimedia conferencing scenarios.  It
+   describes both basic and advanced conferencing scenarios involving
+   voice, video, text, and interactive text sessions.  These scenarios
+   will help with the definition and evaluation of the protocols being
+   developed in the centralized conferencing XCON working group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Even & Ismail                Informational                      [Page 1]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Basic Conferencing Scenarios ....................................3
+      2.1. Ad Hoc Conferences .........................................4
+      2.2. Extension of a Point-to-Point Call to a Multipoint Call ....4
+      2.3. Reserved Conferences .......................................4
+   3. Advanced Conferencing Scenarios .................................5
+      3.1. Extending a Point-to-Point Call to a Multipoint Call .......5
+      3.2. Lecture Mode Conferences ...................................5
+      3.3. Conference with Conference-Aware and Unaware Participants ..6
+      3.4. A Reserved or Ad Hoc Conference with
+           Conference-Aware Participants ..............................6
+      3.5. Advanced Conference Features ...............................6
+   4. Scenarios for Media Policy Control ..............................9
+      4.1. Video Mixing Scenarios ....................................10
+      4.2. Typical Video Conferencing Scenario .......................11
+      4.3. Conference Sidebar Scenario ...............................11
+      4.4. Coaching Scenario .........................................12
+      4.5. Presentation and Q & A Session ............................12
+      4.6. Presence-Enabled Ad Hoc Conference ........................13
+      4.7. Group Chat Text Conferencing ..............................13
+      4.8. Interactive Text ..........................................13
+      4.9. Moderated Group Chat ......................................14
+      4.10. Text Sidebars ............................................14
+      4.11. Conference Announcements .................................14
+   5. Security Considerations ........................................14
+   6. Acknowledgements ...............................................15
+   7. Informative References .........................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Even & Ismail                Informational                      [Page 2]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+1.  Introduction
+
+   This document describes multimedia conferencing scenarios.  The
+   development of these scenarios is intended to help with the
+   definition and evaluation of the requirements for the centralized
+   conferencing (XCON) working group.  Although this document uses some
+   definitions and conventions described in the SIP Conferencing
+   Framework document [1], these scenarios are not specific to SIP.  The
+   document describes basic and advanced conferencing scenarios.  The
+   advanced scenarios assume that the user agents support the set of
+   XCON protocols, identified in the Framework and Data Model for
+   Centralized Conferencing [3], in order to take advantage of the
+   conference functionality.  However, note that many of these features
+   can be implemented today by using an interactive voice response (IVR)
+   or web interface to control the conferencing application.
+
+   The entities comprising the Conferencing System are the conference
+   that is the center point for signaling and the participants.  The
+   participant who initiated the conference is called the initiating
+   participant.
+
+   The scenarios described here demonstrate different conferencing
+   services.  These services can be offered in a multimedia environment
+   that benefits from having some support in the user agents that enable
+   more robust and easier-to-use conferencing services.  It is up to the
+   conferencing system manufacturers and the conferencing service
+   provider to decide what services can be built and which services are
+   offered to the end users.
+
+   The scenarios describe multimedia examples, but they are applicable
+   to audio only as well as to audio and video conferences.
+
+   Multimedia conferences may include any combination of different media
+   types such as audio, video, text, interactive text, or presentation
+   graphics.  The conference scenarios are similar, but the media
+   handling may be dependent on the media type.
+
+2.  Basic Conferencing Scenarios
+
+   These scenarios enable a conference-unaware participant to create,
+   join, and participate in a conference.  The participant may use out-
+   of-band signaling to participate in a conference, but this is not
+   mandatory.  The Conferencing System has all the functionality it
+   needs in order to supply the service offered to the participants.
+   Typical minimum requirements are that the participant support dual-
+   tone multi-frequency (DTMF) tones/signal or provide voice responses
+   to an IVR system.
+
+
+
+
+Even & Ismail                Informational                      [Page 3]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+2.1.  Ad Hoc Conferences
+
+   A participant has a service provisioned to him that enables him to
+   start an ad hoc conference when he calls the Conferencing System.
+   When the participant wants to start a conference, he calls the
+   conference service.  The participant may be identified by different
+   means, including request destination, authenticated identity, or an
+   IVR system using DTMF.  The conference is created automatically with
+   the predefined functionality.  The participant who has such a service
+   notifies the other participants how to call the conference via
+   external means such as instant message or email.
+
+   The participant may have Conferencing System functionality and thus
+   can create an ad hoc conference using his own user agent.  An example
+   of such a conference is an audio conference initiated by a
+   participant who has a conference service that enables him to start a
+   conference when he calls a specific URI.  The conference may be
+   created by the first person calling this URI, or it may be created
+   only after the owner is authenticated using an IVR system.  In the
+   latter case, the other participants may get an announcement and are
+   placed on hold if they call the conference before the owner.
+
+2.2.  Extension of a Point-to-Point Call to a Multipoint Call
+
+   This is a basic case.  The initiating participant (PA) is in a
+   point-to-point call with another participant (PB).  PA wants to add a
+   third participant (PC) to the call.  PA cannot provide the
+   Conferencing System functionality on his user agent nor can the other
+   participant PB.  PA and PB do not support call transfer.  PA has a
+   conferencing service that uses the methods described in 2.1.  PA
+   conveys the conference information to PB in the point-to-point call.
+   Both participants disconnect and call the Conferencing System.  The
+   Conferencing System may support dial-out (for example, via DTMF),
+   allowing the initiating participant PA to call the third party PC
+   through the Conferencing System.
+
+2.3.  Reserved Conferences
+
+   The reservation for this type of conference is typically done by an
+   out-of-band mechanism in advance of the actual conference time.  The
+   conference identification, which may be a URI or a phone number with
+   a pin number, is allocated by the reservation system.  It is sent to
+   all participants through email, IM, etc.  The participants join by
+   using the conference identification.  The conference identification
+   must be routable, enabling the allocation of a conference with free
+   resources at the time when the conference actually runs.  The
+   Conferencing System can also dial out to the conference participants.
+   The participants may not be informed that they are in a conference,
+
+
+
+Even & Ismail                Informational                      [Page 4]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   since their User Agent is not conference aware.  The participants may
+   know, via announcement from the Conferencing System, that they are in
+   a conference and who the other participants are.
+
+3.  Advanced Conferencing Scenarios
+
+   These scenarios assume user agents that support at least call
+   transfer service and a way to communicate information on events from
+   the Conferencing System to the user agent.  The Conferencing System
+   may have the ability to discover the capabilities of the
+   participants, for example, whether they support call transfer.  This
+   section specifies the dependencies in each scenario.  An advanced
+   conference can be initiated only by a user agent that has advanced
+   features, but some user agents in the conference may have less
+   functionality.
+
+3.1.  Extending a Point-to-Point Call to a Multipoint Call
+
+   The initiating participant PA is in a point-to-point call and wants
+   to add a third participant.  PA can start a multipoint call on a
+   conferencing bridge known to him.  The extension can be without
+   consultation, which means that PA moves the point-to-point call to
+   the Conferencing System and then adds the third party (this can be
+   done in various ways).  Alternatively the extension can be done with
+   consultation, which means that PA puts his current party on hold,
+   calls the third party, asks him to join the conference, and then
+   transfers all the participants to the Conferencing System.
+
+3.2.  Lecture Mode Conferences
+
+   This conference scenario enables a conference with a lecturer who
+   presents a topic and can allow questions.  The lecturer needs to know
+   who the participants are and needs to be able to give them the right
+   to speak.  The right to speak can be based on floor control or an
+   out-of-band mechanism.
+
+   In general, the lecturer is seen/heard by the conference participants
+   and often shares a presentation or application with the other
+   participants.
+
+   A participant joining this type of conference can get the identity of
+   the lecturer and often the identities of the audience participants.
+
+   This type of conference may have multiple media streams.  For
+   example, if simultaneous language translation is available, a
+   participant has the option of selecting the appropriate language
+   audio stream.  Multiple video streams could include the speaker's
+   face and a whiteboard/demonstration stream.
+
+
+
+Even & Ismail                Informational                      [Page 5]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+3.3.  Conference with Conference-Aware and Unaware Participants
+
+   A conference can include a mix of participants that are conference-
+   aware and unaware.  Conference-unaware participants may be using a
+   proxy function that proxies the advanced functionality between the
+   different protocols and the Conferencing System.  For example, an IVR
+   system or a web page interface can be used to provide additional
+   functionality.
+
+3.4.  A Reserved or Ad Hoc Conference with Conference-Aware Participants
+
+   In order to start the conference, the initiating participant calls
+   the Conferencing System using, for example, a unique identifier.  The
+   Conferencing System may use some authenticating method to qualify the
+   participant.  The other participants may call the Conferencing System
+   and join the conference.  The Conferencing System is able to find the
+   capabilities of the participants.  In case of a reserved conference,
+   the Conferencing System starts the conference at the scheduled time.
+   The participants may join by calling the conference URI, or the
+   Conferencing System may call them.  The conference may have privilege
+   levels associated with a specific conference or participant.  The
+   privileges are for the initiating participant and for a regular
+   participant; the initiating participant may delegate privileges to
+   the other participants.  The privileges allow functionality as
+   defined in the next section.
+
+3.5.  Advanced Conference Features
+
+   The following features can be used in all the advanced conferencing
+   scenarios.  In the examples given in this section, when referring to
+   a participant that has a functionality, it means a participant with
+   the right privileges.  These scenarios may be available in the
+   advanced conferencing scenarios and are common in many conferencing
+   applications.  This is not a requirement list, rather some examples
+   of how specific functions may be used in a conference.
+
+   o  Add Participants - A participant may add a new participant to the
+      conference.  This can be done, for example, by instructing the
+      Conferencing System to call the participant or by the first
+      participant calling the new participant and pointing him to the
+      conference.
+
+   o  Delete Participant - A participant may delete participants from
+      the conference if he can identify them.
+
+
+
+
+
+
+
+Even & Ismail                Informational                      [Page 6]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   o  Changing User Agent/Modes - During the course of a conference, a
+      participant may switch between user agents with different
+      capabilities while still remaining part of the conference.  For
+      example, a participant may initially join using a mobile phone and
+      then switch to a desktop phone.  Or a participant may join with a
+      phone, discover that the conference has video streams available,
+      and switch to a video phone.
+
+   o  Changing Media - During the conference, a participant may be able
+      to select different media streams than the one he had when he
+      joined the conference.  An example is a participant that initially
+      joined the conference as an audio participant.  The participant is
+      unable to understand the conversation properly, and he learns that
+      there is also an interactive text available.  He will ask to
+      receive the text stream also.
+
+   o  Authenticate participants - A participant can authenticate other
+      participants who want to join the conference.  This can be done,
+      for example, in a video conferencing session by creating a sidebar
+      between the two participants, allowing the authenticating
+      participant to talk with the new participant and verify his
+      identity.
+
+   o  Authorize participants - A participant can authorize other
+      participants in order to allow them to join the conference.  This
+      can be done implicitly by assigning a password to the conference
+      or to each participant and letting the Conferencing System decide
+      if the new participant is allowed to join.  The authorization can
+      be done explicitly by directing the entered password to the
+      initiating participant who will authorize each participant.  The
+      conferencing system may use an authentication mechanism to
+      authenticate the participants.
+
+   o  Controlling the presentation of media - During the conference, the
+      participant may be able to manage whose media is being sent to
+      each participant.  For example, the participant may be able to
+      decide that he wants to be the speaker and all the rest to be
+      listeners; he may also specify whose media he wants to receive.
+      The participant may be able to mute a media stream during the
+      conference.
+
+   o  Giving privileges - During the conference, the participant may
+      want to give a privilege to another participant.  The assigning of
+      privileges may be implicit when requested or explicit by asking
+      the participant to grant a privilege.
+
+
+
+
+
+
+Even & Ismail                Informational                      [Page 7]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   o  Side conferences or sidebars - The participant may want to create
+      a side conference that include some of the main conference
+      participants.  When the side conference is finished, the
+      participants return to the main conference.  A sidebar may have
+      the same functionality as the main conference.  There can be
+      several sidebar scenarios:
+
+      1.  A basic sidebar requires that two participants have the
+          capability to have two calls at the same time, with a point-
+          to-point call in parallel to the main conference.  It is user
+          agent implementation-specific whether both calls' streams are
+          mixed automatically or the participants are allowed to
+          manually switch between them.
+
+      2.  A conferencing-system-based sidebar uses the Conferencing
+          System to create the sidebar and compose the relevant sidebar
+          stream mixes.  These mixes can include the main conference as
+          an incoming stream to the mix.  Mechanisms to signal the
+          creation of the sidebar, invite participants, and control the
+          mixes should be available.
+
+          For example, participants in an audio sidebar may not be heard
+          by the rest of the conference.  However, the main conference
+          audio may be mixed in the sidebar, but at a lower volume, or
+          in a different channel.  As another example, a sidebar can
+          have a different media type from the main conference: a video
+          call can have an audio sidebar where the other participants
+          can see the sidebar participants talking but cannot hear them;
+          or an audio or video conference may have a text sidebar.
+
+   o  Conference information - When a participant joins the conference,
+      he is announced to the participants.  An announcement may be
+      available when he leaves the conference.  The participants may
+      query the conferencing system for the current participants of a
+      specific conference.  This conference information may include
+      other information, for example, the media streams available in the
+      conference.
+
+   o  Extending of a conference - Reserved conferences and ad hoc
+      conferences may have a time limit.  The Conferencing System
+      informs the participants when the limit is approaching and may
+      allow the extension of the conference.
+
+   o  Adding and removing a media type to the conference - A participant
+      may want to start a data presentation during a conference.  He may
+      want to distribute this new media to all the participants.  The
+      participant asks the Conferencing System to start the new media
+      channel and to allow him to send data in the new channel.
+
+
+
+Even & Ismail                Informational                      [Page 8]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   o  Audio-only participants - In a multimedia conference, some of the
+      participants who want to join may have no way to send and receive
+      all the media types.  Typically, they can send and receive audio.
+      Such participants join the conference as audio-only participants.
+      The general case is that participants may send and receive only
+      part of the media streams available in the multimedia conference.
+
+   o  Passive participants - In a conference, some participants may be
+      listeners to all or part of the media streams, but may be
+      invisible to all other participants.
+
+   o  Recorders - A recorder can be added to the conference.  A recorder
+      can record all streams or a subset of the streams.  Recorders may
+      be turned on and off during the conference.  Recorders may be used
+      for a "role call" scenario in order to record a participant's
+      name.  This name can be announced at a later stage automatically
+      or based on a participant request.  A recorder is a case of a
+      passive participant.
+
+   o  Whisper/Private Message - A participant can send a one-way message
+      (text, audio, or even some other media) to another participant
+      that is immediately rendered.  This differs from a sidebar in that
+      it is immediate and creates no long-lived session.
+
+   o  Human operator - A participant may ask for assistance from a human
+      operator during the conference.
+
+4.  Scenarios for Media Policy Control
+
+   During a conference, media streams may be controlled by authorized
+   participants using either a media control protocol or a third-party
+   application.  This section describes some typical media control
+   scenarios.  The conference can be of any size.  Some of the media
+   control scenarios are typical of specific conference sizes.  As a
+   general rule, larger conferences scenarios tend to be more centrally
+   managed or structured.
+
+   The mixing of media in a conference may start when the conference
+   starts or when the initiating participant joins.  In the later case,
+   early participants may be put on hold and get "music on hold".
+
+   The scenarios apply to audio conferences as well as to multimedia
+   conferences.  In the sections below, there is some specific
+   information about the mixed video layout and interactive text.
+
+
+
+
+
+
+
+Even & Ismail                Informational                      [Page 9]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+4.1.  Video Mixing Scenarios
+
+   For video, the participant selects one of a set of predefined video
+   presentations offered by the server.  Each video presentation is
+   identified by a textual description as well as an image specifying
+   how the presentation appears on the screen.  In this scenario, by
+   choosing a video presentation, the participant chooses how many video
+   streams (participants) are viewed at once and the layout of these
+   video streams on the screen.
+
+   The contents of each sub-window can be defined by a conference policy
+   and/or controlled by authorized participants.  It may also be
+   possible to have multiple mixes per conference, possibly as many as
+   there are participants.  (Note that the same flexibility may be
+   afforded to audio mixes as well.)
+
+   The following is a list of typical video presentations.  Other
+   layouts are available today in commercial products.
+
+   - Single view: This presentation typically shows the video of the
+     loudest speaker.
+
+   - Dual view: This presentation shows two streams.  If the streams are
+     to be multiplexed in one image (typical of centralized servers),
+     the multiplexing can be:
+
+     1.  Side-by-side windows, with no altered aspect ratio.  Thus,
+         blanking of parts of the image might be necessary if the
+         streams are to be combined as one image.
+
+     2.  Side-by-side windows, with altered aspect ratios.  Thus,
+         blanking parts of the image is not necessary.  The mixer
+         handles the cropping of the images.
+
+     3.  One window above the other, with no altered aspect ratio.
+
+     4.  One window above the other, with altered aspect ratios.
+
+   - Quadrate view: This presentation shows 4 streams.  If the streams
+     are multiplexed into one image (centralized server), they are
+     arranged in a 2x2 style.  Note that in this style the aspect ratios
+     are maintained.
+
+   - 9 sub-picture view: This presentation shows 9 streams.  If the
+     streams are to be multiplexed in one image, they are arranged in a
+     3x3 style.  In the multiplexing case, cropping is performed under
+     the discretion of the mixer.
+
+
+
+
+Even & Ismail                Informational                     [Page 10]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   - 16 sub-picture view: This presentation shows 16 streams.  If the
+     streams are to be multiplexed into one image, they are arranged in
+     a 4x4 style.  In this style, the aspect ratios are maintained, and
+     no cropping or blanking is needed.
+
+   - 5+1 sub-picture view: This presentation shows 6 streams.  If the
+     streams are to be multiplexed into one image, then the pictures are
+     laid so that one sub-window occupies 4/9 of the screen while each
+     of the other five occupies 1/9 of the screen.
+
+4.2.  Typical Video Conferencing Scenario
+
+   This scenario is known as voice-activated video switch.  Every
+   participant hears the N loudest participants but does not hear
+   himself.  All the participants see the loudest speaker; the loudest
+   speaker may see the previous loudest speaker.  This mode is typical
+   for a small conference.
+
+   A participant with proper authorization can exclude one or more
+   participants from the audio or video mix.  An indication that they
+   are not being seen/heard might be displayed to the affected
+   participants.
+
+   A participant with proper authorization can manipulate the gain level
+   associated with one or more audio streams in the mix.
+
+4.3.  Conference Sidebar Scenario
+
+   An authorized participant creates a sidebar.  The participant selects
+   whether the sidebar should include the media from the main conference
+   or not and the audio gain level associated with the main conference
+   audio.
+
+   A participant invites participants to the sidebar, and upon
+   acceptance they start receiving the sidebar media as specified by the
+   sidebar creator.  If the new participant is not a participant of the
+   conference, but is just a participant of the sidebar, the participant
+   only receives the sidebar media without the media of the main
+   conference.
+
+   A participant with the right authorization can move another
+   participant into the sidebar with no indication, in which case the
+   participant suddenly starts receiving the sidebar media.
+
+   Sidebar participants with the right authorization can select to hear
+   or not to hear the main conference audio mixed with the sidebar
+   audio.
+
+
+
+
+Even & Ismail                Informational                     [Page 11]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   A participant can be a participant to more than one sidebar but can
+   only actively participate in one.
+
+   A participant can jump back and forth between the main conference and
+   one or more sidebars.
+
+4.4.  Coaching Scenario
+
+   This is a call center or a remote training session where there is a
+   supervisor who can monitor the conference.  The supervised
+   participants may be the call center operators or the teachers.  A
+   participant in the conference may be a supervised participant or a
+   "customer".
+
+   The supervisor is a hidden participant and is not part of the
+   participant roster.
+
+   The supervised participants might get an announcement/tone indicating
+   that the supervisor has joined.  The other participants do not hear
+   the announcement.
+
+   The supervisor listens to or sees the session but can only be heard
+   or seen by the supervised participant.
+
+   The supervisor can become a normal participant, in which case the
+   participants see the supervisor as part of the roster and start
+   hearing and seeing him.
+
+4.5.  Presentation and Q & A Session
+
+   An example is an earning call scenario in which a group of presenters
+   delivers material to a group of people.  After the presentation is
+   finished, a Q & A session is opened.
+
+   The conference is created as a panel, and the panel participants are
+   identified.  Only their streams are mixed.
+
+   After the end of the presentation, the session chair changes the
+   conference type to normal, and now streams from all participants may
+   be mixed.  Alternatively, a floor control protocol can be used.  The
+   chair can grant the right to speak by adding the participant, whose
+   turn it is to ask a question, to the conference mix.
+
+
+
+
+
+
+
+
+
+Even & Ismail                Informational                     [Page 12]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+4.6.  Presence-Enabled Ad Hoc Conference
+
+   A presence-enabled ad hoc conference, sometimes described as "walkie
+   talkie" service, is a scenario in which a participant sends media to
+   the other participants of the conference after receiving a
+   confirmation of the other participants' availability.  For example, a
+   participant presses a talk button, which checks the presence of the
+   participants to see if they are available for communication.  If they
+   are, a confirmation tone is played, and the participant can then
+   talk; as a result, the media is sent to the other participants in the
+   conference.  These types of conferences tend to be long lived, hence
+   the need for presence to ensure that the other participants are still
+   available.  The ad hoc nature of the conference means that the
+   participant list can be changed at any time.  Floor control can be
+   used to allow other participants to speak, as the conference is
+   usually half-duplex in nature.
+
+4.7.  Group Chat Text Conferencing
+
+   Group chat is a common scenario for text messaging in which a
+   participant joins (or enters) a chat room in which text messages from
+   participants are rendered in a single window and attributed to the
+   participant that sent the message.  Changes in conference membership
+   are often announced in the text window itself (e.g., "Alice has just
+   entered the room.  Bob has just departed.").  Note that a real-time
+   transcription/closed captioning service can provide a similar window
+   in which audio media is converted into interactive text.  "Nicknames"
+   or aliases are often chosen by participants or assigned by the
+   Conferencing System and used as handles within the room.
+
+4.8.  Interactive Text
+
+   Interactive text uses RTP to carry text one character at a time,
+   providing real-time interactivity, as described in RFC 4103 [2].  The
+   interactive text session may be the main conference itself, or it may
+   be used in conjunction with other media types.  Interactive text may
+   be used to represent the audio in the conference using some
+   translation services.  There can be more than one such stream where
+   each text stream is in a different language.  These text streams may
+   be used as subtitles to the audio stream.  The translation from to
+   text to speech and back is done by transcoders.  These transcoders
+   have similar functionality to transcoders between different audio or
+   video algorithms.
+
+   The conference participants should be able to select to receive text
+   streams with the conference audio or those without it.
+
+
+
+
+
+Even & Ismail                Informational                     [Page 13]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+4.9.  Moderated Group Chat
+
+   A moderated group chat scenario for text messaging is similar to
+   group chat, but all text messages sent to the group are filtered/
+   approved by a moderator.  Note that the moderator can be a human or
+   an application.  The moderator also often has the ability to remove
+   participants and provide feedback on their submissions (e.g., provide
+   warnings before removal).
+
+4.10.  Text Sidebars
+
+   Interactive text or instant messaging sidebars are perhaps the most
+   common sidebars in conferences today.  Often the text sessions are
+   separate from the conference.  However, there are some advantages to
+   having text sessions be a sidebar and as a result a part of the main
+   conference.  For example, a conference that is providing anonymity/
+   aliases to participants can also provide anonymous/alias sidebars.  A
+   text sidebar can also benefit from other security/logging/recording
+   services provided by the Conferencing System.
+
+   Another use of a text sidebar is a text-only conversation/discussion
+   between two or more conference participants who are following the
+   main conference at the same time.
+
+4.11.  Conference Announcements
+
+   The conference moderator may be able to play announcements to all the
+   conference participants.  An announcement may be prerecorded or
+   composed by the moderator before it is sent.  The announcements may
+   be text, audio, or audio-visual.  An example is a conference with
+   several audio break-out sessions going on.  At some point, the
+   moderator wants to record an audio message like "In 5 minutes,
+   everyone please come back to the main meeting" and then play that
+   message to all the breakout sessions.
+
+5.  Security Considerations
+
+   Conferences generally have authorization rules about who may or may
+   not join a conference, what type of media may or may not be used,
+   etc.  This information, sometimes called the conference policy or
+   common conference information, is used by the Conferencing System to
+   admit or deny participation in a conference.  For the conference
+   policy to be implemented, the Conferencing System needs to be able to
+   authenticate potential participants.  The methods used depend on the
+   signaling protocols used by the conference.  This can include a
+   challenge/response mechanism, certificates, shared secret, asserted
+   identity, etc.
+
+
+
+
+Even & Ismail                Informational                     [Page 14]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+   Conferences often require that their content be confidential.  In
+   addition, secure authorization of participants is incomplete if
+   access to the media can be gained by unauthorized participants.
+   Functions for securing the media and for key management and
+   distribution to authorized participants need to be provided by the
+   Conferencing System.  In some cases, the functions used for
+   participant authorization can be leveraged for this purpose.
+
+   Privacy is an important aspect of conferencing.  Users may wish to
+   join a conference without anyone knowing that they have joined, in
+   order to silently listen in.  In other applications, a participant
+   may wish just to hide their identity from other participants, but
+   otherwise let them know of their presence.  These functions need to
+   be provided by the Conferencing System.
+
+   These conference-specific security requirements are discussed further
+   in the XCON framework document.
+
+6.  Acknowledgements
+
+   Thanks to Brian Rosen for contributing conferencing scenarios.
+
+   Thanks to Alan Johnston for going over the document and adding some
+   more scenarios; to Keith Lantz, Mary Barnes, and Dave Morgan for
+   carefully reading the document.
+
+7.  Informative References
+
+   [1]  Rosenberg, J., "A Framework for Conferencing with the Session
+        Initiation Protocol (SIP)", RFC 4353, February 2006.
+
+   [2]  Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
+        RFC 4103, June 2005.
+
+   [3]  Barnes, M., "A Framework and Data Model for Centralized
+        Conferencing", Work in Progress, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Even & Ismail                Informational                     [Page 15]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+Authors' Addresses
+
+   Roni Even
+   Polycom
+   94 Derech Em Hamoshavot
+   Petach Tikva  49130
+   Israel
+
+   EMail: roni.even@polycom.co.il
+
+
+   Nermeen Ismail
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose  95134
+   CA USA
+
+   EMail: nismail@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Even & Ismail                Informational                     [Page 16]
+
+RFC 4597                  Conference Scenarios                 July 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Even & Ismail                Informational                     [Page 17]
+