[asterisk-bugs] [Asterisk 0008089]: [patch] The record# parameter in ENUMLOOKUP is ignored

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8089 
====================================================================== 
Reported By:                otmar
Assigned To:                bbryant
====================================================================== 
Project:                    Asterisk
Issue ID:                   8089
Category:                   Functions/NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0-beta5 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 50028 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             10-04-2006 10:19 CDT
Last Modified:              05-07-2008 02:26 CDT
====================================================================== 
Summary:                    [patch] The record# parameter in ENUMLOOKUP is
ignored
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0005526 [patch] Carrier ENUM support + some rew...
related to          0005666 [patch][post 1.4] Add NAPTR string pars...
related to          0011560 ENUM LOOKUP IS NOT WORKING AGAIN
====================================================================== 

---------------------------------------------------------------------- 
 jtodd - 05-07-08 02:26  
---------------------------------------------------------------------- 
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.

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

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-07-08 02:26  jtodd          Note Added: 0086514                          
======================================================================