[Home]

Summary:ASTERISK-07871: [patch] The record# parameter in ENUMLOOKUP is ignored
Reporter:otmar (otmar)Labels:
Date Opened:2006-10-04 10:19:59Date Closed:2008-05-09 14:49:52
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.4-enum-changes.diff
( 1) 20080326__bug8089.diff.txt
( 2) 20080505-bbryant-dialplan_enum_tests.txt
( 3) 20080506_bug8089.diff
( 4) 20080507_bug8089.diff
( 5) 20080507-1339_8089.diff
( 6) 20080508_bug8089.diff
( 7) 20080508_bug8089-1.diff
( 8) asterisk-1.4.0-beta2-enum-simple.diff
( 9) asterisk-1.4.0-beta2-ienum.diff
(10) bug8089_bbryant_cclen-patch_20080506.diff
(11) enum-doc-update.diff
(12) enum-extensions-test.txt
(13) enum-trunk-update.dff
(14) exten_enum_test.conf
(15) svn-ienum-20070111.diff
Description:In function_enum, the args.record parameter is never evaluated.

That's also a bug in ast_get_enum, which does not offer a seperate parameter for this.

****** ADDITIONAL INFORMATION ******

I started to fix this and got a bit carried away: I've incorporated the ideas of http://bugs.digium.com/view.php?id=5526 and http://bugs.digium.com/view.php?id=5666 into this patch as well. Cleaned up the options parameter, removed a lot of cruft from enum.c (e.g. the search list of domains which was dead code since the demise of the ENUM application), updated the documentation, cleaned up the ISN/ITAD stuff and integrated it into a consistent options scheme. I've also sanitized the code for TXTCIDNAME.

So, yes, this patch is a bit heavy for 1.4. But we *really* need to fix the issues I list above, those are real bugs. One can certainly extract the points which just fix the bug. You'de loose out on a lot of cleanup work, though.
Comments:By: Olle Johansson (oej) 2006-10-09 09:44:47

We need to separate bug fixes from additional features here. Bug fixes can be implemented in earlier releases, feature additions go to trunk.

By: otmar (otmar) 2006-10-09 10:45:10

What do you want? Just a patch which fixes the record# issue? Include the config-file/TXTCIDNAME/ISN cleanups as well?

By: otmar (otmar) 2006-10-16 08:56:19

So, here is a *very* simple patch.

It doesn't fix the current ugliness. While testing I noticed that the current ENUM code fails if there are no "search => ..." entries in the enum.conf file.
(which were completely ignored since removing app_enum.c)

By: Olle Johansson (oej) 2006-10-16 09:55:24

Can you explain in a few words what the "very simple" patch fixes? Thanks.

By: Olle Johansson (oej) 2006-10-31 04:55:21.000-0600

otmar, to work forward, you need to respond :-)

Committed the simple patch to 1.4 and trunk. What's next? Are we done with this bug report and can continue in 5526 and 5666?

By: Olle Johansson (oej) 2006-10-31 04:59:27.000-0600

Committed the simple patch to svn 1.4 - rev 46631

By: otmar (otmar) 2006-10-31 05:46:47.000-0600

Sorry, I seem to have missed your question.

Basically, the simple patch just fixes the stuff from the description.

(and it looks like a bit more cleanup in enum.c got included there as well)

By: jmls (jmls) 2006-11-20 11:50:18.000-0600

ping. housekeeping

By: Serge Vecher (serge-v) 2006-11-21 09:40:14.000-0600

otmar: is the extended patch (asterisk-1.4.0-beta2-ienum.diff) separate from patches in 5526 and 5666? If so, it will need to be redone against trunk.

By: otmar (otmar) 2006-11-21 11:20:57.000-0600

serge: the large diff I posted here incorporated all the changes of the other bugs in a cleaner and better way. Including full documentation and a lot of other cleanup-work.

