SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call March 02, 2006

*Attendees*

Dawn Augustino, University of Pennsylvania
Dennis Baron, MIT
Steve Blair, University of Pennsylvania
Candace Holman, Harvard
Jeff Kuure, Internet 2
Don McLaughlin, UCSD
Christian Schlatter, UNC Chapel Hill
John Todd, Tello
Dave Zimmerman, UC Berkeley

*Discussion*

Today's call features a presentation from Dawn Augustino and Steve
Blair, who provide an overview of the University of Pennsylvania's VoIP
system. Dawn, the project manager, begins by providing some background
information. Penn is a Centrex environment with approximately 25,000
phone lines for which they own the cable infrastructure. All of their
current telephony systems are beginning to show their age and required
replacement. Prior to Dawn's arrival last March a lot of initial
research into various VoIP products was done, with the final decision
being made for SER for proxy services and Asterisk for voicemail and
some media services.

A campus pilot was started in October of 2005, with a full
production-ready system already in place, including billing and the
handling of trouble tickets. While this is still being treated as a
pilot, they intend to transition the pilot system into a full production
system. With their Centrex system, everything was outsourced to Verizon,
so this is the first time that Penn has operated their own services. They
started with 25 users, and are adding approximately 75 per month with
a goal of 850 by June.  These users are all faculty and staff, as most
students are reliant on their personal cell phones. Dawn envisions that
in the future they may provide only emergency hallway phones for students
in dorms.

Dawn is asked about user interface tools, which seem to be a stumbling
block for other institutions. Penn has created their own tools to
provision their services. Existing web-based tools didn't quite meet
their needs, so custom software was developed in Perl and PHP which
allows users to manage their telephone settings via the web. Using
open-source software such as SER and Asterisk makes it easy to develop
such tools. Additionally, Penn was able to utilize the existing help
desk and centralized support systems for telephone system support.

Don McLaughlin asks if Penn has standardized on any particular soft
phone. Currently they are only using hardware phones, namely the Cisco
7940. A soft phone pilot will begin in August of this year, and they
are looking at issues for E911 compliance with soft phones. All location
information for hard phones is stored centrally for the hard phones with
updates made to the PSAP daily for 911 service.

Dennis asks if any features were gained or lost during the transition
from the old system to the new VOIP system. Dawn says they are currently
only setting up single-line systems with no multi-line or bridging
services. One missing feature is the ability for users to assign
priority to voicemail messages under the old system. On the other hand,
the integrated messaging is seen as a real benefit, as is access to
telephone settings via the web. Users can, for example, change their
call forwarding and voice mail-to-email integration from home. They are
doing a controlled rollout of new features, to see what customers like
and will use as well as what cost is involved.

Steve is asked how they are managing for TOS between the endpoints and
the core. Penn is a multi-vendor environment, so all switches and routers
are competitively bid from different vendors. Starting at the wall plate,
the closet switches are all Extreme Networks Summit switches. Beyond that
is a layer 2 or layer 3 multimedia type device, usually a Foundry Network
BigIron box. The routing core is made up of Cisco 7609 routers. Because
they can't set the TOS with the config files in the IP phones, frames
that arrive at a port with a phone attached are remarked. These "magic
ports" are assumed to have voice service and have specific VLAN settings
and TOS handling. At the ingress ports, the 802.1p class-of-service bits
are remarked with a 5, and the IP precedence bits are also remarked. On
the egress port from the switch to the port, the markings are used to
put the frames in a specific hardware queue for transmit. These markings
are honored all through they layer 2 network until they get to the first
router port. These packets are remarked again to ensure preferential
treatment when the arrive at another layer 2 network.

Steve says that they are not using the Cisco 7940's TOS bit configuration,
as these packets can't be remarked on-the-fly unless you also use Cisco
switches. These bits are set to a default value of 5, but this bit is
not trusted coming in. Instead, the port that the phone is attached
to is trusted. This is not ideal, but works if people adhere to the
"magic port" voice port model. Because they are a distributed computing
environment and layer 2 has a wide variety of traffic, they try to ensure
that voice gets preferential treatment.

