VidMid Videoconferencing Scenarios for Videoconferencing

Goal

Several use scenarios are being developed to investigate the middleware requirements for videoconferencing.

• Cast a wide net for important capabilities for the R&E community
• Categorize those needs into problem sets and prioritize
• Help with identifying middleware issues
• Describe typical cases of videoconferencing use. The cases handled are point-to-point, multipoint, and interrealm

The scenarios will drive the mapping of realistic requirements against infrastructural elements and will therefore determine the architecture. The architecture model and the scenarios and their requirements will iterate off each other for a while. Seeing the model, people understand more about the specifics of the scenarios, and vice versa. Once the requirements are clear, the final mapping of them onto components will need video people working with IT architects.

It is hard to keep the scenarios realistic. It is tempting to add a lot of "second generation" desires. The goal is not to put everything in, but to avoid locking things out in subsequent development. If you notice we crossed the line here, please take up the discussion on the VidMid-VC mailing list. (If you are not already subscribed to this list, send a request to listmgr@internet2.edu)

It is also difficult, if not impossible, to generate all potential scenarios or, having generated them, to prioritize them in such a way that everyone would agree on which scenarios should be targeted for development first. With this in mind, the scenarios listed below represent only those generated to date with those that are under the most active development as indicated. In some cases, only "placeholder titles" are included. These indicated scenarios that we hope to elaborate on in the future. The work of Vidmid-VC in enabling the scenarios overall is anticipated to be ongoing, with refinements and reprioritization where and when necessary.

Definitions

videoconferencing

all forms of audio- and/or videoconferencing, including IP-telephony or Voice-over-IP (VoIP), but excluding data- and application-sharing (the last being mentioned explicitly when discussed). Often only "conferencing" is used.

interrealm

the communication taking place across boundaries, where the boundaries can be administrative (between authorization domains) or technical (such as when using different signaling protocols).

he/she, him/her

wherever "he" or "'him" is used, also "she" or "her" is meant.

Process

1. Work out scenarios
2. Extract requirements from prioritized scenarios
3. Develop designs from requirements
4. Set up testbeds for implementations
5. Dissemination from implementations and testbeds

1. Work out scenarios

The scenarios below are intended to provoke discussion of what videoconferencing middleware should and shouldn't do. It is not necessarily the case that these represent a complete list of scenarios or that VidMid-VC should support all of those listed. These scenarios should encompass most of the sorts of things that we expect VidMid-VC to play a part in. Scenarios under active development within each category are designated as such.

• summary of VidMid scenario discussions which collects information from VidMid activities so far in regards to scenario development. These notes are drawn from meeting minutes, email discussions to the VidMid list, and various submitted scenarios. Information is presented generally in chronological order as received by Working Group discussions. By Art Vandenberg
• Directory Scenarios for Videoconferencing, by Art Vandenberg
• SURFnet Conferencing scenarios, by Egon Verharen
• Scenario Guidelines, Verplank, Fulton, Black and Moggridge, INTERCHI'93
• SACRED scenarios; draft-ietf-sacred-scenarios-00. Expired IETF internet-draft, used as example for scenario development.

The format of the attached scenarios is:

Title

Description

Brief explanation

Example

End user story. This may consists of basic, extended and advanced stories

Generic format (optional)

De-personalized and abstracted description

Needed components

Listing of used/required middleware issues [identifier, authentication, authorization, security, directory services, resource discovery, etc.]

Assumptions

Background information required to understand the context of the scenario

Uniqueness (optional)

Description of aspects that separates this scenario from the others, or a description of aspects that change when certain assumptions change, e.g. using SIP instead of H.323 signaling protocols

General Point-to-Point Scenario

Note: we are only concerned with callserver assisted call setup. Point-to-point videoconferencing where the IP address of the other person's device is used, although interesting for firewall scenarios, is not being addressed here.

General Multipoint Scenario with Centralized MCU Control and Media Processing

