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.
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.
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.
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.
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.
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
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).