| Authors: | ||
| Markus Buchhorn Information Infrastructure Services Australian National University Canberra, Australia Samir Chatterjee Art Vandenberg |
Egon Verharen James Whitlock Mary Fran Yafchak |
|
| Editor: Steve Olshansky, Internet2 | Comments/Discussion to: VidMid-VC@internet2.edu | |
The scenarios below are selected as focus areas for the VidMid workplan. Their inclusion here resulted from extensive review and discussion of various scenarios:
The following three scenarios are presented as meeting the above requirements, with these notes:
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
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.
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.
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.
· 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.
Advanced Feature - Scheduled Video Conference
The conference call is scheduled in advance, which entails issues of administration,
coordination, and reservation.
Advanced Feature - Possible Issues for Scheduled Video Conference
Administrative functions should address:
Advanced Feature - Additional Needed components
Advanced Feature - Assumptions
Advanced Feature - Uniqueness
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 a 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
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 handle 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 that 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.
Advanced Feature 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.
Note that the above scenario mentions SIP as specific protocol, but an advanced
scenario involves other protocols (such as H.323) and addresses situations where
users may have different environments at their locations. For instance, Alice
at UNC may be operating in an H.323 reference model while Bob at CGU may be
in SIP specific domain.