The general scenario for scheduled multipoint conferencing is:
Person A, or an administrator operating in behalf of person A, schedules a multipoint conference at a known MCU. Specification would include the call details of the participants, the meeting time to accommodate participants' existing calendar commitments or time zone preferences, the meeting mode, and security (public, private). Set up might include coordination or reservation of bandwidth, in case of limiting factors imposed by the video conferencing or other simultaneous activities.

Advanced: These settings (list of participants, their configurations, their time zone preferences, etc.) can be saved for reuse. It may be that the configuration aspects of individual end points are maintained in a manner that permits them to be mixed and matched dynamically for other multipoint (or endpoint-to-endpoint) sessions.

Interrealm Scenario

There is no end-user scenario worked out for the case where "interrealm" is used for "inter-protocol" videoconferencing.

All point-to-point and multipoint scenarios can be interrealm in the meaning of inter-administrative domain. Where needed this will be described explicitly.

Detailed scenarios

1) Title: Point to Point, ad hoc Videoconferencing Scenario, H.323 **Active Development**

Description
A person uses their videoconferencing device to contact another person who has a similar videoconferencing capability. They participate in a real-time video and audio discussion.

Example
Joan wants to contact Leo and discuss the issues related to a project they are working on together. Joan wants to have a visual component to the meeting, rather than using email or phone call, since they need to resolve some details that a more personal interaction is desirable. Both Joan and Leo have had videoconferencing devices set up in their offices for communications such as this.

Joan is able to lookup Leo's contact information in an authoritative directory, clicks on Leo's entry and a call connection is automatically initiated by the Joan's videoconferencing device. Leo's videoconferencing device alerts him to the connection request and identifies that it is Joan calling. As Leo is between meetings, he accepts the call and Joan and Leo meet with full audio and video capability.

Generic format
Two individuals with videoconferencing capability are able to make a connection. Connection information is looked up automatically by the videoconferencing device's gatekeeper that is closely integrated with LDAP directory services. The LDAP directory represents the people objects and resource objects such as individual classrooms or conference rooms that are videoconference enabled. Account objects represent individual accounts through which individuals access services. Endpoint objects represent the details of the videoconferencing equipment. When a connection request is made, the caller's identification and authentication is checked and then an authorization check ensures the caller has access to the accounts and other resources. Similar identification, authentication and authorization may be conducted for the call destination.

Needed components

• Gatekeeper integration with LDAP directory.
• Directory entries for appropriate data objects, such as people, resources, and accounts.
• Authorization data must be associated with resources and accounts.
• Directory objects should be maintainable by end users and or administrator to ensure authoritative data.
• Integration between gatekeeper and directory should be synchronized at an appropriate level.

Assumptions
The assumption is that both users have videoconferencing devices at an office or desktop level and it is realistic for them to "just call" one another in an ad hoc manner, like using the phone. Clearly, if the call were scheduled, rather than ad hoc, similar actions take place once a prior agreement determined the time of call.

There is an assumption that there identification, authentication and authorization are used to ensure appropriate use of resources - this is not a "personal" direct connection, but a connection mediated by gatekeeper functions. It is also assumed that a concept of caller id may be used, that is, the call is not just accepted as in "Hello, who's this?"

There is an assumption that the individuals are "where they are supposed to be" - perhaps a mechanism for call forwarding or redirection would be reasonable. This then becomes a scenario addressing mobility with attendant issues of managing mobility.

Uniqueness
This is a basic scenario that sets the minimum standard, if you will, for video middleware: identification, authentication, and authorization integrated with gatekeeper functions. The scenario is based on endpoint enabled videoconferencing capability and doesn't necessarily imply any larger infrastructure beyond directories, gatekeepers, and end users. There is an implication of "billing and accounting" issues associated with endpoint and account objects.

1b) Title: Point to Point, Ad Hoc Videoconferencing Scenario, IETF SIP standards-based

2) Title: Interoperable Point to Point Ad Hoc Videoconferencing Scenario, H.323-to-SIP