Christian asks if phones are locked to specific ports to prevent customers
from moving them around. Dawn says that they are not, so all customers
must sign a terms and conditions notice, noting that 911 service is
dependent on power outages and network congestion and that they are
responsible for updating information if the phone is moved. On the
network side, they are looking at ways to dynamically locate a phone,
but this isn't reliable enough to trust. Allowing users to set location
with the web interface is in the plans.

Steve is asked about TLS or SRTP, which are not currently deployed as
they have not yet had a change to seriously look at security. They are
looking at SRTP as well as access control and ways to limit DoS attacks.

Dave Zimmerman asks if anyone has thought about 802.1x authentication
and how it might converge with phone location. Steve says that this has
been considered for some system where the user logs in to the phone. But
phone manufacturers don't support this and they don't know how to keep
this secure to prevent the phone from being compromised. Additionally,
the problem of alphanumeric entry on telephones is also a limitation.

Dennis asks about PSTN access and trunking. Steve says that there are 2
Dell Poweredge 1850 servers running Red Hat Enterprise 4 in physically
different locations on different subnets. One is the primary proxy
and the other is a warm spare, and each has their own MySQL database
of subscriber information. There are also two separate media servers,
with one serving as a cold spare. Only one machine can mount the storage
array filesystem at a time, so one is on standby and someone must manually
intervene and log in to the console to switch them over. Both are run
Asterisk, which works out well as they don't have to worry about data
replication. On each subnet is a Cisco 2620 gateway with one T1 vwic
card, which is connected to a PRI which goes to Verizon's Philadelphia
switch. All local, long distance, and 911 calling goes through this PRI.

Christian asks if they considered using Asterisk for the gateway. Steve
says that they were familiar with Cisco routers, and there were no
cost or performance issues as these are low-end boxes. Each time Penn
chooses a new gateway, they choose something at the lower end of the
scale to minimize the cost for connecting to Verizon or anyone else with
TDM connections. They want to move to a situation where they peer with
carriers via a metropolitan area IP connection. Being in a urban area,
they have access to a high-capacity connections in a carrier hotel.

Steve is asked if the PRI is separate from the Centranet. They're
separate, and they've run into cross-compatibility issues when a user
calls from an IP phone to a Centrex phone. These calls go out the
PRI and back in through the DMS100s, and appear to be to an unknown
caller. People aren't used to this, and there's nothing they can do to
change this issue. Full caller ID is only passed through the IP cloud -
once it leaves the gateway they only pass the number, as Verizon drops
the name field anyway.

Steve forgot to mention that each gateway is collocated with each of the
proxies. Each proxy tries the local gateway first, because it's riskier
to cross the routing core to try the backup.

A question is asked about any name-to-number mapping. This can be done,
but is not offered as part of the service. The SIP.edu implementation
is a separate and distinct proxy, and is not tied in to anything being
discussed today. Some day this all may be merged, but in the short term.

As far as peering, Penn has a layer 2 connection between the university
and the carrier hotel, and they define multiple VLANs that cross that
connection. Each VLAN is a BGP peering session with some carrier's
network. They are looking at different carriers now, and will select
one in a couple of months. This is for IP transit right now; they are
thinking about handoff and termination but have made no decisions.

Dennis asks about a business model and cost recovery for this
implementation. Dawn gives a brief summary; they are doing a
return-on-investment analysis. With the Centrex model, they pay a higher
cost per number but this includes all features. Under the new model,
they still pay per number but provide all the features themselves. Penn
already has a good data network, so this means that they don't continue
spending money on the copper network. Over 3-5 years, the service starts
paying for itself. Moving to IP means they must start charging customers
for a data connection that they didn't use before, or for one that they
already have for a computer, so there are some billing issues. It costs
a bit less after 5 years, but they are not doing it to save money -
they want to provide an integrated telephone service and provide more
features. In an old urban center, it's hard to do changes to physical
voice networks.

The overall goal is to have a telephony architecture similar to
the network one, where it does not depend on any proprietary vendor
solutions. They would like to be able to pick and choose between carriers.

Finally, Steven and Dawn are asked if they have considered open-sourcing
the management tools. Currently, the system is based on Penn's integration
system, but it could be made into something more modular. They would
like to distribute this as an open-source application, but would have
to investigate. They will also provide screen shots.

Dennis asks if anyone will be at VON, which is in two weeks. He and Ben
will be there, and plans are to hold a call as normal.

The next call will be on March 16th.