I haven't looked at the state of trunk. Unless there were other enum-related changes recently, we're better off with 1.4.0beta2 plus the patch from here. You know, there was a reason why I added notes to the other two patches that I've submitted a cleaned up set of patches in ASTERISK-7871. There are no "applied to trunk" notes to those, indicating that they were accepted into trunk.

In other words, you're asking me to provide diffs a third time for the same features as once again someone modified the code before my patches got incorporated.

This stopped being funny in June.

By: otmar (otmar) 2007-01-11 06:00:26.000-0600

I've just uploaded a new patch (relativ to svn trunk as of this week) which once again contains:

* Lots of enum related cleanup.
* Unified handling of various enum variants:
  - ISN
  - Direct
  - Infrastructure ENUM
* Got rid of obsoleted config-file options
* Full documentation update
* even fixed the cidname lookup

By: Jason Parker (jparker) 2007-01-15 16:06:06.000-0600

Just to clarify..

Have issues 5526 and 5666 been obsoleted by this?  Can/should they be closed, but still referenced from here?

By: otmar (otmar) 2007-01-16 02:49:12.000-0600

qwell,

yes. It makes sense to mark those two as closed.

svn-ienum-20070111.diff does all that in a clean an consistent way.

By: John Todd (jtodd) 2007-02-02 13:11:32.000-0600

At a minimum, it would seem at least that TRUNK should no longer indicate in the hints for "core show function ENUMLOOKUP" that record number is defaulting to "1".  This is not true, and I'm sure Otmar's patches take care of that, but right now it is required to install a record number in the lookup otherwise it will fail.  So, I suppose there is a short-term documentation repair before this long-term useful patch gets integrated into TRUNK.

This fails:

exten => _X.,n,Set(isnresult=${ENUMLOOKUP(${EXTEN},sip,,,freenum.org)})

This works:

exten => _X.,n,Set(isnresult=${ENUMLOOKUP(${EXTEN},sip,,1,freenum.org)})

By: otmar (otmar) 2007-02-05 05:31:55.000-0600

Yes, my patch fixes that.

+ if (context.position < 1) /* 0th place makes no sense */
+ context.position = 1;

btw, I recently noted that the long documentation in enum.txt contains
errors:

This works:
exten => 100,1,Set(foo=${ENUMLOOKUP(+13015611020,ALL,c,,loligo.com)})

This doesn't:
exten => _011.,n,Dial(SIP/${ENUMLOOKUP(+${EXTEN:3},sip,,${counter})})

It seems like if ENUMLOOKUP isn't called within Set, then the parameter parsing goes haywire. I haven't checked why.

By: jmls (jmls) 2007-05-28 02:35:11

ping. housekeeping

By: Jason Parker (jparker) 2007-07-09 17:54:23

Would somebody be willing/able to test the svn-ienum-20070111.diff patch?

I reviewed the diff, and most of it looks okay.  I'd like to commit/close this if testing is successful.

By: Tilghman Lesher (tilghman) 2007-08-31 12:31:46

It's been two months since the last note.  Is anybody willing to test this and give us feedback?

By: bjweeks (bjweeks) 2007-12-02 00:31:10.000-0600

The patch no longer applies cleanly to trunk.

By: snuffy (snuffy) 2007-12-02 03:22:08.000-0600

I got bored and decided to make this compile to latest trunk.
If i'm not stepping on anyone's toes i'll upload it.

Skipped the options part and used just ast_verb(num,text), also no enum.txt it has been made into enum.tex under the doc dir. So i've left it out for now



By: John Todd (jtodd) 2007-12-02 12:27:39.000-0600

snuffy: I guess I'm unclear on why you would leave out the options.  There were multiple, fairly important things in the options list that are not replicable just with a query.  (ISN, Infrastructure mode, direct DNS query, removal of method-type)

By: snuffy (snuffy) 2007-12-02 13:28:45.000-0600

jtodd.. i didn't mean the enum options themselves..
i simply ment the 'debug level' stuff aka where ast_verbose was mentioned etc.

Does not use the verbose level from the config file since i believe it should be like all other apps. Anyone else agree?