3) Title: Multipoint Ad Hoc Videoconferencing Scenario, Centralized Control and Media Processing, H.323 **Active Development**

Description
Omar, Mary Lynn, Bill and Jill are from different universities, conference co-chairs for an upcoming seminar. Omar calls Mary Lynn and Bill via a videoconferencing device to discuss the plans. Mid-way in the call they connect Jill into the call for additional input.

Example
Omar, Mary Lynn, Bill and Jill are from four different universities in the region. They are conference co-chairs for an upcoming seminar. They are nearing the final stages or preparation. Omar needs to get feedback on some publicity plans including the layout model of the opening ceremony that has been brought to his office by his assistant. Omar calls Mary Lynn and Bill via a videoconferencing device and they discuss the plans for 30 minutes until they realize that they should get input from Jill. They connect Jill into the call and the four of them work through the details of the conference opening ceremony, including adjusting the layout model presented from Omar's office.

Generic format
Individuals use videoconferencing to work together. A multipoint connection is made via an MCU to enable simultaneous video and audio connections. Additional persons can be added to the call during the call, or individuals can drop out of the call. Connection information is looked up automatically by the videoconferencing device's gatekeeper that is closely integrated with LDAP directory services. The LDAP directory represents the people objects and resource objects such as individual classrooms or conference rooms that are videoconference enabled. Account objects represent individual accounts through which individuals access services. Endpoint objects represent the details of the videoconferencing equipment, including the MCU device that is being used for the call. The caller's identification and authentication is checked and authorization check ensures the caller has access to the MCU as well as other resources. Similar identification, authentication and authorization may be conducted for others who join the call.

• Gatekeeper integration with LDAP directory.
• Directory entries for appropriate data objects, such as people, resources and accounts.
• Authorization data must be associated with resources and accounts.
• Directory objects should be maintainable by end users and or administrator to ensure authoritative data.
• Integration between gatekeeper and directory should be synchronized at an appropriate level.
• Obviously, Multipoint Control Units (MCUs) are also required - raising issues of management of MCU attributes and integration with directory and gatekeeper infrastructure.

Assumptions
Assumption is that this is an ad hoc situation: the availability of the MCU and other devices is a given. If this were to be a scheduled call, then after the arrangements were made to time, the scenario would proceed similarly.

It is assumed that persons are "where they are supposed to be" - perhaps a mechanism for call forwarding or redirection would be reasonable. This then becomes a scenario including mobility of users with attendant issues of managing mobility.

Not addressed is the mode of the conference, whether chair controlled, continuous presence, and voice switched.

Uniqueness
This scenario extends videoconferencing middleware issues by the inclusion of Multipoint Control Units (MCUs) objects. Management of MCU resources becomes important, as far as: availability on ad hoc basis, discovery of the MCU resource, authorization to use.

4) Title: Multipoint Scheduled Videoconferencing Scenario, Centralized Control and Media Processing, H.323

Description
Omar, Mary Lynn, Bill and Jill are from different universities, conference co-chairs for an upcoming seminar. Omar's assistant schedules a videoconference call with Mary Lynn, Bill and Jill to discuss the final plans. The call arrangements are sent in advance to participants and the call is automatically started when the time arrives.

Example
Omar, Mary Lynn, Bill and Jill are from four different universities and are conference co-chairs for an upcoming seminar. They need to review the final plans and agree to schedule a videoconference call two weeks prior to the event. Omar's office assistant uses a web interface to schedule the call, resolving time zone differences and schedule conflicts of the participants. A final time slot is selected and the MCU and other resources are reserved. A reminder notice is sent to the participants and when the call time arrives, the session set up is automatically begun 15 minutes prior to the start time.

Generic format
Individuals use videoconferencing to work together. The schedule a multipoint connection is made via an MCU to enable simultaneous video and audio connections. An administrative function permits the scheduling of the call.

