SIP in higher education

[Garret Yoshimi <>]

Hi folks,

Thanks again to Tyler Johnson for presenting a summary of the Internet2 
RTC Advisory Group activities on our 1/18/2007 call.  Notes from the 
call are included below (thanks to Jeff Kuure).  RTC Advisory Group 
information and documents are available at  http://www.internet2.edu/rtc/ .

Best regards.
Garret, Walt, Candace & Dennis

- - - - -

SIP.edu / VoIP SIG Conference Call, January 18, 2007

* Attendance *

Jay David, University of Rhode Island
Tyler Johnson, University of North Carolina
Walt Magnussen, Texas A&M University
Scott Morningstar, University of North Carolina
Chris Norton, Texas A&M University
Leo O'Shea, Boston College
Christian Schlatter, University of North Carolina
John Stier, Stonybrook
Jonathan Tyman, Internet2
Nick Wachowskii, Michigan State University
Garret Yoshimi, University of Hawaii

* Discussion *

Today's call features Tyler Johnson of the University of North Carolina 
providing an overview of the work of the Internet2 Real Time 
Communications Advisory Group. The group recently completed their 
efforts and presented their findings at the Internet2 Member Meeting in 
Chicago. Tyler chaired the group; Walt, Garret, and Jonathan also 
participated in this group.

The RTCAG was charted in 2005 by the application strategy council and 
grew out of various observations and frustrations within Internet2, 
particularly a lack of coordination between various projects with 
similar goals. Tyler mentions that there was a notion within Internet2 
that at some point in the future, a person would be able to click 
something and be in instant communication with anyone else, which 
obviously has not happened. Videoconferencing currently requires a lot 
of work and equipment to set up, and VoIP systems are not well 
coordinated and tend to exist in various "islands". Tyler cites the 
existence of multiple differing dial-plans such as ISN, GDS, and E.164 
as an example of this lack of cohesiveness, and feels if so many 
projects are headed in the same direction they would benefit from 
collaboration.

The group also desired to present a unified front to vendors, who in the 
past have heard mixed messages about what institutions want in new 
products. Tyler notes that the group is sensitive to the fact that they 
represent a large, diverse community and that full agreement between 
various parties is impossible. The main focus is on broad architectural 
and strategic operations in the short and medium term. The group 
concluded their work at the last Member Meeting and has presented their 
final report and deliverables, which are available at 
http://www.internet2.edu/rtc/.

The first link on the RTC site is to the executive summary, which 
provides an overview of the deliverables and how they can be used. One 
of the items produced is a reference architecture, which aims to provide 
a comprehensive list of items that a campus should be addressing in 
their own RTC architectural plans. There is also an architectural 
checklist, which is a bulleted list of items from the reference 
architecture. This checklist is meant to be used as an internal 
assessment tool as well as a tool for mid-level managers to argue for 
attention to specific resources.

Tyler also suggests that the checklist can be given to vendors to 
evaluate how their products will interoperate with other systems. 
Vendors may not always like this, as they might be using proprietary 
technology while the RTC group focused on open standards. If every 
institution uses products that meet these requirements the level of 
interoperability will generally be very high. This is meant to send a 
message to vendors, as multiple institutions requesting the same 
features will be harder to ignore.

The checklist can also be used within Internet2 to evaluate proposals 
for new initiatives and workgroup structure. For example, the PIC 
working group is looking into XMPP and federations, and this checklist 
can prevent PIC efforts from heading in different direction from other 
Internet2 working groups. Within working groups, the checklist can be 
used to evaluate products from various vendors. These evaluations could 
be shared in an organized way to create a repository of vendor products 
and system. Jonathan Tyman expressed interest in setting up a formal 
system for storing these evaluations, as there has been a great deal of 
interest in this.

Walt feels that this would be a great opportunity for VoIP SIG members 
to take on these evaluations themselves, by working with an account 
representative from a particular vendor to fill out the checklist. 
Having vendors self-evaluate is one thing, but Walt would also like to 
see evaluations from the people who use and configure the systems and 
have more insight into the benefits and drawbacks of particular 
products. Tyler feels that he would like Internet2 to remain fairly 
neutral in this regard, and does not want to do any official testing and 
evaluation. Jonathan offers to bring up a wiki for this purpose, which 
Tyler thinks would be a good idea.

