Asterisk func enumlookup
Synopsis
ENUMLOOKUP allows for general or specific querying of NAPTR records or counts of NAPTR types for ENUM or ENUM-like DNS pointers.New in Asterisk 1.2, deprecates the application EnumLookup in Asterisk 1.4
Description
in Asterisk 1.2:ENUMLOOKUP(number[,Method-type[,options|record#[,zone-suffix]]])
in Asterisk 1.4 and newer:
ENUMLOOKUP(number[,Method-type[,options,record#[,zone-suffix]]])
Option 'c' returns an integer count of the number of NAPTRs of a certain RR type.
Combination of 'c' and Method-type of 'ALL' will return a count of all NAPTRs for the record.
Defaults are: Method-type=sip, no options, record=1, zone-suffix=e164.arpa
For more information, see README.enum
Details
- *CLI> show function ENUMLOOKUP
If you have this in Asterisk 1.2:
${ENUMLOOKUP(${EXTEN},sip,1,freenum.org)}
then you need this in Asterisk 1.4:
${ENUMLOOKUP(${EXTEN},sip,,1,freenum.org)}
Note the extra comma; the field that used to be a union of options and Nth has become two separate fields. Since this branch is based on trunk you need to use the 1.4 syntax with it.
Incidently, if the parameter c were used, as in:
${ENUMLOOKUP(+13015611020,ALL,c,e164.org)}
(from doc/README.enum in the 1.2 branch)
it would become:
${ENUMLOOKUP(+13015611020,ALL,c,,e164.org)}
in the new syntax.
Return value
Returns the resulting string.Example
exten => s,1,Set(foo=${ENUMLOOKUP(7079964444)})For a complete RFC compliant macro, with support for multiple enum providers, see RFC Compliant ENUM Macro
See also
- Asterisk config enum.conf: Configure the ENUM hosts that will be queried
- Asterisk cmd EnumLookup
- Asterisk variables
- Asterisk functions
Comments
333Still has problems
In any case the sorting algorithm used in 1.2.24 sorts by "order" then "preference" then "technique" totally skipping the "result" field. In practice if you do a NAPTR lookup on e164.org everything has the same "order" and "preference". And if you use "ALL" in your enumlookup(), then your technique is "ALL" for all records. In other words you get no sorting at all.
And each time you call enumlookup() it calls the DNS resolver and you can potentially get the records in a different order.
So if your target has published, say a E2U+ADDRESS and a E2U+IAX2 records you might get nothing but the E2U+ADDRESS regardless of the index you pass enumlookup(). I have lots of traces that show this. So even though there is a free e164 route to your destination Asterisk will not reliably allow you to get there.
I ended up patching my copy of enum.c to include the result field in the sort (e.g. the field containing "AIX://.....") and now I actually find usable SIP and AIX records every time if they actually exist. If/when I get where I can run 1.4 and the outstanding bug fixes are committed to 1.4 and trunk, I'll look to see if I can or need to contribute my changes.
And even if you find usable SIP/AIX routes with enumlookup(), make sure your dial plan accounts for unavailable, congestion and busy: In my testing I found a number that published two SIP routes, one apparently to a defunct VoIP provider (DNS lookup on host always failing which caused the dial() to return channel unavailable) and to a FWD account which always returned a busy indication from dial() (maybe because I am not a FWD member). In any case you need to assure your dial plan does not just stop if it finds a e164 route: If the call fails then you should continue on with your other call routing possibilities (your own VoIP provider(s) &/or the PSTN).
333An AGI alternative to ENUMLOOKUP function
333Can't handle multiple entries with the same order/priority