I will upload patch if no-one has any issues with that.



By: Alex Nikolov (alexnikolov) 2007-12-14 19:45:59.000-0600

the patch is not clean to trunk 1.4.15

can you please fix your patch and I will test immediately

regards

A

patching file func_enum.c
Hunk #1 FAILED at 90.
Hunk #2 FAILED at 328.
Hunk #3 FAILED at 383.
3 out of 3 hunks FAILED -- saving rejects to file func_enum.c.rej
can't find file to patch at input line 114
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: include/asterisk/enum.h
|===================================================================
|--- include/asterisk/enum.h    (revision 90471)
|+++ include/asterisk/enum.h    (working copy)
--------------------------



By: snuffy (snuffy) 2007-12-16 01:13:55.000-0600

I have now uploaded a 1.4 svn version as well

By: Alex Nikolov (alexnikolov) 2008-01-07 16:20:31.000-0600

and I have..
patching file func_enum.c
Hunk #1 FAILED at 35.
Hunk #2 FAILED at 82.
Hunk #3 FAILED at 447.
Hunk #4 FAILED at 498.
Hunk ASTERISK-1 FAILED at 507.
Hunk ASTERISK-2 FAILED at 562.
Hunk ASTERISK-3 FAILED at 583.
Hunk ASTERISK-4 FAILED at 613.
Hunk ASTERISK-5 FAILED at 622.
Hunk ASTERISK-6 FAILED at 636.
Hunk ASTERISK-7 FAILED at 658.
Hunk ASTERISK-8 FAILED at 672.
Hunk ASTERISK-9 FAILED at 696.
Hunk ASTERISK-10 FAILED at 706.
Hunk ASTERISK-11 FAILED at 720.
Hunk ASTERISK-12 FAILED at 755.
Hunk ASTERISK-13 FAILED at 1002.
17 out of 17 hunks FAILED -- saving rejects to file func_enum.c.rej

By: snuffy (snuffy) 2008-01-07 17:34:52.000-0600

alexnikolov - what version are you trying to patch against?

By: Alex Nikolov (alexnikolov) 2008-01-08 05:05:19.000-0600

Trunk 1.4.17 and appears that in this version as oppose 1.4.13the enum lookup works I will try test this further

By: jmls (jmls) 2008-02-06 04:29:09.000-0600

alexnikolov, did you test it further ?

By: Tilghman Lesher (tilghman) 2008-03-26 18:13:50

Patch updated to current.

By: Tilghman Lesher (tilghman) 2008-04-17 12:59:37

Guys, we need some testing love on this issue, or it will be closed.

By: Brett Bryant (bbryant) 2008-05-01 11:36:46

otmar, it seems like your patch isn't backwards compatible with what is currently in trunk making it unable to be merged.

Below are the results of my dialplan tests.

Testing with trunk...
   -- Executing [2@default:1] Answer("Zap/4-1", "") in new stack

   -- Executing [2@default:2] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,,,,loligo.com)") in new stack
   -- Executing [2@default:3] NoOp("Zap/4-1", "2203@sip.fox-den.com") in new stack

   -- Executing [2@default:4] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,tel,,,loligo.com)") in new stack
   -- Executing [2@default:5] NoOp("Zap/4-1", "+12125551212") in new stack

   -- Executing [2@default:6] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,sip,c,,loligo.com)") in new stack
   -- Executing [2@default:7] NoOp("Zap/4-1", "3") in new stack

   -- Executing [2@default:8] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,tel,,2,loligo.com)") in new stack
   -- Executing [2@default:9] NoOp("Zap/4-1", "+12125551212") in new stack

   -- Executing [2@default:10] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,ALL,c,,loligo.com)") in new stack
   -- Executing [2@default:11] NoOp("Zap/4-1", "6") in new stack

   -- Executing [2@default:12] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,ALL,,2,loligo.com)") in new stack
   -- Executing [2@default:13] NoOp("Zap/4-1", "tel:+12125551212") in new stack

   -- Executing [2@default:14] NoOp("Zap/4-1", "ENUMLOOKUP(+437203001721)") in new stack
   -- Executing [2@default:15] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:16] NoOp("Zap/4-1", "ENUMLOOKUP(1234*256,,,,freenum.org)") in new stack
   -- Executing [2@default:17] NoOp("Zap/4-1", "//www.loligo.com/") in new stack

   -- Executing [2@default:18] NoOp("Zap/4-1", "ENUMLOOKUP(1234567890,sip,,1,enum.yoyodynelabs.com)") in new stack
   -- Executing [2@default:19] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:20] Hangup("Zap/4-1", "") in new stack


