[Asterisk-Dev] ENUM application idea

Tue Mar 18 12:35:22 MST 2003

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>