[Asterisk-Dev] ENUM application idea

[John Todd]

I see from old posts to the Asterisk list (November 02) that there 
were discussions about an enum AGI script.  Did anything ever come of 
that?  It seems a worthwhile addition as an application and not an 
AGI, even if enum is still in it's infancy.  Being one of the first 
systems to support enum would be a coup for Asterisk.  The only 
problem currently is getting entries made into the .e164.arpa. 
address range; that seems to be very mired in political nonsense at 
the moment, but will most likely get some traction as soon as things 
like Asterisk start to use it (chicken/egg syndrome - which comes 
first?)

I have only recently been investigating enum, so my example probably 
leaves a lot to be desired from robustness.  Comments welcome.

An Application would work better than an AGI, I think, so it can be 
put in the dial flow pipeline.  .  Here's my take on what it would 
look like below.  Note that as I've publicly said before: "John Todd 
cannot program his way out of a wet paper bag."    Thus, I leave this 
imaginary program to someone else's creative abilities for code 
implementation, if it's even a worthwhile task.

I expect very few calls will be completed via enum lookups, so this 
application is written as a "jump" module.  It's easily inserted in 
the call flow, and could easily be inserted in front of almost 
any/all Dial statements without significant pain, I think.




Name: CheckEnum

Function: Checks a given number and protocol/technology to see if it 
exists in the enum (e.164) DNS database.  If true, then will re-write 
$EXTEN to the returned value (minus leading URI portions of the 
string, such as "sip:" or "tel:") and sets $ENUMSERVER to the SIP 
host (if URI is a SIP URI) and jump to a given context.  If false, 
continues to next priority level.

Syntax:  CheckEnum(TECHNOLOGY,DIALEDNUMBER,CONTEXT[,DIGITS,COUNTRYPREFIX])

TECHNOLOGY =
	SIP = SIP protocol
	H323 = H323 protocol
	IAX = IAX protocol (is this a standard URI term yet?)
	TEL = PSTN telephony protocol
	Others?

DIALEDNUMBER = The dialed number.

CONTEXT = The context to jump to on successful lookup of the 
DIALEDNUMBER using TECHNOLOGY (i.e.: if you were looking for SIP and 
1-301-555-1212, and you got a sip:// response on 
2.1.2.1.5.5.5.1.0.3.1.e164.arpa. then you'd jump to the context 
specified)

DIGITS = the number of digits required as a minimum to add the 
COUNTRYPREFIX (this is to avoid adding a country code if someone has 
already typed it into a fully-qualified number)

COUNTRYPREFIX = the country prefix to add if the passed DIALEDNUMBER 
is less than DIGITS in length.  This is for situations where persons 
are not "used" to adding a country code to their numbers, and this is 
the "default" country code.



-- Example:
A basic example to check 13015551212 as a dialed number to see if 
it's valid in enum DNS tables to redirect to a SIP call.

In the DNS, the following record exists (ignore how it got in there 
for the moment; that's another application that needs to be written, 
but for now we'll assume it's hand-entered):

2.1.2.1.5.5.5.1.0.3.1.e164.arpa.  IN NAPTR 100 10 "u" "sip+E2U" 
"!^.*$!sip:39393 at ast.foo.com!"

[blah]
exten => _1.,1,CheckEnum(SIP,${EXTEN:1},enum-sip,10,1)
exten => _1.,2,Playback(sorry-no-such-number)

[enum-sip]
exten => s,1,Dial(SIP,${EXTEN}@${ENUMSERVER},40)


This would check to see if an NAPTR containing "sip:" was returned in 
a query about enum address 2.1.2.1.5.5.5.1.0.3.1.e164.arpa. - if 
true, then jump to context enum-sip and dial 
"SIP/13015551212 at ast.foo.com"  If false, go to priority 2.  <grunt> 
The more I look at that, the more I am unsure if the SIP parser will 
handle it correctly.


Note: weird thing about North American numbers is that any long 
distance here requires a "1" in front of the dialstring.  My example 
strips the '1' off with the EXTEN:1 syntax, but then adds it back on 
with the "10,1" modifiers to the CheckEnum call.  Other countries 
will have less confusing examples that don't remove and add the same 
digit, so North America is a bad example.  I anxiously await the day 
when all calls are proceeded with "1-NPA" instead of this 
unpredictable "local call" seven digit syntax that we now face 
(sometimes, depending, maybe, sort of.)


Note2: I could eliminate the "DIGITS" and "COUNTRYPREFIX" with clever 
acrobatics before I called the CheckEnum application, but it seems 
most "clean" to handle all of that inside the application instead of 
re-writing the $EXTEN, since many (most?) queries will return "false" 
and if we fooled around with $EXTEN outside of the CheckEnum 
application, we'd have to switch it back to the way it was before in 
order to pass the call to a "normal" Dial application call.


See Also:

RFC2916 - e.164 and DNS - http://zvon.org/tmRFC/RFC2916/Output/index.html

enum site: http://www.enum.org/   - sign up for a demo set of 
.e164.arpa. numbers if you can figure out who offers the service for 
North America!  It's a mystery surprise!

More enum: http://www.itu.int/osg/spu/enum/index.html

RFC2806 URLs for Telephone Calls 
(http://www.zvon.org/tmRFC/RFC2806/Output/index.html)  - LOTS of 
hidden "gotchas" potentially returned in "tel:" replies; Danger, Will 
Robinson!

IETF-DRAFT 
http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-04.txt

RFC3261 Session Initiation Protocol 
(http://www.zvon.org/tmRFC/RFC3261/Output/chapter19.html#sub1) - 
careful with that axe, Eugene.  There are lots of things that have to 
be handled in sip: URI replies; most are not used with Asterisk 
currently.  If you are converting tel: responses into sip: responses 
(i.e.: looking up a TEL URI and then jumping to a context that dials 
the EXTEN with a SIP Dial command) note the caveats in section 19.1.6 
which explicitly describe how that conversion should take place. 
Perhaps this not a big issue, since Asterisk will explicitly chop out 
the phone number from the tel: URI and crush it into a small wad of 
numerics.  (i.e.: +01-301-555-1212 becomes "013015551212")



JT