Testing with trunk + patch....

   -- Executing [2@default:1] Answer("Zap/4-1", "") in new stack

   -- Executing [2@default:2] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,,,,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='', suffix='loligo.com', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:3] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:4] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,tel,,,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='tel', suffix='loligo.com', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:5] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:6] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,sip,c,,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='sip', suffix='loligo.com', options='c', record=1
  == ENUM options(c): pos=1, options='1'
   -- Executing [2@default:7] NoOp("Zap/4-1", "0") in new stack

   -- Executing [2@default:8] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,tel,,2,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='tel', suffix='loligo.com', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:9] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:10] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,ALL,c,,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='ALL', suffix='loligo.com', options='c', record=1
  == ENUM options(c): pos=1, options='1'
   -- Executing [2@default:11] NoOp("Zap/4-1", "0") in new stack

   -- Executing [2@default:12] NoOp("Zap/4-1", "ENUMLOOKUP(+13015611020,ALL,,2,loligo.com)") in new stack
  == ast_get_enum(num='+13015611020', tech='ALL', suffix='loligo.com', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:13] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:14] NoOp("Zap/4-1", "ENUMLOOKUP(+437203001721)") in new stack
  == ast_get_enum(num='+437203001721', tech='sip', suffix='e164.arpa', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:15] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:16] NoOp("Zap/4-1", "ENUMLOOKUP(1234*256,,,,freenum.org)") in new stack
  == ast_get_enum(num='1234*256', tech='', suffix='freenum.org', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:17] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:18] NoOp("Zap/4-1", "ENUMLOOKUP(1234567890,sip,,1,enum.yoyodynelabs.com)") in new stack
  == ast_get_enum(num='1234567890', tech='sip', suffix='enum.yoyodynelabs.com', options='', record=1
  == ENUM options(): pos=1, options='0'
   -- Executing [2@default:19] NoOp("Zap/4-1", "") in new stack

   -- Executing [2@default:20] Hangup("Zap/4-1", "") in new stack
  == Spawn extension (default, 2, 20) exited non-zero on 'Zap/4-1'
   -- Hungup 'Zap/4-1'



By: snuffy (snuffy) 2008-05-04 12:19:08

I've worked on some of the issues..
Should hopefully have updated patch by end of week

By: snuffy (snuffy) 2008-05-05 12:14:08

I have updated the code again..
Found 1 or 2 errors..
Still has the following major problem.
cannot handle regex listed in bbryants test.
i'm at a loss atm figure someone else can cast their eyes over it.
also i think we should change the return from some of these functions to be inline with coding guidelines (returning 0 for success) naptr_parse is one that doesn't follow those rules but simple enough change.

*Please note there are some extra 'log_warnings' listed for my ease of debugging only*
Below are my latest test results:
test*CLI> console dial 12345
 == Console is full duplex
[May  6 02:12:56] NOTICE[22021]: console_video.c:130 console_video_start: voice only, console video support not present
   -- Executing [12345@default:1] NoOp("Console/dsp", ""ENUMLOOKUP(+13015611020,,,,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='', suffix='loligo.com', options='', record=1
 == ENUM options(): pos=1, options='0'
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:56] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:56] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:56] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 1 ms
   -- Executing [12345@default:2] NoOp("Console/dsp", "res enum +14155551212") in new stack
   -- Executing [12345@default:3] NoOp("Console/dsp", ""COUNT ENUMLOOKUP(+13015611020,,c,,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='', suffix='loligo.com', options='c', record=1
 == ENUM options(c): pos=1, options='1'
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:56] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:56] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:56] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 2 ms
   -- Executing [12345@default:4] NoOp("Console/dsp", "count enum 2") in new stack
   -- Executing [12345@default:5] NoOp("Console/dsp", ""ENUMLOOKUP(+13015611020,tel,,,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='tel', suffix='loligo.com', options='', record=1
 == ENUM options(): pos=1, options='0'
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:56] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:56] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:56] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 1 ms
   -- Executing [12345@default:6] NoOp("Console/dsp", "bleh enum ") in new stack
   -- Executing [12345@default:7] NoOp("Console/dsp", ""COUNT ENUMLOOKUP(+13015611020,sip,c,,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='sip', suffix='loligo.com', options='c', record=1
 == ENUM options(c): pos=1, options='1'
[May  6 02:12:56] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:56] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:56] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:56] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:56] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 1 ms
   -- Executing [12345@default:8] NoOp("Console/dsp", "count enum 0") in new stack
   -- Executing [12345@default:9] NoOp("Console/dsp", ""ENUMLOOKUP(+13015611020,tel,,2,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='tel', suffix='loligo.com', options='', record=2
 == ENUM options(): pos=2, options='0'
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:57] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:57] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:57] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 2 ms
   -- Executing [12345@default:10] NoOp("Console/dsp", "res enum +14155551212") in new stack
   -- Executing [12345@default:11] NoOp("Console/dsp", ""COUNT ENUMLOOKUP(+13015611020,ALL,c,,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='ALL', suffix='loligo.com', options='c', record=1
 == ENUM options(c): pos=1, options='1'
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:57] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:57] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:57] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 2 ms
   -- Executing [12345@default:12] NoOp("Console/dsp", "count enum 4") in new stack
   -- Executing [12345@default:13] NoOp("Console/dsp", ""ENUMLOOKUP(+13015611020,ALL,,2,loligo.com)"") in new stack
 == ast_get_enum(num='+13015611020', tech='ALL', suffix='loligo.com', options='', record=2
 == ENUM options(): pos=2, options='0'
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:57] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:57] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:57] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 2 ms
   -- Executing [12345@default:14] NoOp("Console/dsp", "res enum sip:2203@sip.fox-den.com") in new stack
   -- Executing [12345@default:15] NoOp("Console/dsp", ""ENUMLOOKUP(+437203001721)"") in new stack
 == ast_get_enum(num='+437203001721', tech='sip', suffix='e164.arpa', options='', record=1
 == ENUM options(): pos=1, options='0'
 == ast_get_enum() profiling: FAIL, 1.2.7.1.0.0.3.0.2.7.3.4.e164.arpa, 347 ms
   -- Executing [12345@default:16] NoOp("Console/dsp", "res enum ") in new stack
   -- Executing [12345@default:17] NoOp("Console/dsp", ""ENUMLOOKUP(1234*256,,,,freenum.org)"") in new stack
 == ast_get_enum(num='1234*256', tech='', suffix='freenum.org', options='', record=1
 == ENUM options(): pos=1, options='0'
 == ast_get_enum() profiling: FAIL, 6.5.2.4.3.2.1.freenum.org, 7 ms
   -- Executing [12345@default:18] NoOp("Console/dsp", "res enum ") in new stack
   -- Executing [12345@default:19] NoOp("Console/dsp", ""ENUMLOOKUP(1234567890,sip,,1,enum.yoyodynelabs.com)"") in new stack
 == ast_get_enum(num='1234567890', tech='sip', suffix='enum.yoyodynelabs.com', options='', record=1
 == ENUM options(): pos=1, options='0'
 == ast_get_enum() profiling: FAIL, 0.9.8.7.6.5.4.3.2.1.enum.yoyodynelabs.com, 348 ms
   -- Executing [12345@default:20] NoOp("Console/dsp", "res enum ") in new stack
 == ast_get_enum(num='+13015611020', tech='mailto', suffix='loligo.com', options='', record=1
 == ENUM options(): pos=1, options='0'
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+13015611020$: and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:549 parse_naptr: pattern:^\+*([^\*]*): and naptr:13015611020:
[May  6 02:12:57] WARNING[22021]: enum.c:551 parse_naptr: NAPTR Regex match failed.
[May  6 02:12:57] WARNING[22021]: enum.c:620 enum_callback: Failed to parse naptr :(
[May  6 02:12:57] WARNING[22021]: dns.c:234 dns_parse_answer: Failed to parse result
[May  6 02:12:57] WARNING[22021]: dns.c:276 ast_search_dns: DNS Parse error for 0.2.0.1.1.6.5.1.0.3.1.loligo.com
 == ast_get_enum() profiling: FAIL, 0.2.0.1.1.6.5.1.0.3.1.loligo.com, 1 ms
   -- Executing [12345@default:21] NoOp("Console/dsp", "MINE mail enum ") in new stack
   -- Executing [12345@default:22] Hangup("Console/dsp", "") in new stack
 == Spawn extension (default, 12345, 22) exited non-zero on 'Console/dsp'
<< Hangup on console >>
test*CLI> exit

By: John Todd (jtodd) 2008-05-05 16:10:33

A few notes on the testing of this:

1) The "default" technology really should be SIP in any of these queries, since that is the most typical technology to be used for DNS-based pointer lookups at this time.  This may be what causes some of the backwards compatibility issues that bbryant notes.

2) +437203001721 does not (any longer) have valid data in the DNS in e164.arpa, so will always fail.  It is useful only as a test to confirm failure modes.

3) enum.yoyodynelabs.com does not have valid NAPTR data in the DNS for 1234567890, so will always fail.  It is useful only as a test to confirm failure modes.

4) Snuffy: Please include your testing dialplan as a file attachment so I can duplicate experiments.  There's too much cruft to sift through in the last debug comment.

5) Freenum/ISN/ITAD parsing is broken with this patch.  The query goes to the DNS correctly for a NAPTR record and the DNS supplies a reply, but no valid NAPTRs are returned to the function call.

