[*] Requesting an ITAD
Bill Reid
billreid at shaw.ca
Tue Sep 6 23:42:36 CDT 2005
Here is a message from John Todd about getting an ITAD:
_________________________________________________________
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: itad at big.edu
]
==================
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 admin at freenum.org 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 <jtodd at tellocorp.com> 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 admin at freenum.org 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
"john.whorfin at big.edu", 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:\\1 at sip.big.edu!" .
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 "12345 at sip.big.edu". This NAPTR record can
be entered directly in the "freenum.org" zone - just email <admin at freenum.org>
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.
More information about the Asterisk
mailing list