doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7205.txt b/doc/rfc/rfc7205.txt
new file mode 100644
index 0000000..5de54f8
--- /dev/null
+++ b/doc/rfc/rfc7205.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Romanow
+Request for Comments: 7205                                         Cisco
+Category: Informational                                        S. Botzko
+ISSN: 2070-1721                                             M. Duckworth
+                                                                 Polycom
+                                                            R. Even, Ed.
+                                                     Huawei Technologies
+                                                              April 2014
+
+
+                Use Cases for Telepresence Multistreams
+
+Abstract
+
+   Telepresence conferencing systems seek to create an environment that
+   gives users (or user groups) that are not co-located a feeling of co-
+   located presence through multimedia communication that includes at
+   least audio and video signals of high fidelity.  A number of
+   techniques for handling audio and video streams are used to create
+   this experience.  When these techniques are not similar,
+   interoperability between different systems is difficult at best, and
+   often not possible.  Conveying information about the relationships
+   between multiple streams of media would enable senders and receivers
+   to make choices to allow telepresence systems to interwork.  This
+   memo describes the most typical and important use cases for sending
+   multiple streams in a telepresence conference.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7205.
+
+
+
+
+
+
+
+
+
+Romanow, et al.               Informational                     [Page 1]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Overview of Telepresence Scenarios  . . . . . . . . . . . . .   4
+   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     3.1.  Point-to-Point Meeting: Symmetric . . . . . . . . . . . .   7
+     3.2.  Point-to-Point Meeting: Asymmetric  . . . . . . . . . . .   7
+     3.3.  Multipoint Meeting  . . . . . . . . . . . . . . . . . . .   9
+     3.4.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  10
+     3.5.  Heterogeneous Systems . . . . . . . . . . . . . . . . . .  11
+     3.6.  Multipoint Education Usage  . . . . . . . . . . . . . . .  12
+     3.7.  Multipoint Multiview (Virtual Space)  . . . . . . . . . .  14
+     3.8.  Multiple Presentation Streams - Telemedicine  . . . . . .  15
+   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   6.  Informative References  . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romanow, et al.               Informational                     [Page 2]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+1.  Introduction
+
+   Telepresence applications try to provide a "being there" experience
+   for conversational video conferencing.  Often, this telepresence
+   application is described as "immersive telepresence" in order to
+   distinguish it from traditional video conferencing and from other
+   forms of remote presence not related to conversational video
+   conferencing, such as avatars and robots.  The salient
+   characteristics of telepresence are often described as: being actual
+   sized, providing immersive video, preserving interpersonal
+   interaction, and allowing non-verbal communication.
+
+   Although telepresence systems are based on open standards such as RTP
+   [RFC3550], SIP [RFC3261], H.264 [ITU.H264], and the H.323 [ITU.H323]
+   suite of protocols, they cannot easily interoperate with each other
+   without operator assistance and expensive additional equipment that
+   translates from one vendor's protocol to another.
+
+   The basic features that give telepresence its distinctive
+   characteristics are implemented in disparate ways in different
+   systems.  Currently, telepresence systems from diverse vendors
+   interoperate to some extent, but this is not supported in a
+   standards-based fashion.  Interworking requires that translation and
+   transcoding devices be included in the architecture.  Such devices
+   increase latency, reducing the quality of interpersonal interaction.
+   Use of these devices is often not automatic; it frequently requires
+   substantial manual configuration and a detailed understanding of the
+   nature of underlying audio and video streams.  This state of affairs
+   is not acceptable for the continued growth of telepresence -- these
+   systems should have the same ease of interoperability as do
+   telephones.  Thus, a standard way of describing the multiple streams
+   constituting the media flows and the fundamental aspects of their
+   behavior would allow telepresence systems to interwork.
+
+   This document presents a set of use cases describing typical
+   scenarios.  Requirements will be derived from these use cases in a
+   separate document.  The use cases are described from the viewpoint of
+   the users.  They are illustrative of the user experience that needs
+   to be supported.  It is possible to implement these use cases in a
+   variety of different ways.
+
+   Many different scenarios need to be supported.  This document
+   describes in detail the most common and basic use cases.  These will
+   cover most of the requirements.  There may be additional scenarios
+   that bring new features and requirements that can be used to extend
+   the initial work.
+
+
+
+
+
+Romanow, et al.               Informational                     [Page 3]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   Point-to-point and multipoint telepresence conferences are
+   considered.  In some use cases, the number of screens is the same at
+   all sites; in others, the number of screens differs at different
+   sites.  Both use cases are considered.  Also included is a use case
+   describing display of presentation material or content.
+
+   The multipoint use cases may include a variety of systems from
+   conference room systems to handheld devices, and such a use case is
+   described in the document.
+
+   This document's structure is as follows: Section 2 gives an overview
+   of scenarios, and Section 3 describes use cases.
+
+2.  Overview of Telepresence Scenarios
+
+   This section describes the general characteristics of the use cases
+   and what the scenarios are intended to show.  The typical setting is
+   a business conference, which was the initial focus of telepresence.
+   Recently, consumer products are also being developed.  We
+   specifically do not include in our scenarios the physical
+   infrastructure aspects of telepresence, such as room construction,
+   layout, and decoration.  Furthermore, these use cases do not describe
+   all the aspects needed to create the best user experience (for
+   example, the human factors).
+
+   We also specifically do not attempt to precisely define the
+   boundaries between telepresence systems and other systems, nor do we
+   attempt to identify the "best" solution for each presented scenario.
+
+   Telepresence systems are typically composed of one or more video
+   cameras and encoders and one or more display screens of large size
+   (diagonal around 60 inches).  Microphones pick up sound, and audio
+   codec(s) produce one or more audio streams.  The cameras used to
+   capture the telepresence users are referred to as "participant
+   cameras" (and likewise for screens).  There may also be other
+   cameras, such as for document display.  These will be referred to as
+   "presentation cameras" or "content cameras", which generally have
+   different formats, aspect ratios, and frame rates from the
+   participant cameras.  The presentation streams may be shown on
+   participant screens or on auxiliary display screens.  A user's
+   computer may also serve as a virtual content camera, generating an
+   animation or playing a video for display to the remote participants.
+
+   We describe such a telepresence system as sending one or more video
+   streams, audio streams, and presentation streams to the remote
+   system(s).
+
+
+
+
+
+Romanow, et al.               Informational                     [Page 4]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   The fundamental parameters describing today's typical telepresence
+   scenarios include:
+
+   1.   The number of participating sites
+
+   2.   The number of visible seats at a site
+
+   3.   The number of cameras
+
+   4.   The number and type of microphones
+
+   5.   The number of audio channels
+
+   6.   The screen size
+
+   7.   The screen capabilities -- such as resolution, frame rate,
+        aspect ratio
+
+   8.   The arrangement of the screens in relation to each other
+
+   9.   The number of primary screens at each site
+
+   10.  Type and number of presentation screens
+
+   11.  Multipoint conference display strategies -- for example, the
+        camera-to-screen mappings may be static or dynamic
+
+   12.  The camera point of capture
+
+   13.  The cameras fields of view and how they spatially relate to each
+        other
+
+   As discussed in the introduction, the basic features that give
+   telepresence its distinctive characteristics are implemented in
+   disparate ways in different systems.
+
+   There is no agreed upon way to adequately describe the semantics of
+   how streams of various media types relate to each other.  Without a
+   standard for stream semantics to describe the particular roles and
+   activities of each stream in the conference, interoperability is
+   cumbersome at best.
+
+   In a multiple-screen conference, the video and audio streams sent
+   from remote participants must be understood by receivers so that they
+   can be presented in a coherent and life-like manner.  This includes
+   the ability to present remote participants at their actual size for
+   their apparent distance, while maintaining correct eye contact,
+
+
+
+
+Romanow, et al.               Informational                     [Page 5]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   gesticular cues, and simultaneously providing a spatial audio sound
+   stage that is consistent with the displayed video.
+
+   The receiving device that decides how to render incoming information
+   needs to understand a number of variables such as the spatial
+   position of the speaker, the field of view of the cameras, the camera
+   zoom, which media stream is related to each of the screens, etc.  It
+   is not simply that individual streams must be adequately described,
+   to a large extent this already exists, but rather that the semantics
+   of the relationships between the streams must be communicated.  Note
+   that all of this is still required even if the basic aspects of the
+   streams, such as the bit rate, frame rate, and aspect ratio, are
+   known.  Thus, this problem has aspects considerably beyond those
+   encountered in interoperation of video conferencing systems that have
+   a single camera/screen.
+
+3.  Use Cases
+
+   The use cases focus on typical implementations.  There are a number
+   of possible variants for these use cases; for example, the audio
+   supported may differ at the end points (such as mono or stereo versus
+   surround sound), etc.
+
+   Many of these systems offer a "full conference room" solution, where
+   local participants sit at one side of a table and remote participants
+   are displayed as if they are sitting on the other side of the table.
+   The cameras and screens are typically arranged to provide a panoramic
+   view of the remote room (left to right from the local user's
+   viewpoint).
+
+   The sense of immersion and non-verbal communication is fostered by a
+   number of technical features, such as:
+
+   1.  Good eye contact, which is achieved by careful placement of
+       participants, cameras, and screens.
+
+   2.  Camera field of view and screen sizes are matched so that the
+       images of the remote room appear to be full size.
+
+   3.  The left side of each room is presented on the right screen at
+       the far end; similarly, the right side of the room is presented
+       on the left screen.  The effect of this is that participants of
+       each site appear to be sitting across the table from each other.
+       If 2 participants on the same site glance at each other, all
+       participants can observe it.  Likewise, if a participant at one
+       site gestures to a participant on the other site, all
+       participants observe the gesture itself and the participants it
+       includes.
+
+
+
+Romanow, et al.               Informational                     [Page 6]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+3.1.  Point-to-Point Meeting: Symmetric
+
+   In this case, each of the 2 sites has an identical number of screens,
+   with cameras having fixed fields of view, and 1 camera for each
+   screen.  The sound type is the same at each end.  As an example,
+   there could be 3 cameras and 3 screens in each room, with stereo
+   sound being sent and received at each end.
+
+   Each screen is paired with a corresponding camera.  Each camera/
+   screen pair is typically connected to a separate codec, producing an
+   encoded stream of video for transmission to the remote site, and
+   receiving a similarly encoded stream from the remote site.
+
+   Each system has one or multiple microphones for capturing audio.  In
+   some cases, stereophonic microphones are employed.  In other systems,
+   a microphone may be placed in front of each participant (or pair of
+   participants).  In typical systems, all the microphones are connected
+   to a single codec that sends and receives the audio streams as either
+   stereo or surround sound.  The number of microphones and the number
+   of audio channels are often not the same as the number of cameras.
+   Also, the number of microphones is often not the same as the number
+   of loudspeakers.
+
+   The audio may be transmitted as multi-channel (stereo/surround sound)
+   or as distinct and separate monophonic streams.  Audio levels should
+   be matched, so the sound levels at both sites are identical.
+   Loudspeaker and microphone placements are chosen so that the sound
+   "stage" (orientation of apparent audio sources) is coordinated with
+   the video.  That is, if a participant at one site speaks, the
+   participants at the remote site perceive her voice as originating
+   from her visual image.  In order to accomplish this, the audio needs
+   to be mapped at the received site in the same fashion as the video.
+   That is, audio received from the right side of the room needs to be
+   output from loudspeaker(s) on the left side at the remote site, and
+   vice versa.
+
+3.2.  Point-to-Point Meeting: Asymmetric
+
+   In this case, each site has a different number of screens and cameras
+   than the other site.  The important characteristic of this scenario
+   is that the number of screens is different between the 2 sites.  This
+   creates challenges that are handled differently by different
+   telepresence systems.
+
+   This use case builds on the basic scenario of 3 screens to 3 screens.
+   Here, we use the common case of 3 screens and 3 cameras at one site,
+   and 1 screen and 1 camera at the other site, connected by a point-to-
+   point call.  The screen sizes and camera fields of view at both sites
+
+
+
+Romanow, et al.               Informational                     [Page 7]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   are basically similar, such that each camera view is designed to show
+   2 people sitting side by side.  Thus, the 1-screen room has up to 2
+   people seated at the table, while the 3-screen room may have up to 6
+   people at the table.
+
+   The basic considerations of defining left and right and indicating
+   relative placement of the multiple audio and video streams are the
+   same as in the 3-3 use case.  However, handling the mismatch between
+   the 2 sites of the number of screens and cameras requires more
+   complicated maneuvers.
+
+   For the video sent from the 1-camera room to the 3-screen room,
+   usually what is done is to simply use 1 of the 3 screens and keep the
+   second and third screens inactive or, for example, put up the current
+   date.  This would maintain the "full-size" image of the remote side.
+
+   For the other direction, the 3-camera room sending video to the
+   1-screen room, there are more complicated variations to consider.
+   Here are several possible ways in which the video streams can be
+   handled.
+
+   1.  The 1-screen system might simply show only 1 of the 3 camera
+       images, since the receiving side has only 1 screen.  2 people are
+       seen at full size, but 4 people are not seen at all.  The choice
+       of which one of the 3 streams to display could be fixed, or could
+       be selected by the users.  It could also be made automatically
+       based on who is speaking in the 3-screen room, such that the
+       people in the 1-screen room always see the person who is
+       speaking.  If the automatic selection is done at the sender, the
+       transmission of streams that are not displayed could be
+       suppressed, which would avoid wasting bandwidth.
+
+   2.  The 1-screen system might be capable of receiving and decoding
+       all 3 streams from all 3 cameras.  The 1-screen system could then
+       compose the 3 streams into 1 local image for display on the
+       single screen.  All 6 people would be seen, but smaller than full
+       size.  This could be done in conjunction with reducing the image
+       resolution of the streams, such that encode/decode resources and
+       bandwidth are not wasted on streams that will be downsized for
+       display anyway.
+
+   3.  The 3-screen system might be capable of including all 6 people in
+       a single stream to send to the 1-screen system.  For example, it
+       could use PTZ (Pan Tilt Zoom) cameras to physically adjust the
+       cameras such that 1 camera captures the whole room of 6 people.
+       Or, it could recompose the 3 camera images into 1 encoded stream
+       to send to the remote site.  These variations also show all 6
+       people but at a reduced size.
+
+
+
+Romanow, et al.               Informational                     [Page 8]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   4.  Or, there could be a combination of these approaches, such as
+       simultaneously showing the speaker in full size with a composite
+       of all 6 participants in a smaller size.
+
+   The receiving telepresence system needs to have information about the
+   content of the streams it receives to make any of these decisions.
+   If the systems are capable of supporting more than one strategy,
+   there needs to be some negotiation between the 2 sites to figure out
+   which of the possible variations they will use in a specific point-
+   to-point call.
+
+3.3.  Multipoint Meeting
+
+   In a multipoint telepresence conference, there are more than 2 sites
+   participating.  Additional complexity is required to enable media
+   streams from each participant to show up on the screens of the other
+   participants.
+
+   Clearly, there are a great number of topologies that can be used to
+   display the streams from multiple sites participating in a
+   conference.
+
+   One major objective for telepresence is to be able to preserve the
+   "being there" user experience.  However, in multi-site conferences,
+   it is often (in fact, usually) not possible to simultaneously provide
+   full-size video, eye contact, and common perception of gestures and
+   gaze by all participants.  Several policies can be used for stream
+   distribution and display: all provide good results, but they all make
+   different compromises.
+
+   One common policy is called site switching.  Let's say the speaker is
+   at site A and the other participants are at various "remote" sites.
+   When the room at site A shown, all the camera images from site A are
+   forwarded to the remote sites.  Therefore, at each receiving remote
+   site, all the screens display camera images from site A.  This can be
+   used to preserve full-size image display, and also provide full
+   visual context of the displayed far end, site A.  In site switching,
+   there is a fixed relation between the cameras in each room and the
+   screens in remote rooms.  The room or participants being shown are
+   switched from time to time based on who is speaking or by manual
+   control, e.g., from site A to site B.
+
+   Segment switching is another policy choice.  In segment switching
+   (assuming still that site A is where the speaker is, and "remote"
+   refers to all the other sites), rather than sending all the images
+   from site A, only the speaker at site A is shown.  The camera images
+   of the current speaker and previous speakers (if any) are forwarded
+   to the other sites in the conference.  Therefore, the screens in each
+
+
+
+Romanow, et al.               Informational                     [Page 9]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   site are usually displaying images from different remote sites -- the
+   current speaker at site A and the previous ones.  This strategy can
+   be used to preserve full-size image display and also capture the non-
+   verbal communication between the speakers.  In segment switching, the
+   display depends on the activity in the remote rooms (generally, but
+   not necessarily based on audio/speech detection).
+
+   A third possibility is to reduce the image size so that multiple
+   camera views can be composited onto one or more screens.  This does
+   not preserve full-size image display, but it provides the most visual
+   context (since more sites or segments can be seen).  Typically in
+   this case, the display mapping is static, i.e., each part of each
+   room is shown in the same location on the display screens throughout
+   the conference.
+
+   Other policies and combinations are also possible.  For example,
+   there can be a static display of all screens from all remote rooms,
+   with part or all of one screen being used to show the current speaker
+   at full size.
+
+3.4.  Presentation
+
+   In addition to the video and audio streams showing the participants,
+   additional streams are used for presentations.
+
+   In systems available today, generally only one additional video
+   stream is available for presentations.  Often, this presentation
+   stream is half-duplex in nature, with presenters taking turns.  The
+   presentation stream may be captured from a PC screen, or it may come
+   from a multimedia source such as a document camera, camcorder, or a
+   DVD.  In a multipoint meeting, the presentation streams for the
+   currently active presentation are always distributed to all sites in
+   the meeting, so that the presentations are viewed by all.
+
+   Some systems display the presentation streams on a screen that is
+   mounted either above or below the 3 participant screens.  Other
+   systems provide screens on the conference table for observing
+   presentations.  If multiple presentation screens are used, they
+   generally display identical content.  There is considerable variation
+   in the placement, number, and size of presentation screens.
+
+   In some systems, presentation audio is pre-mixed with the room audio.
+   In others, a separate presentation audio stream is provided (if the
+   presentation includes audio).
+
+
+
+
+
+
+
+Romanow, et al.               Informational                    [Page 10]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   In H.323 [ITU.H323] systems, H.239 [ITU.H239] is typically used to
+   control the video presentation stream.  In SIP systems, similar
+   control mechanisms can be provided using the Binary Floor Control
+   Protocol (BFCP) [RFC4582] for the presentation token.  These
+   mechanisms are suitable for managing a single presentation stream.
+
+   Although today's systems remain limited to a single video
+   presentation stream, there are obvious uses for multiple presentation
+   streams:
+
+   1.  Frequently, the meeting convener is following a meeting agenda,
+       and it is useful for her to be able to show that agenda to all
+       participants during the meeting.  Other participants at various
+       remote sites are able to make presentations during the meeting,
+       with the presenters taking turns.  The presentations and the
+       agenda are both shown, either on separate screens, or perhaps
+       rescaled and shown on a single screen.
+
+   2.  A single multimedia presentation can itself include multiple
+       video streams that should be shown together.  For instance, a
+       presenter may be discussing the fairness of media coverage.  In
+       addition to slides that support the presenter's conclusions, she
+       also has video excerpts from various news programs that she shows
+       to illustrate her findings.  She uses a DVD player for the video
+       excerpts so that she can pause and reposition the video as
+       needed.
+
+   3.  An educator who is presenting a multiscreen slide show.  This
+       show requires that the placement of the images on the multiple
+       screens at each site be consistent.
+
+   There are many other examples where multiple presentation streams are
+   useful.
+
+3.5.  Heterogeneous Systems
+
+   It is common in meeting scenarios for people to join the conference
+   from a variety of environments, using different types of endpoint
+   devices.  A multiscreen immersive telepresence conference may include
+   someone on a PC-based video conferencing system, a participant
+   calling in by phone, and (soon) someone on a handheld device.
+
+   What experience/view will each of these devices have?
+
+   Some may be able to handle multiple streams, and others can handle
+   only a single stream.  (Here, we are not talking about legacy
+   systems, but rather systems built to participate in such a
+   conference, although they are single stream only.)  In a single video
+
+
+
+Romanow, et al.               Informational                    [Page 11]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   stream, the stream may contain one or more compositions depending on
+   the available screen space on the device.  In most cases, an
+   intermediate transcoding device will be relied upon to produce a
+   single stream, perhaps with some kind of continuous presence.
+
+   Bit rates will vary -- the handheld device and phone having lower bit
+   rates than PC and multiscreen systems.
+
+   Layout is accomplished according to different policies.  For example,
+   a handheld device and PC may receive the active speaker stream.  The
+   decision can either be made explicitly by the receiver or by the
+   sender if it can receive some kind of rendering hint.  The same is
+   true for audio -- i.e., that it receives a mixed stream or a number
+   of the loudest speakers if mixing is not available in the network.
+
+   For the PC-based conferencing participant, the user's experience
+   depends on the application.  It could be single stream, similar to a
+   handheld device but with a bigger screen.  Or, it could be multiple
+   streams, similar to an immersive telepresence system but with a
+   smaller screen.  Control for manipulation of streams can be local in
+   the software application, or in another location and sent to the
+   application over the network.
+
+   The handheld device is the most extreme.  How will that participant
+   be viewed and heard?  It should be an equal participant, though the
+   bandwidth will be significantly less than an immersive system.  A
+   receiver may choose to display output coming from a handheld device
+   differently based on the resolution, but that would be the case with
+   any low-resolution video stream, e.g., from a powerful PC on a bad
+   network.
+
+   The handheld device will send and receive a single video stream,
+   which could be a composite or a subset of the conference.  The
+   handheld device could say what it wants or could accept whatever the
+   sender (conference server or sending endpoint) thinks is best.  The
+   handheld device will have to signal any actions it wants to take the
+   same way that an immersive system signals actions.
+
+3.6.  Multipoint Education Usage
+
+   The importance of this example is that the multiple video streams are
+   not used to create an immersive conferencing experience with
+   panoramic views at all the sites.  Instead, the multiple streams are
+   dynamically used to enable full participation of remote students in a
+   university class.  In some instances, the same video stream is
+   displayed on multiple screens in the room; in other instances, an
+   available stream is not displayed at all.
+
+
+
+
+Romanow, et al.               Informational                    [Page 12]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   The main site is a university auditorium that is equipped with 3
+   cameras.  One camera is focused on the professor at the podium.  A
+   second camera is mounted on the wall behind the professor and
+   captures the class in its entirety.  The third camera is co-located
+   with the second and is designed to capture a close-up view of a
+   questioner in the audience.  It automatically zooms in on that
+   student using sound localization.
+
+   Although the auditorium is equipped with 3 cameras, it is only
+   equipped with 2 screens.  One is a large screen located at the front
+   so that the class can see it.  The other is located at the rear so
+   the professor can see it.  When someone asks a question, the front
+   screen shows the questioner.  Otherwise, it shows the professor
+   (ensuring everyone can easily see her).
+
+   The remote sites are typical immersive telepresence rooms, each with
+   3 camera/screen pairs.
+
+   All remote sites display the professor on the center screen at full
+   size.  A second screen shows the entire classroom view when the
+   professor is speaking.  However, when a student asks a question, the
+   second screen shows the close-up view of the student at full size.
+   Sometimes the student is in the auditorium; sometimes the speaking
+   student is at another remote site.  The remote systems never display
+   the students that are actually in that room.
+
+   If someone at a remote site asks a question, then the screen in the
+   auditorium will show the remote student at full size (as if they were
+   present in the auditorium itself).  The screen in the rear also shows
+   this questioner, allowing the professor to see and respond to the
+   student without needing to turn her back on the main class.
+
+   When no one is asking a question, the screen in the rear briefly
+   shows a full-room view of each remote site in turn, allowing the
+   professor to monitor the entire class (remote and local students).
+   The professor can also use a control on the podium to see a
+   particular site -- she can choose either a full-room view or a
+   single-camera view.
+
+   Realization of this use case does not require any negotiation between
+   the participating sites.  Endpoint devices (and a Multipoint Control
+   Unit (MCU), if present) need to know who is speaking and what video
+   stream includes the view of that speaker.  The remote systems need
+   some knowledge of which stream should be placed in the center.  The
+   ability of the professor to see specific sites (or for the system to
+   show all the sites in turn) would also require the auditorium system
+
+
+
+
+
+Romanow, et al.               Informational                    [Page 13]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   to know what sites are available and to be able to request a
+   particular view of any site.  Bandwidth is optimized if video that is
+   not being shown at a particular site is not distributed to that site.
+
+3.7.  Multipoint Multiview (Virtual Space)
+
+   This use case describes a virtual space multipoint meeting with good
+   eye contact and spatial layout of participants.  The use case was
+   proposed very early in the development of video conferencing systems
+   as described in 1983 by Allardyce and Randal [virtualspace].  The use
+   case is illustrated in Figure 2-5 of their report.  The virtual space
+   expands the point-to-point case by having all multipoint conference
+   participants "seated" in a virtual room.  In this case, each
+   participant has a fixed "seat" in the virtual room, so each
+   participant expects to see a different view having a different
+   participant on his left and right side.  Today, the use case is
+   implemented in multiple telepresence-type video conferencing systems
+   on the market.  The term "virtual space" was used in their report.
+   The main difference between the result obtained with modern systems
+   and those from 1983 are larger screen sizes.
+
+   Virtual space multipoint as defined here assumes endpoints with
+   multiple cameras and screens.  Usually, there is the same number of
+   cameras and screens at a given endpoint.  A camera is positioned
+   above each screen.  A key aspect of virtual space multipoint is the
+   details of how the cameras are aimed.  The cameras are each aimed on
+   the same area of view of the participants at the site.  Thus, each
+   camera takes a picture of the same set of people but from a different
+   angle.  Each endpoint sender in the virtual space multipoint meeting
+   therefore offers a choice of video streams to remote receivers, each
+   stream representing a different viewpoint.  For example, a camera
+   positioned above a screen to a participant's left may take video
+   pictures of the participant's left ear; while at the same time, a
+   camera positioned above a screen to the participant's right may take
+   video pictures of the participant's right ear.
+
+   Since a sending endpoint has a camera associated with each screen, an
+   association is made between the receiving stream output on a
+   particular screen and the corresponding sending stream from the
+   camera associated with that screen.  These associations are repeated
+   for each screen/camera pair in a meeting.  The result of this system
+   is a horizontal arrangement of video images from remote sites, one
+   per screen.  The image from each screen is paired with the camera
+   output from the camera above that screen, resulting in excellent eye
+   contact.
+
+
+
+
+
+
+Romanow, et al.               Informational                    [Page 14]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+3.8.  Multiple Presentation Streams - Telemedicine
+
+   This use case describes a scenario where multiple presentation
+   streams are used.  In this use case, the local site is a surgery room
+   connected to one or more remote sites that may have different
+   capabilities.  At the local site, 3 main cameras capture the whole
+   room (the typical 3-camera telepresence case).  Also, multiple
+   presentation inputs are available: a surgery camera that is used to
+   provide a zoomed view of the operation, an endoscopic monitor, a
+   flouroscope (X-ray imaging), an ultrasound diagnostic device, an
+   electrocardiogram (ECG) monitor, etc.  These devices are used to
+   provide multiple local video presentation streams to help the surgeon
+   monitor the status of the patient and assist in the surgical process.
+
+   The local site may have 3 main screens and one (or more) presentation
+   screen(s).  The main screens can be used to display the remote
+   experts.  The presentation screen(s) can be used to display multiple
+   presentation streams from local and remote sites simultaneously.  The
+   3 main cameras capture different parts of the surgery room.  The
+   surgeon can decide the number, the size, and the placement of the
+   presentations displayed on the local presentation screen(s).  He can
+   also indicate which local presentation captures are provided for the
+   remote sites.  The local site can send multiple presentation captures
+   to remote sites, and it can receive from them multiple presentations
+   related to the patient or the procedure.
+
+   One type of remote site is a single- or dual-screen and one-camera
+   system used by a consulting expert.  In the general case, the remote
+   sites can be part of a multipoint telepresence conference.  The
+   presentation screens at the remote sites allow the experts to see the
+   details of the operation and related data.  Like the main site, the
+   experts can decide the number, the size, and the placement of the
+   presentations displayed on the presentation screens.  The
+   presentation screens can display presentation streams from the
+   surgery room, from other remote sites, or from local presentation
+   streams.  Thus, the experts can also start sending presentation
+   streams that can carry medical records, pathology data, or their
+   references and analysis, etc.
+
+   Another type of remote site is a typical immersive telepresence room
+   with 3 camera/screen pairs, allowing more experts to join the
+   consultation.  These sites can also be used for education.  The
+   teacher, who is not necessarily the surgeon, and the students are in
+   different remote sites.  Students can observe and learn the details
+   of the whole procedure, while the teacher can explain and answer
+   questions during the operation.
+
+
+
+
+
+Romanow, et al.               Informational                    [Page 15]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   All remote education sites can display the surgery room.  Another
+   option is to display the surgery room on the center screen, and the
+   rest of the screens can show the teacher and the student who is
+   asking a question.  For all the above sites, multiple presentation
+   screens can be used to enhance visibility: one screen for the zoomed
+   surgery stream and the others for medical image streams, such as MRI
+   images, cardiograms, ultrasonic images, and pathology data.
+
+4.  Acknowledgements
+
+   The document has benefitted from input from a number of people
+   including Alex Eleftheriadis, Marshall Eubanks, Tommy Andre Nyquist,
+   Mark Gorzynski, Charles Eckel, Nermeen Ismail, Mary Barnes, Pascal
+   Buhler, and Jim Cole.
+
+   Special acknowledgement to Lennard Xiao, who contributed the text for
+   the telemedicine use case, and to Claudio Allocchio for his detailed
+   review of the document.
+
+5.  Security Considerations
+
+   While there are likely to be security considerations for any solution
+   for telepresence interoperability, this document has no security
+   considerations.
+
+6.  Informative References
+
+   [ITU.H239]  ITU-T, "Role management and additional media channels for
+               H.300-series terminals", ITU-T Recommendation H.239,
+               September 2005.
+
+   [ITU.H264]  ITU-T, "Advanced video coding for generic audiovisual
+               services", ITU-T Recommendation H.264, April 2013.
+
+   [ITU.H323]  ITU-T, "Packet-based Multimedia Communications Systems",
+               ITU-T Recommendation H.323, December 2009.
+
+   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+               A., Peterson, J., Sparks, R., Handley, M., and E.
+               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+               June 2002.
+
+   [RFC3550]   Schulzrinne, H., Casner, S., Frederick, R., and V.
+               Jacobson, "RTP: A Transport Protocol for Real-Time
+               Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC4582]   Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
+               Control Protocol (BFCP)", RFC 4582, November 2006.
+
+
+
+Romanow, et al.               Informational                    [Page 16]
+
+RFC 7205                 Telepresence Use Cases               April 2014
+
+
+   [virtualspace]
+               Allardyce, L. and L. Randall, "Development of
+               Teleconferencing Methodologies with Emphasis on Virtual
+               Space Video and Interactive Graphics", April 1983,
+               <http://www.dtic.mil/docs/citations/ADA127738>.
+
+Authors' Addresses
+
+   Allyn Romanow
+   Cisco
+   San Jose, CA  95134
+   US
+
+   EMail: allyn@cisco.com
+
+
+   Stephen Botzko
+   Polycom
+   Andover, MA  01810
+   US
+
+   EMail: stephen.botzko@polycom.com
+
+
+   Mark Duckworth
+   Polycom
+   Andover, MA  01810
+   US
+
+   EMail: mark.duckworth@polycom.com
+
+
+   Roni Even (editor)
+   Huawei Technologies
+   Tel Aviv
+   Israel
+
+   EMail: roni.even@mail01.huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romanow, et al.               Informational                    [Page 17]
+