Other notes: as of today's TRUNK, this applies cleanly.

By: Brett Bryant (bbryant) 2008-05-05 17:55:07

jtodd, the dialplan i used for testing is added as an attachment.

By: John Todd (jtodd) 2008-05-05 23:17:06

There appear to be many, many problems with this patch as it stands now.  

- no default tech/method
- wrong counts on methods
- wrong results on specific priority queries
- inconsistent results over multiple queries (eventually all lookups fail)
- no valid replies at all for most query methods and types
- lots of problems with regexp issues (or at least, complaints in debug)

I've included a short not-quite-a-regression-test dialplan as an attachment (enum-extensions-test.conf) which anyone can feel free to extend to their heart's content.  I'm still using my own entries in the DNS as a source of test material in the DNS, since I have some artificial entries that are complex enough to exercise the various options of the lookup routines.

Otmar - do you have any sources of valid infrastructure ENUM test queries or objects in the public DNS that could be used in an extension of these tests?  I wasn't able to test with that.

By: otmar (otmar) 2008-05-06 08:44:37

Guys, I'm currently not in the position to promise a quick code review and testing.

regarding i-ENUM numbers, there are a few entries under i.3.4.e164.arpa, e.g. 0.0.0.1.6.0.3.1.i.3.4.e164.arpa. ( = +4313061000 ). Please don't call this number, though.