The connection set up may require coordination of time zones, participants' schedules, as well as availability of MCU and other devices. Set up also may involve setting format of the conference, whether chair controlled, continuous presence, voice switched.

Connection information is looked up automatically by the videoconferencing device's gatekeeper that is closely integrated with LDAP directory services. The LDAP directory represents the people objects and resource objects such as individual classrooms or conference rooms that are videoconference enabled. Account objects represent individual accounts through which individuals access services. Endpoint objects represent the details of the videoconferencing equipment, including the MCU device that is being used for the call. The caller's identification and authentication is checked and authorization check ensures the caller has access to the MCU as well as other resources. Similar identification, authentication and authorization may be conducted for others who join the call.

Needed components

• Gatekeeper integration with LDAP directory.
• Directory entries for appropriate data objects, such as people, resources and accounts.
• Authorization data must be associated with resources and accounts.
• Directory objects should be maintainable by end users and or administrator to ensure authoritative data.
• Integration between gatekeeper and directory should be synchronized at an appropriate level.
• Scheduling capability would include ability to reserve MCUs and other devices for future use.

Assumptions

• Assumption is that this is a scheduled situation that may require the availability of the MCU and other devices to be negotiated.
• It is assumed that persons are "where they are supposed to be" since this is a scheduled call.
• It is assumed this is a live event and no arrangements are made for recording the event for streaming simultaneously or for later on-demand service.

Uniqueness

• Scheduling of MCU resources becomes important.
• What is the implication for interfacing effectively with calendaring functions, such as calendars and time zones of resources or persons?
• Quality of service may become an issue, if scheduling causes conflicts among users and contention for "prime times."

5) Title: Multipoint Scheduled Videoconferencing Scenario, Centralized Control and Media Processing, SIP?

6) Title: Multipoint Scheduled Videoconferencing Scenario, Distributed Control and Media Processing

7) Title: Integrating Videoconferencing (H.323) to Streaming Video Scenario

Description
A live videoconference session is streamed live to enable viewing by those without higher end videoconferencing capability and also as a future saved archive of the event.

Example
An Internet2 Member Meeting is planned. Live videoconference capability will be available for the event, permitting remote users with access to appropriate MCU and resources to participate in two-way mode with the events live. Additionally, the conference is simultaneously streamed to extend the conference (one way visual only) to a wider audience. This stream will be retained as well as an archive of the event that may be accessed "on-demand."

Generic format
A live videoconference is also captured for streaming. The streaming may be in parallel with live event or for later "on-demand" use.

People and organizations often perceive streaming video and video-on-demand (VOD) as being not only alternative modes of participation in live videoconferencing events but also as separate communications modes of their own.

In some ways streaming video communication can be viewed as a superset of real-time videoconferencing with

1. Higher quality audio and video
2. Archival recording (and playback) capability
3. Generally no-cost or marginal-cost ubiquitously available viewers that do not require hardware additions
4. Inherent support for parallel streams of overheads or other supplemental visual channels
5. Generally higher latency
6. Generally higher bandwidth quality and quality requirements

In this view, an event worth supporting with videoconferencing access is also routinely streamed live and captured with the highest capture quality possible for later encoding in a variety of rates for viewing on-demand. The live streams make it possible for people anywhere, who will not have real-time H.323 equipped systems available to them, to participate actively with an audio and video feed of the event and with a telephone or text based back-channel for their interaction. The VOD files made available immediately after the event make it possible for remote participants to refresh aspects of the event or to review material for more intense study.

Needed components

• For the primary interactive sites, H.323 (or H.320) endpoints and appropriate network connectivity are needed.
• For people participating via stream modes, needs include a PC with a stream viewer client, appropriate Internet connectivity and whatever back channels may be desired or required.
• A special head-end H.323 system with the capability to provide an output of both the local screen video (cf. a single-display H.323 system) and a mix of the local and remote audio is then connected by dialing a connection to the H.323 MCU. Its special logging output is always connected through distribution amplifiers to relevant stream encoders and servers.
  

