SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call February 02, 2006

*Attendees*

Derrick Abrams, Oregon State University
Dennis Baron, MIT
Candace Holman, Harvard
Jerry Keith, UC Riverside
Jeff Kuure, Internet 2
Mark Silis, MIT
Christian Schlatter, UNC Chapel Hill
Ben Teitelbaum, Internet 2
Chris Trown, Oregon
Mike Van Norman, UCLA
Garrett Yoshimi, Hawaii
Dave Zimmerman, Berkeley

*Discussion*

Today's call begins with Mark Silis presenting slides on MIT's SIP
implementation. The slides are available here:

     http://mit.edu/sip/presentations/mit-sip-edu.pdf

The infrastructure is broken into several components, including an
outgoing SIP proxy for authentication and authorization, an internal
SIP proxy for isolating internal calls and better performance, and a
DMZ SIP proxy to provide SIP connectivity to external clients. There
is also a media proxy to support voice calling over NAT devices; a
RADIUS server which provides authentication, among other things; an
Asterisk server for voicemail and conferencing; and Cisco gateways for
connection to the PSTN.

MIT is using OpenSER for the SIP proxies, which Mark believes to have
more active development than the Iptel branch. It is running on Red
Hat Enterprise Linux, with an outgoing proxy for authentication and
authorization. The primary entrance is redundant through the use of F5
load balancer.

Mark is asked about redundancy, which he says is accomplished with
load balancing and failover. SER state is maintained by replicating
the registrations and maintaining the location information. They've
not had any problems with stability. Each node has their own
database. There is no IPv6 implementation, as MIT has a class A
network and has no immediate need for IPv6.

The media proxy was not in the original design, but it was determined
to be necessary later in order to support NAT clients. It uses the
media proxy module for SER which then inserts a MediaProxy server for
NAT traversal.  MediaProxy is written in Python and from the AG
Project.

Mark is asked about call handling, transcoding, and video support. He
believes that the system can handle 500 G.711 calls, but it should
scale easily by adding additional inexpensive Intel computers. He
believes that it does transcoding, but would have to double check. The
media proxy also is capable of handling video, but he has not tried
this. [After the call it was determined that the current version does
not do transcoding.]

The RADIUS server provides authentication and authorization, and
maintains call accounting records. It has been a key piece of the
infrastructure, as it allows for accounting and integration with the
backend Oracle database. MIT uses FreeRADIUS, and redundancy can be
achieved with a pool of servers.

A question about billing is asked. Mark says that CDR records are
stored in a database, so calls could be billed easily or could be
integrated with MIT's ERP system. Dennis mentions that billing is
something that they will do eventually but has political and privacy
concerns that need to be addressed. They are seeing less demand for
detailed accounting as phone calls become less expensive, but there
still is a faction that would like to account for everything.

Mark goes on to discuss Asterisk, which he refers to as the "Swiss
Army knife" of the SIP setup. Asterisk is the open source IP PBX, and
it supports several VOIP protocols. It was first used for voicemail
service, and now also provides voicemail-to-email service and
conference bridge service.

The connection to the PSTN is through a Lucent 5ESS PBX; soon they
will be moving to a Cisco AS5800 platform. MIT is also using the Cisco
RPID field for PBX/PSTN caller ID.

The second to last slide provides a graphical overview of the system;
Dennis mentions that it should probably be redone as the
infrastructure has changed from the initial design.

Mark is asked how everything is connected together in terms of
switches and routers. He says that each layer is switched, depending
on where on campus it is located. The components are located together
on a switched network but replicated at a geographic diverse location
to provide redundancy.

Finally, Mark discusses the management tools which have been developed
for configuration and user management. The management application is
built on Apache, Oracle, and X.509 certificate authentication, and
allows users to customize their SIP accounts through a Web
interface. Dennis mentions that he would like to possibly have a
future call to demonstrate the web interface.

Mark finishes up by mentioning that he can be contacted with any
questions at 
.

The remainder of the call is devoted to Dennis discussing the
Real-Time Communication Advisory Group which has been mentioned in
previous calls. He, along with Garrett and Ben are members. The
commission was set up to develop a path for Internet2 universities for
developing and advancing real-time communications and to coordinate
activities between different working groups. The group is chaired by
Tyler Johnson at UNC.

One major activity of the group, besides getting people together to
talk, has been to work on a document showing a roadmap for campuses
which will hopefully be done by the Spring Member Meeting. There has
been some good progress with several people contributing. There was a
first draft deadline at the end of January, and pieces are beginning
to appear, with editing work to commence soon.

One of the other issues that has come up is that people are looking
for broader input for the RTC group and Application Strategy Council,
particularly questions about what Internet2 should be doing in the
next 12 and 36 months - what initiatives, services, functions,
real-time communications issues or concerns that Internet2 could help
to address.

Derrick from Oregon State mentions that they encounter Internet video
and wonders how to deal with video traffic needing to communicate on
various ports, without opening too many ports in their firewalls. He's
interested in seeing some sort of best practices for Internet video,
or for ways to narrow the number of ports used by video applications -
not so much for bandwidth management as for connectivity issues.

Derrick also mentions the idea of SIP trunking between
universities. This leads into a discussion about the regulatory
implications of recent FCC rulings regarding CALEA. Ben mentions
confusion on the part of participants with regard to the rulings
concerning yet to be specified technical requirements and a lawsuit
that many institutions are party to. The final outcome has not been
determined, but he believes that there is no need to be particularly
timid as he does not see SIP as being a replacement for the
PSTN. Dennis thinks that organizations should avoid being blatant
about any alternate paths that can be used for voice traffic, but they
don't necessarily need to hide what they're doing.

Ben believes that the current direction is that campuses need to be
CALEA compliant. The Department of Justice considers the language of
the FCC order to be more inclusive and expansive than others, but
until the FCC says what exactly is required of universities no one
knows what needs to be done.

The next call will be on February 16th.