some of the algorithms I implemented a year ago for asterisk are no longer in the current IETF drafts. For the latest specs, see http://tools.ietf.org/html/draft-ietf-enum-combined-08

By: snuffy (snuffy) 2008-05-06 09:52:37

I've updated this file.. removing the extra regex searching.
Counting now works also

I also have a standard e164 for test. +43780004711
Found on enum website and will return results
so ENUMLOOKUP(+43780004711) would work.



By: Brett Bryant (bbryant) 2008-05-06 15:34:27

snuffy, I doubt this has anything to do with what you're trying to fix but when reviewing the code i modified the cclen function since it didn't work properly before.

By: John Todd (jtodd) 2008-05-06 15:42:05

Apparently, one or two of the test cases in my dialplan were incorrectly created, and I've also added a few more tests as well.  Same filename (enum-extensions-test.txt) but new dialplan code.

MOSTLY working - still a few glitches.  There are still some regexp issues - see the failure cases from my test dialplan.

By: snuffy (snuffy) 2008-05-06 22:31:11

I have incorporated your change bbyrant.
This version correctly identifies and does do the regex (putting number back)

Also to make the tests a little bit easier to read i've made a summary part.

I believe your test 5 and 6 are in error.. i have made a 13 and 14 which test and get what i believe to be correct.



