[Asterisk-Dev] ENUM application idea

Tue Mar 18 13:15:08 MST 2003

I started working on an enum switch a while back but I stopped working on
it when I found out that the most popular enum lib (can't remember the
maker right now), was not going to GPL their latest version.  The GPL'd
version that is available would need some modifcations to bring it up to
recent standards.

After I stopped working on that I threw together a perl agi script to do
enum lookups.  I think I posted it to the list or maybe I included it in
my asterisk-perl distribution

James

On 18 Mar 2003, Steven Critchfield wrote:

> Sounds like this needs to be part of a switch statement. As Mark has
> stated, switch is setup to be a plugable way of doing extension lookups
> via different technologies. At that point you could have a entry in the
> specific context that said
> 
> switch => Enum
> 
> On Tue, 2003-03-18 at 12:49, John Todd wrote:
> > 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
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> -- 
> Steven Critchfield  <critch at basesys.com>
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> 