SIP in higher education

[John Todd <>]

[apologies for the delay in sending this - I was hoping to have a 
website up with this before now, but my web design skills are 
abysmal, and I find myself forwarding this ASCII representation. 
Hopefully this will find it's way into HTML shortly, but I think it's 
time to send it to the list regardless of my aversion to 
web-authoring...]

There seems to be rough consensus that the ISN (ITAD Subscriber 
Number) scheme of inter-organization dialing might have some merit. 
At the very least, the effort to implement seems to be low enough 
that an alpha test does not seem to be unwarranted in order to 
investigate the usefulness or difficulty of the dialing method.  With 
that in mind, I have created a preliminary zone as a testbed for ISN 
dialing, and invite any participants in the SIP.edu community (and 
beyond) to participate.  There is no cost, and there are "crutch" SIP 
and ENUM resolvers provided (see below) for quick implementation 
without having to parse any numbers.  In addition, a fairly 
simple-to-use external SIP redirector is offered to speed initial 
tests.

While this document is not meant to be another full discussion of the 
ISN concept, I will mention that ITADs do not directly conflict with 
ENUM, or SIP URIs.  They are an intermediate step between the two, 
which hopefully will allow some of the usefulness of SIP syntax be 
applied to systems which are constrained to 12-digit dialpads, while 
shedding the political and technical complexity of e.164 mapping. 
ISN dialing is not a replacement for, but an overlay onto existing 
SIP URI endpoint directory structures which is more accessible to the 
vast majority of users who are using telephones or telephone-like 
devices with no easy alphanumeric entry method.

On the last SIP.edu conference call (2005-08-11) there were questions 
on how to obtain an ITAD from IANA.  The following template is the 
one that I have used successfully with IANA registrations, and I have 
discussed with the IANA ITAD administrator that this is sufficient 
data for creating entries in the ITAD list.

Thus far (2005-08-24) there are 11 IANA-registered ITAD holders, most 
of which are currently resolving correctly and receiving calls on ISN 
dialstrings.  Notable in the list are Free World Dialup and Tello as 
operational destinations.  To keep updated on the list of 
registrants, visit http://www.iana.org/assignments/trip-parameters 
which has a list at the bottom of the page.

I have included the instructions for ITAD sign-up in this document, 
along with a very preliminary "how-to" guide/cookbook to actually use 
the ISN system in it's demonstration ("alpha") form.  This "how-to" 
guide is in the process of being converted into a white paper, a 
formal proposal of implementation, and an informal cookbook. 
However, in the interests of getting people up and running in a 
manner that is more than just speculative discussion, I've 
hyper-condensed the cookbook below:


Step 1: Register an ITAD with IANA by going to this URL:

http://www.iana.org/cgi-bin/assignments.pl
  [your suggested responses in brackets]

=============
Contact Name:
  [the name of the human that is responsible for this application]


Contact Email:
  [the email address of the person who is responsible for this 
application.  I did not specifically discuss the use of role accounts 
in this field, but I assume that is acceptable since others have done 
so.]


