SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call July 28, 2005

*Attendees*

Dennis Baron, MIT
Bob Bownes, Tello
Ed Guy, Pulver
Jeff Kuure, Internet 2
Megan Pengelly, Columbia
Mark Spencer, Indiana University
Ben Teitelbaum, Internet 2
John Todd, Tello
Chris Trown, University of Oregon
Garrett Yoshimi, University of Hawaii
Dave Zimmerman, UC Berkeley

*Discussion*

Today's call features a presentation by John Todd from Tello, regarding a
new system for dialing IP devices with 12-digit devices. John stresses
that this implementation, like all number-to-URI translation, is a
temporary measure, as dialing by URI is still the end goal.

An abbreviated version of the slides from the presentation are
available here:
     http://mit.edu/sip/sip.edu/presentations/tello_sipdotedu.pdf

The proposed solution is called the ISN, for ITAD Subscriber Number. This
is a numeric and symbol-only identifier which looks like a combination
of a SIP URI and an E.164 number. A subscriber identifier is on the left
side of the ISN, followed by an asterisk as a delimiter, with a unique
organization number (the ITAD, or Internet Telephony Administrative
Domain), on the right. The ITAD is an IANA assigned number which
any organization can apply for at no cost. The subscriber number is
assigned by the local organization, and could be in any format, such
as any existing extension or a complete E.164 number. Tello would like
to propose ISN as a BCP or RFC standard, with the Internet2 community
being the first test users.

To call an ISN, the user begins by dialing a prefix, such as 012 or 022,
which is configured locally at the site. This tells the system that
the call is to an ISN number, which could be looked up in a separate
tree. This filters out internet phone calls and makes it easy to retrofit
existing systems. After the user dials the ISN, a modified ENUM lookup
occurs which would require a root domain to handle the lookups. This
root domain has yet to be decided on, but preferably would be a .org
managed by a non-profit or consortium which would subcontract the name
service to a third party. An ENUM like construct would be created from
the subscriber number, which would be sent to the resolver. This allows
the local organization to associate various URIs with a subscriber number.

ISNs can be dialed from 12-digit keypads, and two-stage dialing would be
unnecessary. In addition, they are globally unique, do not interfere with
existing ENUM or E.164 dialing,  do not require a lot of infrastructure
changes, can be as long or as short as the local provider wants, and
could be filtered based on the ITAD. They would also be verifiable as
they are assigned by a central authority.

Possible drawbacks include some systems which might be incapable of
passing the asterisk, though this is rare. In addition, ITADs must be
acquired from IANA but this is free for organizations and carries few
restrictions. Also, ITADs are not mnemonic; they are incremented serially
and assigned in order, with numbers below 256 being reserved.

Ben asks about a policy to prevent a "gold rush" of organizations
claiming desirable ITADs for future trading. John mentions that there
is no current policy, but he plans to bring this up with IANA. Treating
ITADs as mnemonics, while perhaps unavoidable, is not the intention.

The final two drawbacks are that a top-level domain is required, and must
be agreed upon by all organizations.  Also, some proxies or gateways may
be too "dumb" to do the ISN conversion.  Asterisk and SER, for example,
can do this with very little scripting, but others may not.

Dennis asks about the ENUM-like complexity. Why use subscriber*ITAD
instead of ITAD*subscriber, which would allow standard routing to handle
the call? John responds that the goal is to come up with a number
similar to SIP URIs, with the organizational identifier to the right
of the delimiter. When the eventual transition to SIP URIs occurs, the
numbers will be more familiar.  Secondly, the asterisk is not permitted
in the RFC for DNS, so the removal of the asterisk at the point closest
to the device making the query is desirable. This could be done on the
SIP proxy, meaning no ENUM would occur on the lookup.

Following this is a brief overview of various Tello services for call
routing.  Tello would like to be the directory service provider for ITAD
mapping on behalf of the governing organization, both administering the
temporary root domain for ITAD service mapping to existing SIP addresses
as well as ISN rewrites and redirects. Tello is now offering their beta
service for enterprise call routing at no cost through the end of the
year. Any SIP.edu members are welcome; if there is enough interest ISN
support will be added.

The final discussion focuses on the benefits and drawbacks of ITAD
numbers and mnemonic devices. Dennis is concerned that if the ITAD,
which is currently three digits,  becomes popular it will lead to longer
numbers. John mentions that a 6 digit ITAD would allow for 1,000,000
organizations which leaves lots of room for growth. Adding a 5 digit
subscriber number leads to an 11 digit ISN, which is the same as an
E.164 number.

The next call will be August 11th.