[Home]

Summary:ASTERISK-06338: ENUMLOOKUP failing on all methods
Reporter:John Todd (jtodd)Labels:
Date Opened:2006-02-16 11:55:39.000-0600Date Closed:2008-01-15 17:45:00.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/func_enum
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) enumlookup-doc-patch.txt
Description:Several things have changed in the ENUMLOOKUP function recently so that now it does not function as it did two or three months ago.  I have this in my dialplan:

exten => _012.,1,Set(isnresult=${ENUMLOOKUP(${EXTEN:3},sip,,freenum.org)})

This means that if I dial "0122203*256" that the result in isnresult should be "sip:2203@204.91.156.10".  However, the result is blank because the DNS lookup is malformed.

Note that this example uses the ISN re-write features, as the number queried (2203*256) has a "*" in it.  This means that the actual lookup will be "3.0.2.2.256.freenum.org" in the DNS.  Regardless of if the ISN method is used or not, or standard alternate-root specifications are made such as this:

exten => _1.,1,Set(isnresult=${ENUMLOOKUP(${EXTEN},,,e164.org)})  

...the result is the same.  The suffix for the ENUM lookup is always e164.arpa (which is what is in enum.conf) and the lookup fails.  This is more or less a total failure of the ENUMLOOKUP routines, since not even the CORRECT NAPTR is being looked up in e164.arpa (it's just the zone suffix, not even the number.)

This is the only lookup I see in tethereal on port 53 when performing ENUMLOOKUP events:

92.612648 10.0.1.10 -> 204.91.156.197 DNS Standard query NAPTR e164.arpa

This should be something like "2.1.2.1.5.5.5.2.1.2.1.e164.arpa" on a lookup.

Lastly, the "func_enum" category in Mantis is slightly inaccurate, since it's now "func_enumlookup", but that could probably be safely ignored...
Comments:By: Tilghman Lesher (tilghman) 2006-02-16 16:33:20.000-0600

Is this actually for trunk or is this for 1.2?
By: John Todd (jtodd) 2006-02-16 18:44:29.000-0600

Trunk.  I updated this morning.
By: Alex Nikolov (alexnikolov) 2006-03-20 17:59:32.000-0600

Hi John You can look at bug 6699 and patch with it
By: Tilghman Lesher (tilghman) 2006-03-20 23:57:09.000-0600

Fixed in 6699
By: John Todd (jtodd) 2006-03-21 00:40:47.000-0600

This still does not seem to work after update to SVN 13710.  Bug 6699 (http://bugs.digium.com/view.php?id=6699)  was also closed prematurely, which deals with perhaps this same problem.

Basic tests like this fail with ${foo} ending with null values (these are "known working" NAPTR records):

exten => 2230,1,Set(foo=${ENUMLOOKUP(16503816199,sip,1,mavetju.org)})

;exten => 2230,1,Set(foo=${ENUMLOOKUP(+18005551212,iax2,c,freenum.org)})

;exten => 2230,1,Set(foo=${ENUMLOOKUP(2203*256,sip,1,freenum.org)})

;exten => 2230,1,Set(foo=${ENUMLOOKUP(2203*256,,i,freenum.org)})

;exten => 2230,1,Set(foo=${ENUMLOOKUP(+437203001721,sip,r)})

If someone has it working, can you please forward the results of any or all of the above lines in a dialplan debug output?  Note that this is a blend of "normal" E.164 lookups as well as ISN lookups (NAPTR 3.0.2.2.256.freenum.org, as an example from above.)
By: Alex Nikolov (alexnikolov) 2006-03-21 02:59:45.000-0600

It's working ...

Connected to Asterisk SVN-trunk-r13675M currently running on localhost (pid = 2575)
Verbosity is at least 16
   -- Remote UNIX connection
Mar 21 08:58:15 DEBUG[2659]: chan_sip.c:6205 build_route: build_route: Contact hop: <sip:203@192.168.15.4:5060>
Mar 21 08:58:15 DEBUG[2622]: channel.c:856 channel_find_locked: Avoiding initial deadlock for 'SIP/203-bec8'
Mar 21 08:58:15 NOTICE[6531]: func_enum.c:102 function_enum: Num=+878107472566000
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1394 pbx_substitute_variables_helper_full: Function result is '0'
   -- Executing Set("SIP/203-bec8", "sipcount=0|counter=0") in new stack
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1461 pbx_substitute_variables_helper_full: Expression result is '0'
   -- Executing GotoIf("SIP/203-bec8", "0?3:6") in new stack
   -- Goto (analogext,00878107472566000,6)
Mar 21 08:58:15 NOTICE[6531]: func_enum.c:102 function_enum: Num=+878107472566000
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1394 pbx_substitute_variables_helper_full: Function result is '1'
   -- Executing Set("SIP/203-bec8", "iaxcount=1|counter=0") in new stack
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1461 pbx_substitute_variables_helper_full: Expression result is '1'
   -- Executing GotoIf("SIP/203-bec8", "1?8:22") in new stack
   -- Goto (analogext,00878107472566000,8)
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1461 pbx_substitute_variables_helper_full: Expression result is '1'
   -- Executing Set("SIP/203-bec8", "counter=1") in new stack
Mar 21 08:58:15 NOTICE[6531]: func_enum.c:102 function_enum: Num=+878107472566000
Mar 21 08:58:15 DEBUG[6531]: pbx.c:1394 pbx_substitute_variables_helper_full: Function result is 'guest@misery.digium.com/6000'
   -- Executing Dial("SIP/203-bec8", "IAX2/guest@misery.digium.com/6000") in new stack
localhost*CLI>
By: Joshua C. Colp (jcolp) 2006-03-21 11:52:17.000-0600

This is a configuration issue, not a problem in enumlookup. The argument list is:

number[|Method-type[|options[|record#[|zone-suffix]]]]

Therefore you should be using (referring to jtodd):

exten => 2230,1,Set(foo=${ENUMLOOKUP(16503816199,sip,,1,mavetju.org)})
By: John Todd (jtodd) 2006-03-21 13:01:54.000-0600

First: Please don't close tickets before the person that opened the ticket has a chance to reply and confirm that this is fixed.  It's courteous to allow someone the chance to discuss the issue especially when..

Second: You are partially incorrect.  The syntax in the documentation (doc/enum.txt) is different from that in the code, and I'm somewhat unsurprised to find the change happened at the same time as the rest of ENUMLOOKUP was altered.  Please look at enum.txt for a fully detailed discussion of the ENUMLOOKUP function, and you'll note the description of the function call that is built into Asterisk is different.  It was altered in a change by kpfleming on Feb 11, which is when ENUMLOOKUP diverged from documentation.

I'm confused as to why the options were separated from the "count" integer, since it is not possible to both receive a count of records and specify an ordinal placement at the same time.  But OK, that's not a big deal.

I have attached a patch which corrects the documentation.
By: Russell Bryant (russell) 2006-03-21 13:30:43.000-0600

It looks like the "record#" option is in 1.2 as well.  Does this documentation update need to be done there as well?
By: Joshua C. Colp (jcolp) 2006-03-21 13:58:42.000-0600

I apologize for closing it prematurely, and thank you for digging deeper into the documentation issue.
By: John Todd (jtodd) 2006-03-21 14:10:56.000-0600

Russel -
 I don't have a copy of 1.2 convenient to me, but let's say this:

Type "show function ENUMLOOKUP"

If the result is:
 ENUMLOOKUP(number[|Method-type[|options[|record#[|zone-suffix]]]])
...then the documentation needs to be updated with my patch.

If the result is:
 ENUMLOOKUP(number[|Method-type[|options|record#[|zone-suffix]]])
... then the documentation does not need to be updated with my patch.

The differences are very subtle - essentially: Do we require 4 parameters (new) or just 3 parameters (old) to make ENUMLOOKUP work in a more-than-trivial use case?  The "record#" exists in both cases; it's just the distinction between combining the "options" and "<integer>" fields as a treatment in the function call that is at question.

Josh -
 No problem.  It's hard keeping up with the bug volume, so rapid closure is typically desirable but give the reporter a little breathing room.  :-)
By: Russell Bryant (russell) 2006-03-21 14:14:19.000-0600

Ah, ok.  I see it now.  Then, this change is only needed in the trunk.  Thanks!
By: Russell Bryant (russell) 2006-03-21 15:53:12.000-0600

I have updated the documentation in the trunk in revision 14053.

Thanks!
By: Digium Subversion (svnbot) 2008-01-15 17:45:00.000-0600

Repository: asterisk
Revision: 14053

U   trunk/doc/enum.txt

------------------------------------------------------------------------
r14053 | russell | 2008-01-15 17:45:00 -0600 (Tue, 15 Jan 2008) | 2 lines

update enum documentation to reflect recent changes to the ENUMLOOKUP function (issue ASTERISK-6338)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=14053