Skip to Content.
Sympa Menu - Notes from 1-18-2007 call with Tyler Johnson

Subject: SIP in higher education

List archive

Notes from 1-18-2007 call with Tyler Johnson

Chronological Thread 
  • From: Garret Yoshimi <>
  • To: Internet2 VoIP SIG <>, "Internet2" <>
  • Subject: Notes from 1-18-2007 call with Tyler Johnson
  • Date: Tue, 30 Jan 2007 12:57:23 -1000

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 .

Best regards.
Garret, Walt, Candace & Dennis

- - - - - / 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

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 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.

  • Notes from 1-18-2007 call with Tyler Johnson, Garret Yoshimi, 01/30/2007

Archive powered by MHonArc 2.6.16.

Top of Page