PIC-SER Trial report for the MIT Plasma Science and Fusion Center.

Background:

1. Deployment Environment - nature of collaborative activities, team size, team location(s), degree of mobility, technical savvy of users, unique characteristics

We hoped to deploy this to a significant subset of our scientific
research group. We are a group of approximately 50 scientists and
engineers, collaboratively operating a physics experiment. The
experiment operates about 20 weeks per year, 4 days per week for 8
hours per day. The group is mostly located here at MIT, but we have
significant outside collaboration, both US and elsewhere. While the
experiment is operating a high degree of communication between sub
groups of the experimenters is desirable. Presence, instant
messaging, audio phone, and video conferences would positively impact
the work that we do, especially for those collaborators who are
off-site. We currently use telephone, jabber, H323 and AccessGrid
video conferencing for this purpose. Integrating these tools would
make them even more useful. Of particular interest to us is the
ability to get our voicemail delivered as email.

2. Technical/Computing Environment - network topology, QoS status, server details, client details, audio/video peripherals._

All testing was done using eyebeam under windows-XP. We attempted to
get the wave3 session client working with no success. Differences
between the beta eyebeam we were running, and the older beta being
distributed added to the confusion about what was working, and what
was not.

Deployment:

1. Installation Experience - client/server issues/problems, comment on help resources, documentation. Did the installation process live up to your expectations? Any suggestions for improvement?

The pic-ser kit was installed on a machine running a clean install of
RHEL4. The initial installation failed, and left erroneous entries in
some of the database tables which hold account information. These
prevented subsequent installation attempts from succeeding, until
these tables were cleaned out by hand. Once this was done, the
installation went smoothly. A significant issue was that the code was
built against an older SER distribution than we were running in
production. This limited our interest in it.

2. Did you integrate PIC-SER with any existing campus communications or IT assets (e.g. a PBX, an existing VoIP deployment, a campus directory, a campus authentication infrastructure, a location service, a calendaring or scheduling application)?

No. See (1) code version issues.

Usage:

1. Describe the usage patterns, user feedback, interesting use cases.

I am sorry to say that we had no significant use of the package. It
was not clear that there is a compelling added benefit for distributed, as opposed to peer to peer, presence information.

2. For most users, was this their first exposure to campus/enterprise IM & presence?

See (1)

3. Would extending the offering to mobile devices be powerful?

In general being able to 'find' people and talk with them over the
best (most appropriate) medium available would be very interesting and
useful to us. Users would definitely want some degree of control on
how and when communications are forwarded to mobile devices.

4. Would the addition of more detailed presence information in the system such as location and schedule be of value.

Integrating schedule / calendar information with the presence
information would be useful. One issue is that in order to get real
benefit from it, all of the interested people would need to adopt the
tool and use it. It would have to be extremely easy to use and keep
up to date. Location would be useful. In particular in the case that
it makes users presence (or absence) state automatic. There may be
some resistance due to privacy issues. See (5) below.

5. Comment on the privacy concerns in your environment.

In general users here are willing to put aside their privacy concerns
in the interest of effectively operating our experiment. They are
only comfortable with publishing their presence information during the
limited periods that the experiment is operating. At other times the
they would be willing to publish less information about the presence
and location.

Results:

1. Was the trial valuable?

No not really. The fact that the distribution was based on an older
code base than our running system, as well as problems with versions
of the user agents prevented us from making a really meaningful
trial. Computer based user agents (soft phones) are clearly the
correct solution, being configurable, programmable, and extensible.
That said, the success of these tools is highly dependent their
ergonomics, which are lacking.

2. Would you consider expanding the installation to larger groups?

No, not really.

3.Is there sufficient added value over consumer services such as AIM, Yahoo!, or MSN to warrant deployment as a campus service?

In general these services would be sufficient to our needs with a few
exceptions. They do not provide bridges to POTs telephone. They are
not under our control, so it is not clear that we could count on them
to provide services which are critical to our operation. They are
limited in scope and not expandable. We are very interested in things
like third party calling and application sharing.

4. What could the PIC-SER team do to improve the offering?

Base your distribution on the current head of the source tree for the
tools in question. Useful presence tools need to be cognizant of the
ways in which users actually behave. For example, signing in with
multiple user agents, leaving or arriving without updating their
presence information. Finding or developing really good user agents
would help with user acceptance. These tests can only be done with a
significant user community on board.

Josh Stillerman
MIT Plasma Science and Fusion Center
jas@psfc.mit.edu
sip:jas@psfc.mit.edu