Assumptions

• Users participating in streaming will of course not have full two-way interaction capability that is available with H.323 modes. However, it is possible to use phone bridge to permit some level of two-way audio that can supplement the streaming.
• We assume that the same requirements for gatekeeper and directory services integration is part of this scenario. Are there additional issues related to streaming? Is there possibly a quality of service issue depending on the demand for the streams? As a bandwidth conserving strategy, VOD file presentation can be delayed until the completion of a period (1-2 days, for example) of scheduled multicast rebroadcasts (say, eight times per day/night) to attempt to satisfy short-term review demand with lower impact multicast, rather than unicast, network transport.
• To what degree are indexing and archiving issues addressed? This assumes a very simple mechanism, such as listing a stream player option next to the schedule of the live event. Searching for the topics or indexing the stream itself is not addressed.
  

Uniqueness
This raises the bar on "live" videoconferencing requirements. Issues are now included relating to simultaneous capture, additional equipment needs, and managing possible bandwidth contention. Managing videoconferencing assets resulting from live events becomes important. This scenario can be viewed as an overlap into the area of VidMid, Video-on-Demand working group.

8) Title: Integrating Videoconferencing to Streaming Video Enhanced Interactive Scenario

Description
A security camera monitors the high security area of the university's operations center that also manages the enterprise certificate authority and PK infrastructure. Security cameras provide live video to monitoring stations and a streaming capability ensures that any suspicious events can be reviewed immediately. A two-way videoconferencing capability provides additional authentication and authorization security.

Example
A university's operations center that also manages the enterprise certificate authority and PK infrastructure requires 24x7 monitoring of all access to the operations room. Several security cameras provide live video to several monitoring stations. A streaming capability ensures that any suspicious events can be reviewed immediately, without interrupting the live video. Individual cameras may be controlled by authorized operators. Additionally, the university's CIO has the capability of back stream videoconferencing so that two-way real-time visual authentication can occur between CIO and the monitoring station or operations personnel.

Within the live-access situation there are several components. Initially a user (security personnel) needs to be authenticated and authorized to access a (set of) camera(s) and any associated alert systems. Once alerted, or on-demand/browsing, the user then needs to access a particular camera (implying a choice of video source), jump between cameras (tracking situation) and also drive the cameras that support pan-tilt-zoom (PTZ) operations. Certain actions require that visually verified authorization be obtained. A videoconferencing capability exists between the CIO's office and the personnel in operations and/or the monitoring stations.

Generic format (optional)

Needed components

• The need to support multiple users accessing the same camera (e.g. several police tracking a suspect, but who controls the camera's PTZ?).
• The need to encrypt/sign the actual stream (avoid middleman problems, where the stream is either tapped or altered.)
• The need for variable levels of access required, depending on the user and the infrastructure (new users, part-time private security vs. full-time police, high-res/low-res cameras, white light/infrared, with/without PTZ, etc.) Identification, authentication, and authorization are critical.
• The need for real-time parallel archiving of the video, including indexing (tagging with time/location metadata) and potentially encryption of the archive. Meta information would include journaling and auditing of control/access information (who drove the camera that way, who was watching this particular scene?).
• One aspect of accessing the archive that may be different to other VoD scenarios is the requirement to do so extremely quickly. It needs to support the "Hey, what just happened?" question common in security situations to initiate tracking and/or reaction by security personnel. If it takes several hours/days to archive and index the content it becomes useful for evidence but not for reaction. Similarly if it takes 10-30 seconds for a recorded stream to start playing it is also too slow. This may require a two-tier archiving system, where the first tier is effectively a smart/continuous cache of live content, and the second tier is your more traditional content archive. Content needs to move (in a trusted but rapid fashion) between the live/tier-1/tier-2 systems.
  

Assumptions
Important to have:

• High level security
• Interactive manipulation
• Auditing of actions

Uniqueness
See Needed Components. This scenario adds highest levels of security and encryption, need for full interactivity, and fast response requirements. This scenario is complex but serves to illustrate a desirable end goal. This scenario can be viewed as an overlap into the area of the VidMid Video-on-Demand working group.

9) Title: Mobility and Media Switching in an in-progress point-to-point ad hoc videoconference