What type of assignment/registration are you requesting?
  [Put in something like this:  "I would like to register an ITAD 
(Internet Telephony Administrative Domain) number with IANA for my 
organization." ]

Which registry are you requesting this assignment/registration be made in?
  [Put something like this: "I am requesting this to be added to the 
IANA ITAD list, found on 
http://www.iana.org/assignments/trip-parameters";]

If possible, please give a brief description of why you need this 
assignment/registration:
  [Again, you may put in whatever you wish, but a standard 
description like this would work: "We will be utilizing the ITAD as a 
globally unique inter-organizational identification number for VoIP 
(SIP) signalling and media exchange." ]


Additional Information.  Please include a reference to the 
specification or RFC (if available) that defines this number or name 
space:
  [Here it is suggested that you put the following information:

ITADs are allocated per RFC3219 (section 13.5 - 
http://www.zvon.org/tmRFC/RFC3219/Output/chapter13.html#sub5)

My organization information is as follows:
Organization: Big State University
Address:      123 University Ave,
              Suite 1000
              Collegeville, ST 12345
Phone:        +1-700-555-1212
Fax:          +1-700-555-1213
Email:        


]
==================



Step 2: Publish your ITAD/ISN information in the DNS

  2.1 Wait for your ITAD to be returned.  It "should only take about 
a week" according to the admin at IANA (with whom I spoke about these 
registrations directly.)

  2.2 Send your ITAD confirmation to  along with the 
nameservice information (described below)

(Note: this is an "alpha" test using freenum.org as the root. 
Currently that is operated and managed personally by John  Todd 
<> and the bandwidth/public services associated 
with the test are provided by Tello.  It is desired that a non-profit 
or non-commercial consortium will eventually manage the "root", but 
that has not been worked out yet, nor has a final root zone name been 
decided upon.  For the purposes of the test, "freenum.org" can 
function as the root.)

2.3 Get pointers configured correctly.  Pick from one of the two 
possibilities given below:

  2.3.1 Do you have your own nameservers and ENUM-like DNS data?  If 
so, send the NS record entries to  and they will 
then point to your nameservers for local administration.  Create a 
new zone called "xxx.freenum.org" on your nameserver(s), where "xxx" 
is your ITAD number.  Populate it with the subscriber numbers for 
your entity in ENUM-like format - perhaps this will be a simple as 
creating a symlink of "xxx.freenum.org" to your existing ENUM 
extension zone.  Note that in this fashion you can create one-to-one 
mappings of subscriber numbers to SIP URI's like 
"", thus meshing well with any existing SIP 
infrastructure that exists at your institution.  The delegation of 
"xxx.freenum.org" to your servers will allow DNS queries from the 
rest of the world to find the  entries for the extensions/subscriber 
numbers in your ENUM-like tree.

  2.3.2 Do you have only a single SIP server, and you don't want to 
deal with the hassle of creating a zone file?  It is possible for the 
whole zone to be pointed at your SIP proxy or gateway without 
delegation of the zone to your nameservers.  What you need is a 
single record like this to be entered directly in the freenum.org 
zonefile for your entire zone:

[line is wrapped for ease of reading]
*.xxx.freenum.org IN NAPTR 100 10 "u" "E2U+sip"
     
"!^\\+*([^\\*]*)!sip:\\!"
 .

 This means "take any number given, ignore a leading '+' sign (if 
given), and then take everything to the left of the '*' sign (if 
given) as the number, or just use the whole number provided if there 
is no '*' sign, and create a SIP URI out of it."  This would take any 
of these strings: "12345*111", "+12345*111", "+12345", "12345" and 
turn it into "".  This NAPTR record can be entered 
directly in the "freenum.org" zone - just email <> 
with the NAPTR record modified for your public SIP proxy.  No DNS 
modification is required at all on your servers if this method is 
used, as all data and queries will be resolved by the freenum.org 
masters.



Step 3: Configure your system to receive inbound SIP calls from the Internet.

  This is a very site-specific task, and so details about how to map 
numeric subscriber numbers to the user community on the local SIP 
proxy are left to the local administrator.  If the local dialplan 
just maps numbers directly through to extensions on an Asterisk or 
Cisco gateway to a PRI to your main PBX, then this will be relatively 
easy.  If the dialplan is mapping subscriber numbers to SIP URI's 
through a database, this is more complex, but it is assumed that the 
local administrator has the ability to configure their SIP 
proxy/gateway to receive inbound INVITEs from foreign sources.  This 
can be accomplished through entry of SIP URIs into the DNS (if the 
zone is delegated to the organization and each extension has an 
ENUM-like entry) or it can be done on the proxy at the moment a call 
is received - this is up to the local administrator.
  This ability is a prerequisite for many aspects of SIP.edu 
integration, and thus will not be covered in detail here.



Step 4: Configure your system to perform ISN lookups and calls

 4.1 It is perhaps advisable to create a local prefix which users 
enter which distinguishes ISN dialing.  Since ISNs are 
variable-length, you will probably have to have a timer-based 
end-of-dial decision if you are interfacing standard DTMF handsets. 
A suggested dial prefix is "022" or "012" as these may mesh well with 
existing trunk prefixes that are familiar to users (like "011" for 
North American international dialing.)   The implementation of this 
is a local issue, and is left to the discretion of the administrator. 
If a local user dials (as an example) "0122425*256" then the local 
proxy should strip off the "012" (which is the example trunk prefix) 
and pass the remaining ISN of "2425*256" to the next step of the 
dialing process.

 4.2 Once a number is evaluated into an ISN (by whatever mechanism) 
by your SIP gateway or proxy, it needs to perform an ISN lookup which 
leads to a SIP URI.  This can be done in one of three ways - pick one:

   4.2.1 Option 1:Your proxy/gateway may have enough "intelligence" 
and scriptable capability to tear the dialed sequence apart and 
perform a "native" ISN lookup.  The format of "<subscriber>*<itad>" 
can be recognized and turned into distinct strings for ENUM-like 
lookup.  Your system should perform a lookup by taking the ITAD 
portion of the ISN and prefixing it onto "freenum.org" as the zone 
name.  Then, the subscriber number is inverted and turned into an 
ENUM-like zone prefix.  An example is easier than description: If the 
user dials "2203*256" the ENUM-like lookup that occurs is 
"3.0.2.2.256.freenum.org".  The NAPTRs (if any) that are returned as 
a result are parsed in the manner that is according to ENUM rules; 
hopefully there is a protocol URI in the response of the type you are 
seeking (typically, SIP.)

  4.2.2 Option 2: Your gateway or proxy can perform a SIP lookup on 
the ISN against the publicly accessible Tello SIP proxies configured 
for this purpose.  As a public service, Tello has a SIP proxy which 
will do ISN-to-SIP rewrites.  If you send your SIP query in the 
format:
   <subscriber>*<ITAD>@public.tello.com
then any valid ISN lookup by the Tello proxy will result in a "302 
Redirect"-style response.  Note that this will only respond with the 
first (highest preference) URI in any list of NAPTRs, including "tel" 
or other URI methods.  Your gateway must be able to parse the reply. 
It is anticipated that for this alpha test that almost all replies 
will be SIP URI formatted responses.

  4.2.3 Option 3: Your gateway or proxy can perform an ENUM lookup on 
the ISN against the publicly accessible ISN rewriting DNS resolver, 
which is also provided by Tello as a public service.  This resolver 
has been written to specifically re-write ENUM queries with ISN 
format and convert them to appropriate ISN lookup syntax.  This 
re-write on the Tello resolver does something like this:
   6.5.2.*.3.0.2.2.e164.arpa. -> 3.0.2.2.256.freenum.org
Currently, the "freenum.org" zone is what is used to convert any 
e164.arpa. lookups into an ISN-style search.  It is also possible to 
use the "freenum.org" zone as an ENUM-like root zone name.
  In order to use this search method, you MUST have your gateway or 
proxy exclusively use the Tello resolver IP address as the only 
resolver that the device uses.  All other query types will be passed 
through unchanged by the Tello resolver to a set of "normal" 
resolvers; only NAPTRs containing "*" and which are for e164.arpa. 
suffixed requests will be altered.  If the NAPTR does _not_ contain a 
"*" within the record, then it will be unmodified (i.e.: you can make 
"normal" ENUM or ENUM-like queries through this resolver without 
worry.)
  The DNS resolver which is configured to do this is located on 
66.28.153.11 (public.tello.com)  You may point your /etc/resolv.conf 
or other resolution configuration sections to this nameserver in 
order to have that resolver do ISN re-writes for your ENUM-capable 
equipment.

  4.3 Try to make Caller ID number match correctly for ISN calls.  If 
your callers are making outbound calls via ISN lookups, please try to 
make their caller ID match the ISN method for those outbound calls. 
The numbering scheme of "<subscriber>*<ITAD>" should be sufficient to 
fill the caller ID number with information that can be identified as 
an ISN, as the "*" digit indicates the ISN nature of the caller ID. 
Of course, Caller ID name ("John Doe") is left to the local 
administrator, as are any privacy flags which may obscure the caller 
ID in it's entirety.


Appendix:

A) Testing methods.

 To test to see if your ISN mappings are correct so that others may 
find you, try looking at a valid subscriber number for your ITAD zone 
name.  Assuming you have a valid ENUM entry for "4.3.2.1" in your 
zonefile (or have a wildcard) and your ITAD is 999, then this should 
work after DNS updates have been put in place:

 dig @my.nameserver.edu NAPTR 4.3.2.1.\*.999.freenum.org.

This should respond with the NAPTR record you have in place.  If you 
get an "NXDOMAIN" then something else is wrong with DNS resolution, 
and you should debug as you would a normal DNS issue.

There is also TXT data stored for each organization in a 
somewhat-X.500 compliant list in the "info.freenum.org" zone.  This 
is more of a convenience for the administration of the nameserver 
records, but also may be of some use to participants.

  dig @my.nameserver.edu TXT 256.info.freenum.org.



B) Quick Asterisk outbound config for outbound ISN queries:

; -- Start Asterisk extensions.conf Config --
[isn]
;
; This is the ISN re-write routines.  I include this context in
;  other parts of the dialplan where my users typically have
;  their dialplan comparisons for standard dialing (domestic,
;  international, emergency, voicemail, etc.)
;
; If a number is presented that is 012<some-digits>*<some-digits>
;  then we should assume it is an ISN number.  Hopefully this
;  can be replaced with an ENUM lookup from within the new ENUM
;  functions for Asterisk I'm having written, but for now this
;  is a SIP handoff to the Tello SIP ISN re-write proxy since
;  that is significantly faster and easier. You don't need the Tello
;  SIP proxy to do ISN dialing, but they have the ability to
;  do the number re-writes easily.  If there is a match for
;  the ISN dial string,  we get back a "302 Redirect" otherwise
;  the call goes to a congestion tone.
;
; The prefix for ISN numbers on this local system is "012" so
;  strip off those digits when presenting. Modify to suit.
;
; Ensure that "promiscredir=yes" in sip.conf is set so that
;  redirection is accepted from remote proxies.
;
; Hopefully better examples will be available at
;  http://www.freenum.org/ soon - check back often.
;
exten => 
_012.*.,1,Dial(SIP/${EXTEN:3:20}@public.tello.com)
exten => _012.*.,2,Congestion
exten => _012.*.,102,Congestion
;
; -- End Asterisk Config --


C) Test numbers.  The following testing numbers should answer on 
G.711 with a recorded message or a person who doesn't mind being 
called:

613*262   - Free World Dialup echo test
2425*259  - Tello "success" message, echo test
1234*256  - John's annoying monkeys, then echo test
2405*259  - John Todd's desk (for questions)


D) Thanks to...

The public service ISN re-writer and SIP redirector are provided by 
Tello Corporation at no charge.  Please visit http://www.tello.com/ 
for more information on Tello.

Please note that while Tello provides some of these public service 
services which encourage the use of ISNs, it is not the case that 
Tello "owns", patents, or otherwise constrains the use or concept of 
ISNs in any way.