Posted: Tue Mar 18, 2003 6:49 pm Post subject: [Asterisk-Dev] ENUM application idea
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.
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@ast.foo.com!"
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@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.
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!
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!
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")
Posted: Tue Mar 18, 2003 7:35 pm Post subject: [Asterisk-Dev] ENUM application idea
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:
Quote:
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.
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@ast.foo.com!"
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@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.
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!
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!
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")
Posted: Tue Mar 18, 2003 8:15 pm Post subject: [Asterisk-Dev] ENUM application idea
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:
Quote:
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@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@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@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Steven Critchfield <critch@basesys.com>
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum