SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call December 1, 2005

*Attendees*

Dennis Baron, MIT
Steve Blair, University of Pennsylvania
John Covert, Independent Consultant
Joel Dunn, UNC Chapel Hill
Wes Ferguson, Utah Education Network
Soo Hom, UCSD
Jeff Kuure, Internet2
Don McLaughlin, UCSD
Dave Packham, Utah
Ben Teitelbaum, Internet2
John Todd, Tello
Chris Trown, University of Oregon
Frank Whittemore, UCSD
Garrett Yoshimi, University of Hawaii
Dave Zimmerman, Berkeley

Today's call begins with an introduction from the UCSD participants. The
University is using Asterisk and is looking to have their SIP.edu
deployment operational by January 2006.

The remainder of the call was devoted to John Todd's discussion of
Asterisk. Asterisk is an open-source telephony toolkit that is capable
of doing SIP, and can be used as a PRI gateway. Asterisk can provide
most functions required by medium to large universities, but it is not
a SIP proxy. Very large institutions might want to using Asterisk in
conjunction with a dedicated SIP proxy, though there are universities
with users in the six-digit range successfully using Asterisk alone for
various protocols.

John has been working on an Asterisk cookbook for SIP.edu, which focuses
on the Soekris box mentioned in a previous call. This device features
three ethernet ports, as well as a PCI slot which contains a TDM PRI
card. The cookbook is aimed at  people who want to support soft phones and
SIP as well as the passing of calls to an existing TDM phone system. The
Soekris handles both pure SIP as well as converting to TDM in the middle.

In the cookbook, Asterisk is configured to act as a simple gateway
which translates calls between two SIP endpoints or one TDM and one
SIP endpoint. There are two parts, one going into the organization
and one going out. On the incoming side it will accept, for example,

 or a username such as 

 to make a phone
or SIP client ring. On the outgoing side of the gateway, Asterisk acts
as a SIP registrar, allowing clients to register against it and remain
permanently affixed. When these devices want to make an outbound call
to an E.164 number or SIP URI, Asterisk will pass the call.

Both SER and Asterisk support some NAT rewrite rules for firewalled
applications; SER will do media proxying as well. Asterisk is a very
large back-to-back user agent, and it keeps a list of active calls
flowing through it. Asterisk on a P3 can handle 1000 calls or more if
there is no media. If proxying media instead of just signaling, it can
handle 150-200 simultaneous calls.

There are a variety of ways for Asterisk to access external data sources
for name-to-number mapping. There is an LDAP module, and text files can be
imported or accessed via HTTP. Asterisk also uses a scripting language
of sorts for its configuration file, which makes it relatively easy
to integrate shell scripts or interface with existing databases. The
language is fairly easy to learn, and John believes that it is much
simpler than SER's language.

Finally, Asterisk servers can be grouped and interconnected easily,
allowing it to scale to very large deployments.

John mentions that he is putting together a 32mb Compact Flash card
for the Soekris boxes, with everything preconfigured for Asterisk. An
administrator would simply have to input a domain name and some phone
numbers and it would be ready to go.

Following John's overview is a brief question-and-answer session. Chris
Trown mentions that the University of Oregon is reluctant to release
student directory information, which seems to be a somewhat common
political hurdle.

Dennis asks if Asterisk supports the RPID field; John believes that it
does, but if not extra headers are easily configured. He also mentions
the ability of Asterisk to reconfigure headers based on directory lookups
or peer specifications - this allows Asterisk to override any headers
from the user agent that may be inaccurate.

Dennis asks if there is any sort of web interface for configuration or
management of Asterisk. There are, but John feels that none of them
are particularly good. Some are good for programmers, as they allow
macro-like functions, but John believes that the command line tools are
the best way to configure Asterisk. There is a management tool called the
Asterisk Flash Operator Panel. This will allow you to see most of what
is happening with current calls. There are also several CDR processing
kits for Asterisk, which will generate CSV files and can be imported
into MySQL.

John also mentions that there is an Asterisk book available
from O'Reilly, which is also available online as a PDF here:
http://www.asteriskdocs.org/modules/tinycontent/index.php?id=11

Don McLaughlin asks about the Compact Flash card for the Soekris box; John
says that it will fit on a 32mb card, and he will provide instructions
on how to burn the image with a Mac. If others are interested, he will
do this for them in exchange for the cost of the media.

John warns that the Soekris boxes aren't very powerful. Since Asterisk is
not a pure SIP proxy, it does require some processing power to operate,
particularly for transcoding with high-compression codecs. It will not,
for example, support the G.729 codec. It will support the G.711 codec,
which as part of the SIP spec, must be included with all calls. So all
RFC-compliant calls will work, but will require more bandwidth. If this
is a problem, you will need to run Asterisk on a faster computer. The
G.729 codec is patented, and must be purchased from Digium for a cost of
$10 per simultaneous channel. There are boards with 4 PRIs, which also
would something more powerful than the Soekris. Boards with 16 PRIs
capable of onboard transcoding are coming.

Ben asks if anyone working is on Asterisk conferencing, allowing
software transcoding for conference calls. John says not currently,
but more wideband codec support is coming soon, though Asterisk would
need a lot of work to support this. One other shortcoming with Asterisk
is that there is no TLS SIP support, which is another project that is
hopefully coming soon. Asterisk will support almost any codec, as far
as simply passing packets through. It is a clearly a back-to-back user
agent, while full SIP is more than this.

The next call will be on Thursday, December 15th.