Figure 1: SIP scenario

Description
Bob invites Alice for a videoconferencing session to finish a paper they are jointly co-authoring (see Fig. 1). Bob and Alice start discussing the last meetings action items. After 30 minutes, Alice remembers that she has to pick up her daughter from school, so she invites her own cell-phone to this conference, and talks to Bob over the cell-phone for the next 20 minutes. After that, she enters her home, and transfers the session to her home PC. They further discuss the rest of the paper.

Example
Bob@cgu.edu invites Alice@unc.edu to a videoconferencing session to work jointly on a paper. Alice has several ideas to discuss with Bob, however, she knows that she will have to pick her daughter up after about 30 minutes into the call. She simply informs Bob that she is switching to her cell-phone (audio only) and they continue to discuss while Alice is driving to the elementary school. After sometime, Alice enters her home, informs Bob that she is putting him on hold, redirects the call to her home PC (that has DSL access) and terminates the cell-phone conversation. They continue to use video/audio for the rest of the discussions.

Generic format (optional)
Two individuals Bob and Alice use a SIP User Agent (either a soft-videophone or a hard videophone) to establish a video-conferencing session. Both are registered to their local domain SIP registrar that maintains bindings of their email type SIP URI and their present IP addresses. Bob can input Alice's SIP URI from three places: i) type the address, ii), lookup from the User Agent personal address book or iii) lookup an campus-wide directory server (using LDAP). This campus-wide directory server contains names and their SIP URI bindings for people who can be called using voice or video-over IP. The LDAP directory may also contain domain names and IP addresses of various infrastructure servers like the local SIP proxy server. When Alice@unc.edu accepts the call, SDP negotiations agree upon a video codec to be used for the call and both parties connect using media/RTP/UDP/IP. While the call is in progress, Alice initiates another call from her soft-videophone to bring in her own cell-phone into the call. The session only requests an audio feed. An MCU mixes all three users (Bob, Alice, Alice's cell-phone) appropriately for a brief time until Alice terminates her desktop session. Now Alice on her cell-phone and Bob on his desktop switch back to a point-to-point voice only session. Obviously, the IP packets are routed through gateways provided by a third party (Level3 for example). When Alice reaches her home, she initiates another video call to connect to Bob and they continue the session. The cell-phone end-point is terminated.

Needed components

• Proper integration of SIP proxy and registrar server with a suitable LDAP directory server.
• Directory entries may refer to end-users with their SIP URIs as well as resources such as SIP servers.
• When 2-party call switches to 3-parties, MCU must seamlessly come into action. However, when the call again reverts back to point-to-point, MCU releases control.
• Configuring proxies with proper IP-telephony gateway IP addresses will be required.
• Some billing/accounting info may also be needed to be maintained.
  

Assumptions
This is an ad hoc situation where one user moves across end-user device and media type as call progresses. SIP and its registration service handles most of the end-user mobility part. Alice's end-point should have a rich user interface via which she can put one call on hold, make another call and transfer or redirect as she pleases.

Uniqueness
This scenario presents a sophisticated mobility environment which is quite typical in our daily lives. It also brings out some of the power of SIP signaling. Managing mobility, managing media switching, phase-in and phase-out of MCU management, whether to use MCU in this case or maintain simultaneous streams, discovery of gateways, MCUs and proxies all become important.

Extended Scenario
Integrating the above scenario with a presence server. Presence server (similar to instant messaging) lets end-user know the status of a person logged on to the net. The person is there willing to accept calls or simply busy now and will reject any calls. The presence information can be displayed right on the soft-videophone user interface or can be looked up from a presence-enabled directory service. This gets into several exciting areas of integrating directory servers with presence servers.