By: John Todd (jtodd) 2008-05-07 02:26:49

Getting closer!

Got a warning on the compile:

  [CC] enum.c -> enum.o
enum.c: In function â??parse_naptrâ??:
enum.c:515: warning: pointer targets in passing argument 2 of â??regexecâ?? differ in signedness
enum.c:526: warning: pointer targets in assignment differ in signedness
enum.c:528: warning: pointer targets in assignment differ in signedness
  [CC] event.c -> event.o

Otmar: I tried an Infrastructure test.  Seems to work.  I'm afraid I'm too behind on my mailing lists to say if I know if the "i" zone delineator appears in places other than directly after the country code, nor do I know if this code is "hard-coded" for two digits or what.  Are there other examples that might exist "in the wild" that have the "i" in different places for testing purposes?

Snuffy: As for tests 5 and 6:  My versions are partially incorrect due to my sloppy typing (comments were right, but "Set" lines were wrong) but the new tests 13 and 14 you added aren't valid from a logic perspective, either.

An example Freenum/ISN lookup does this:
 1234*256 gets dialed.  Then, if the ISN flag ("i") is specified in the ENUMLOOKUP routine, the lookup turns into:  4.3.2.1.256.freenum.org

 Note that the "*" vanishes in the lookup, and that there are no "." characters between any of the digits in the "256" section.  Other than that, parsing is identical to any other ENUM-like lookup scheme - only the DNS record is different during the lookup.  Asterisk has worked correctly with these types of lookups for several years (until ENUM broke more fundamentally.)  See http://www.freenum.org/ for details.  Typically the regexp removes the ITAD and the * from the resulting lookup, so something like "1234*256" gets digested into "1234", but this of course is up to the person creating the NATPR record.

 The test5 SIP NAPTR regexp that is in place for 4.3.2.1.256.freenum.org should result in "1234@loligo.com", and the IAX2 NAPTR you added should result in "@204.91.156.10/1234" as a result (without the quotes, of course.)



By: snuffy (snuffy) 2008-05-07 02:51:22

jtodd that is easy fixed i can just add extra rule for that isn lookup.
aka if 1234*256 just ditch everythin after *.
I didn't realise the rule and was just coding to produce good results.



By: John Todd (jtodd) 2008-05-07 02:58:13

OK.  It's not quite "ditch everything after the *" - the ITAD portion actually gets used in the DNS lookup.  I think you can see from the example how it's supposed to work, but I just wanted to be clear.

Also: how many digits are supported in these lookups, for both "normal" ENUM style queries, as well as Freenum/ISN queries?  The Freenum/ISN stuff may get pretty long - 20 digits on the left side of the * is not unforseeable, and on the right side of the * there will hopefully be six or seven digits (though the limit is a 32 bit number.)  Are there buffer overflow checks on these sequences?  (Sorry, I'm not a coder or I'd look myself - I just break things and test them.)

By: otmar (otmar) 2008-05-07 09:54:07

>Otmar: I tried an Infrastructure test. Seems to work. I'm afraid I'm too behind on my mailing lists to say if I know if the "i" zone delineator appears in places other than directly after the country code, nor do I know if this code is "hard-coded" for two digits or what.