Tyler returns to the list of deliverables, and mentions the fourth item 
which offers guidelines for activity alignment. Internet2 asked the RTC 
group to look at how other working groups were structured. There is 
currently a lot of reorganization and restructuring going on within 
Internet2, and these observations should be viewed only as a guide.

A question is asked about a Word version of the checklist. Tyler says 
that there is a link to one on the site, as others have asked for the 
same thing. This could be emailed to vendors for them to fill out and 
return.

The next item that Tyler discusses is the reference architecture. The 
document is nine pages, which he feels is short for something that 
aspires to describe an RTC infrastructure, but long for a summary. He 
notes that this is not only for VOIP, but a next-generation architecture 
for IM, voice, video, data collaboration, or any other application. 
Voice over IP might be a way for institutions to ease into the other 
applications, and this reference aims to describe a common set of 
functionalities for campuses to interact with other campuses.

This document covers signaling, which focuses heavily on SIP with the 
understanding that people will still use H.323. XMPP is also identified 
as an important protocol for IM and presence. The architecture discusses 
middleware and notes the importance of IT organizations having strong 
capabilities with middleware to glue other functions together. There are 
also recommendations for addressing, with an acknowledgement that 
further work needs to be done in terms of building consensus around 
addressing schemes. Recommendations are also included for authentication 
and authorization, with a mention that campuses should be preparing now 
for an interdomain federated approach using a protocol like SAML. Other 
recommendations focus on directory services with H.350 and identity 
management, security, encryption, and privacy, and for denial of service 
attacks and SPAM, which are tied in with federation.

Disaster recovery and business continuity are also covered in the 
reference architecture, as is multipoint conferencing, which seems to be 
of interest to both video and audio groups. There are recommendations 
for data collaboration, which is a contentious issue. Garret says that 
the industry seems to be heading towards walled-garden systems as 
opposed to more common approach, so this area is quite fragmented.

Presence is discussed, which Tyler says is still a nascent area. 
Location services are also covered, and this issue seems to be 
interpreted quite differently by different groups. Groups focused on 
VoIP tend to think of this only in the context of 911, while instant 
messaging people think about other applications and how reliable and 
accurate it might be.

Other recommendations cover accounting, firewall and NAT traversal, and 
identity management for directory-enabled VoIP systems, which have 
different requirements for affiliates and credentials. Staffing and 
operational planning are also covered, with the intent of helping 
high-level IT management move from traditional telephony to VoIP and 
other real-time communications. Finally, there is some information and 
potential direction for regulatory concerns including CALEA, 911, and 
law enforcement.

Following this overview, Jonathan presents the group with a real-world 
problem. Recently the board of directors told him that they want to stop 
using POTS for their occasional conferences and want to use a 
full-fledged collaboration tool which includes video. Tyler says that 
UNC, Columbia, MIT, and UPENN have been working to develop their own RTC 
architectures based on the RTCAG recommendations. Christian Schlatter 
has put together a system using OpenSER, Asterisk, and Counterpath 
eyeBeam clients in conjunction with Tandberg video conferencing tools 
and phones from SNOM and Polycom. They have started to pilot the system 
to other users, and find it to be stable and relatively low-cost. 
Christian feels that the only missing element is something for 
data-sharing, mostly because there are not standardized solutions. 
Screen-sharing is a possibility, but he would like to see something SIP 
based. Tyler says that he has been using VNC lately for sharing.

Jonathan feels that his situation is an interesting scenario, as it is a 
perfect opportunity to sell this architecture to the people who make 
decisions. These are top-level university staff, specifically asking for 
exactly what everyone involved with SIP.edu and the RTCAG have been 
working on. He asks about ways to turn this project into something that 
generates support and visibility. Tyler suggests hosting a meeting and 
providing trial access, or building a system at the upcoming Commons.

Mike from CommuniGate asks if Asterisk does media proxying for video in 
Christian's system. Christian says that they don't use Asterisk as a 
PBX, only as gateway servers and for voicemail. Since SIP is a 
peer-to-peer protocol, they are using OpenSER as a proxy and all media 
is done peer-to-peer, including video. Mike expressed interest in 
working with Christian, and says that their upcoming software release 
has full support for video proxying. Tyler says that he would be 
interested in testing this.

As a final note, Jonathon says that Polycom is looking for people to 
beta-test their new unreleased SIP client. If anyone is interested, they 
can contact him.