SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call August 17, 2006

*Attendees*

Dennis Baron, MIT
Patrick Brooks, UNC Chapel Hill
Alan Crosswell, Columbia
Jeremy George, Yale
Robert Klima, Texas A&M
Jeff Kuure, Internet 2
Chris Norton, Texas A&M 
Mark Silis, MIT
David Slater, Level Three
John Todd, Loligo
Mike Van Norman, UCLA
Doug Walsten, Cisco
Garret Yoshimi, Hawaii


*Discussion*

Today's call focuses on MIT's web-based SIP configuration application,
which was developed when MIT switched from using Pingtel's SIPxchange
to SER and Asterisk.  The goal was include the functionality that they
were used to, with additional features for MIT's specific needs. Since
the initial deployment, Mark Silas has added support for MIT's VOIP
pilot as well as a configuration server for Polycom
phones. Authentication is provided through the use of web
certificates, which were already in heavy use at MIT.

The application allows users to configure a variety of options
relating to their accounts and devices. Multiple owners are allowed
for each account, and accounts can be managed based on billing
records. Users who have the authorization to manage departmental
financial information, for example, are able to manage that
department's phone accounts.

Call forwarding is also configurable, allowing users to forward calls
to voice mail after a specific number of seconds or to a particular
number or SIP URI. Call level access is also configurable, which
allows administrators to disallow the calling of international numbers
on open phones in public areas. Calls can be blocked by number or by
regular expression, and this blocking can be overridden to always
allow certain numbers/URIs to be connected. Anonymous calls can also
be blocked, and a recording informs the caller that anonymous calls
are not accepted.

A question is asked, based on the WebEx demonstration screen, if users
are able to customize their RPID and DID numbers. Mark explains that
only administrators can do this. They have discussed the possibility
of allowing users to select their number from a drop-down list, but
they would not be allowed to change it after the account was set up
without an administrator.

Mark also explains that the white and blacklisting is done with
AVPs. All information on the web page is generated from an Oracle
database, which is then sent to RADIUS. SER uses the AVP to drive all
decision making. When this was first implemented, the performance was
slow. Now, all results are returned from RADIUS in a single call when
using avp_load_caller or avp_load_callee, and the performance has
improved dramatically. OpenSER's support for OpenRADIUS has been
good. Mark offered to make the schema for the database available to
participants.

Voicemail is provided by Asterisk, with MySQL storing the
configuration. Asterisk has plugins installed to allow support for GSM
and MP3 formats in addition to WAV.  This allows SMS notifications to
be sent to mobile devices as MP3. Mark is asked about how the message
indicator functions, and says that it is sending out NOTIFYs rather
than using a presence server. Modifications were made to the SER
source, as by default it expects Asterisk to function as a stand-alone
IP PBX. Dennis asks if any sort of state is maintained, and Mark says
no. For accounts with no contacts, a 404 is returned immediately.

Call records for accounts display incoming, outgoing, and missed
calls, including the calling and called numbers/URIs, the IP of the
originating call, duration, and date, all of which comes from RADIUS
accounting. A program parses the RADIUS logs every 5 minutes and loads
the data into Oracle, a task that Mark found more difficult than he
imagined it would be. Alan Crosswell asks why RADIUS was chosen over
MySQL. Mark found that a database was harder to replicate with the
level of availability needed. RADIUS allows the use of a central
database and has built in failover mechanisms.

For configuring devices, the MAC address is entered, an owner is
assigned, and a configuration for a Polycom or Hitachi phone is
built. The configurations are pushed to an FTP server, using VLAN
security to protect the preset username and password. Client
certificates can be used for authentication on Polycom phones as of
firmware version 1.6.5. Multiple owners can be assigned to devices,
and users can add and delete accounts for devices. The Polycom phones
have three buttons, which allows multiple calls and accounts to be
configured for each button. Mark feels that the provisioning features
of the Polycom phones are nice, and the Snom phones aren't bad. He has
had some difficulty with documentation for Cisco phones.

A question is asked about provisioning multiple appearances of the
same number on different devices. Dennis says that this is possible,
and incoming calls are simply forked instead of using any sort of
presence features for shared lines. But he has mixed feelings about
attempting to emulate shared line functionality, and doing this in a
way that works like a traditional PBX is difficult with SIP, as it
pushes you into using back-to-back user agents.  Polycom has an option
for making lines shared; the idea is that once you have a presence
agent, all shared appearances can subscribe. But this still poses
difficulties, such as allowing other phones to join a call and
determining if the audio is mixed by one device to or if a media
server is used. Supporting other clients such as soft phones is
another potential problem. These features are not yet available in open
source products.

Mark mentions that he was surprised by the use of shared calls among
administrative users at MIT, particularly in boss and secretary or
shared office scenarios. He feels that the lack of shared calls will
be problematic, as only a few IP PBX products offer this feature. He
feels that a separate system may be put into place to allow
traditional shared calling. Dennis says that when Penn began using
Cisco 7900 phones, they were treated as replacements for traditional
analog phones and were able to defer on some of these issues, compared
to the MIT users who have gotten used to their ISDN lines. The web
interface, and the different options that it allows users to
customize, will probably lead changes in user expectations and
behaviors.

Mark is asked how much of the code for the web application is in
shareable modules. He says that some of it is specific to MIT, but
other parts would be applicable to any institution.

Finally, a question is asked about call forwarding, which is disabled
on the phone itself. This has caused some confusion, but users seem to
like the web interface as they often find themselves setting it up
from remote locations when they are not in front of their desk phones,
on sick days, for example.

Screen shots are available here:

     http://mit.edu/sip/presentations/screens/mit/

There will be a VoIP SIG call on August 24th.
[This call has now been cancelled.]