It's supposed to be a the country code. See Section 5 in http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-08.txt

>Are there other examples that might exist "in the wild" that have the "i" in different places for testing purposes?

Not that I know.

By: snuffy (snuffy) 2008-05-07 11:08:36

Jtodd/bbyrant the issue with the ISN should now be fixed in latest patch i've uploaded.
Please let us know how you go with it.

By: John Todd (jtodd) 2008-05-07 15:12:12

This patch doesn't seem to want to apply cleanly, but I don't know what I'm doing with "patch" so maybe this is my fault:

[root@voip asterisk]# patch -p0 < ../asterisk-patches/enum-patch.2008050701.txt
patching file main/enum.c
patch: **** malformed patch at line 596:        context->dst = dst;                     /* Return string */

[root@voip asterisk]# date
Wed May  7 13:12:14 PDT 2008
[root@voip asterisk]#

By: snuffy (snuffy) 2008-05-07 17:05:35

Sorry about that guys..
It should patch fine now.

By: John Todd (jtodd) 2008-05-08 17:19:59

OK, this latest patch passes all my tests.  Can some other people test it, please?

By: Brett Bryant (bbryant) 2008-05-09 12:21:05

This has also passed the tests I had been running. I'll do some more testing with the new features and such some time today.

Thanks Snuffy, for doing all the work on this patch.

By: Digium Subversion (svnbot) 2008-05-09 14:48:56

Repository: asterisk
Revision: 115584

U   trunk/funcs/func_enum.c
U   trunk/include/asterisk/enum.h
U   trunk/main/enum.c

------------------------------------------------------------------------
r115584 | bbryant | 2008-05-09 14:48:54 -0500 (Fri, 09 May 2008) | 15 lines

The following patch adds new options and alters the default behavior of the ENUM* functions. The TXCIDNAME lookup function has also gotten a
new paramater. The new options for ENUM* functions include 'u', 's', 'i', and 'd' which return the full uri, trigger isn specific rewriting, look
for branches into an infrastructure enum tree, or do a direct dns lookup of a number respectively. The new paramater for TXCIDNAME adds a
zone-suffix argument for looking up caller id's in DNS that aren't e164.arpa.

This patch is based on the original code from otmar, modified by snuffy, and tested by jtodd, me, and others.

(closes issue ASTERISK-7871)
Reported by: otmar
Patches:
     20080508_bug8089-1.diff
- original code by otmar (license 480),
- revised by snuffy (license 35)
Tested by: oej, otmar, jtodd, Corydon76, snuffy, alexnikolov, bbryant

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

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

By: Digium Subversion (svnbot) 2008-05-09 14:49:52

Repository: asterisk
Revision: 115585

_U  branches/1.6.0/

------------------------------------------------------------------------
r115585 | bbryant | 2008-05-09 14:49:51 -0500 (Fri, 09 May 2008) | 22 lines

Blocked revisions 115584 via svnmerge

........
r115584 | bbryant | 2008-05-09 14:54:45 -0500 (Fri, 09 May 2008) | 15 lines

The following patch adds new options and alters the default behavior of the ENUM* functions. The TXCIDNAME lookup function has also gotten a
new paramater. The new options for ENUM* functions include 'u', 's', 'i', and 'd' which return the full uri, trigger isn specific rewriting, look
for branches into an infrastructure enum tree, or do a direct dns lookup of a number respectively. The new paramater for TXCIDNAME adds a
zone-suffix argument for looking up caller id's in DNS that aren't e164.arpa.

This patch is based on the original code from otmar, modified by snuffy, and tested by jtodd, me, and others.

(closes issue ASTERISK-7871)
Reported by: otmar
Patches:
     20080508_bug8089-1.diff
- original code by otmar (license 480),
- revised by snuffy (license 35)
Tested by: oej, otmar, jtodd, Corydon76, snuffy, alexnikolov, bbryant

........

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

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