SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call, October 5th 2006

*Attendees*

Dennis Baron, MIT
Steve Blair, University of Pennsylvania
Justin Church, UNC
Alan Crosswell, Columbia
Jeremy George, Yale
Candace Holman, Harvard
Jerry Keith, UC Riverside
Jiri Kuthan, iptel.org
Neal McBurnett, Internet 2
Randy Neil, Trent University 
Christian Schlatter, UNC
Philippe Sultan, Inria
John Williamson, Trent University 

*Discussion*

Today's call begins with Dennis asking if any participants have any
questions or topics for discussion before Jiri Kuthan begins his
presentation.

Dennis mentions that Inria in France is now part of SIP.edu and is
reachable by SIP. They also have an ITAD number, and are looking at
doing ISN. Iptel.org is now also reachable by ISN. Dennis cites
iptel.org as an inspiration for SIP.edu, and was surprised to find
that his iptel.org account had a numeric alias. Jiri says that this is
because many people use terminal adaptors which make it difficult to
enter letters.

Jiri begins with a history of iptel.org. The origins of SER and
iptel.org come from Fraunhofer FOKUS, which Jiri compares to DOD labs
in the US. The organization does research for both technological
development as well as industrial application. SER was developed in
2001 and released to the public in 2002, and went from a research
project to a commercial run by iptel.org. ISPs have been the main
commercial implementers. Later iptel.org was acquired by Tekelec which
has caused lots of questions about the future of SER, but all the
groups are working to make the software available.

Jiri met with Dennis at VON and was surprised how much confusion there
was about SER and OpenSER. OpenSER was created by people who left
iptel.org and have their own vision of how OpenSER should be run. Jiri
is not involved in OpenSER.

Over the past year, iptel.org has focused on making SER mature,
leading to a fundamental overhaul based on the deployment
experience. These changes will lead to new major release, the testing
version of which is codenamed Ottendorf and will be released this
month. The data model has been completely updated, there is better
performance for scaling many TCP connections, the scripting capability
and database connection facilities have been improved, and there are
new management features based on XMLRPC. Further changes will focus on
DNS and Stun processing; these have been committed to the repository
but are still being worked on.

Jeremy asks if the documentation has been updated. Jiri says that
there are links to updates on the iptel.org SER site, and he would
like to credit Greger Teigre who has been instrumental in working on
the documentation.

Jiri asks who on the call is using SER or OpenSER. John Williamson of
Trent says that they have started looking at it. Steve Blair uses
both; their production VOIP is running on SER and a session border
controller is running OpenSER, which may change depending on what's in
the new version of SER. Alan at Columbia is using OpenSER. Dennis was
using Pingtel SIPxchange and moved to OpenSER a year ago. He was not
the one that made the decision, but one important thing was TLS
support for SIP clients.

Jiri touches on the differences between SER and OpenSER. Recently SER
has been focused on stability and functionality, and he believes
OpenSER is more focused on new features.

One request is for more complete documentation. At the time of the
separation one issue was consistency of documentation. This is still
an issue. Jiri feels that this is a big concern and a fair comment.

Christian says that he was surprised at the continued development of
SER after speaking with people from Tekelec, as they mentioned that
they were not as interested in continuing SER as an open source
project and were more interested in integrating SER into their IMS
offerings. He asks about the future of SER as an open source
project. Jiri feels that there should be no issues, and the main
contributors are still making contributions. He's hesitant to speak on
the behalf of the company, but feels that based on past performance
nothing should be changing.

Jerry Keith asks what will drive new releases in the future. Jiri says
that they have been struggling with this; they don't like the current
release cycles but they have been unavoidable due to the recent
changes and the impact that they have had. They would like to have
quarterly releases but no final decisions have been made. Historically
major features or the need to backport to the current release has been
the driving force for new releases.

Dennis asks about requesting features or asking for work to be done on
existing features. Jiri isn't prepared to give a final answer, but
they are collecting feedback and sorting out priorities. They haven't
published a roadmap as most common requests will be addressed in the
next release, and feedback from the new release will influence the
roadmap. SER is pretty stable and established, and it would be hard to
imagine any new, fundamental features that might be developed.

Dennis asks if SEMS and SERWeb will continue to be developed. Jiri
says that they will, but documentation is still an issue. SEMS has had
an offer recently for documentation maintenance, but SERWeb is still
not very well documented.

A question is asked about licensing, particularly between SER and
OpenSER. Jiri says that both SER and OpenSER are GPL, and the
copyright for SER is owned by Iptel meaning that they can release it
under different license. They have contemplated dual licensing but
have not this very often. Since both SER and OpenSER are GPL licensed,
code can pass back and forth between projects. For code in SER,
contributors are asked to grant some additional rights in order to
keep integrity for code created by the SER project. There is a new
experimental directory for review of new code, which migrates to the
SER codebase after evaluation.

Jiri is asked if modules for OpenSER, in particular the XMPP module,
are compatible with SER. He is unsure.

Following a question about presence, Jiri provides a brief overview of
the IETF process. The development began with 9 proposed methods for
presence that were eventually narrowed down to three. Two of the
groups proposing methods dropped out, and SIMPLE, based on SIP,
remained. Jabber, the XMPP protocol, arrived after this. The IETF is
allowing both to continue and letting the market decide.  Personally,
Jiri felt that SIMPLE was the better choice based on service
integration, but it has taken so long to progress that both
technologies now are comparable. Iptel has only been working with
Simple, and does not see any future work with XMPP.

Christian asks about the presence module, which Jiri says has been
completely overhauled in the new release. He also asks about DNS
failovers, which also are in place in version 0.10.

Dennis asks about STUN improvements. Jiri found that it was unstable
as it worked poorly on certain types of NATs. Changes have happened
over the past two years to rectify this, moving to technology that
uses STUN as a detection tool. Before exchanging any voice packets,
additional checks are performed to make sure that the STUN results are
reliable. IETF is now mandating that SIP traffic is multiplexed with
STUN to keep NAT bindings intact, and the Stun protocol has been
altered. These changes are in the upcoming SER release.

Dennis says that after discussions at VON, there was interest doing a
trial implementation of the SIP Identity RFC for authenticating SIP
signaling, and is curious if Iptel has any interest in implementing
this. Jiri says that they would like to add this, and would love
people to contribute to SER as they are shorthanded in terms of
development.

The final question regards identity, and which approach to concentrate
on. Jiri says that RFC 4474 covers a way to convey identity in a way
that is cryptographically secure within domains based on digest
authentication. He would like to see it function similarly between
domains. One approach they have been investigating is similar to
Kerberos, where authentication and service infrastructure is
separated. Dennis mentions also wanting to process unidentified calls
differently, perhaps sending them directly to voicemail. Jiri feels
that different users would have different policies based on clear
identity.