[Home]

Summary:ASTERISK-09407: Regular expression parsing for ENUM entries on ENUMLOOKUP fails
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-05-08 19:00:56Date Closed:2011-06-07 14:08:13
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Functions/func_enum
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:ENUMLOOKUP returns errors when it should return a URL.  The data in the DNS is valid, but Asterisk chokes on the re-write.  Verified on TRUNK from a few days ago, and I haven't seen any ENUM-related fixes so it's a safe bet it's still broken.



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

Reported to me by "Dietmar Zlabinger" <dietmar@zlabinger.at>:

My question was, if the enum-lookup-application has a problem with
the regular expression I use on my ENUM-record (at e164.arpa).

So, when I do:

dig 4.0.3.8.5.0.8.5.1.3.4.e164.arpa. naptr

; <<>> DiG 9.3.4 <<>> 4.0.3.8.5.0.8.5.1.3.4.e164.arpa. naptr
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35310
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;4.0.3.8.5.0.8.5.1.3.4.e164.arpa. IN    NAPTR

;; ANSWER SECTION:
4.0.3.8.5.0.8.5.1.3.4.e164.arpa. 60 IN  NAPTR   100 10 "u" "E2U+sip"
"!^\\+43158058(.+)$!sip:\\1@rtr.at!" .

;; Query time: 34 msec
;; SERVER: 127.0.0.1ASTERISK-49(127.0.0.1)
;; WHEN: Wed May  9 00:34:36 2007
;; MSG SIZE  rcvd: 109

I get the correct record back.
But when I do the query in Asterisk, all I get is an error:

   -- Executing EnumLookup("SIP/sipura1-081add88", "43158058304") in new
stack
May  9 00:35:55 WARNING[22221]: enum.c:231 parse_naptr: NAPTR Regex match
failed.
May  9 00:35:55 WARNING[22221]: enum.c:347 enum_callback: Failed to parse
naptr :(
May  9 00:35:55 WARNING[22221]: dns.c:163 dns_parse_answer: Failed to
parse result

But when I test it on a web-ENUM-Client the result is ok:

http://nona.net/features/enum/?sourceid=mozilla-search&e164=43158058304

Comments:By: James Golovich (jamesgolovich) 2007-08-13 16:35:07

Just trying to hit up some older bugs and looking at this it seems as if its already been addressed by doc/enum.txt:

 a) The use of "+" in lookups is confusing, and warrants further
 explanation.  All E.164 numbers ("global phone numbers") by
 definition need a leading "+" during ENUM lookup.  If you neglect to
 add a leading "+", you may discover that numbers that seem to exist
 in the DNS aren't getting matched by the system or are returned with
 a null string result.  This is due to the NAPTR reply requiring a
 "+" in the regular expression matching sequence.  Older versions of
 Asterisk add a "+" from within the code, which may confuse
 administrators converting to the new function.  Please ensure that
 all ENUM (e164.arpa) lookups contain a leading "+" before lookup, so
 ensure your lookup includes the leading plus sign.  Other DNS trees
 may or may not require a leading "+" - check before using those
 trees, as it is possible the parsed NAPTRs will not provide correct
 results unless you have the correct dialed string.  If you get
 console messages like "WARNING[24907]: enum.c:222 parse_naptr: NAPTR
 Regex match failed." then it is very possible that the returned
 NAPTR expects a leading "+" in the search string (or the returned
 NAPTR is mis-formed.)
By: Jon Creasy (johann8384) 2007-08-13 16:48:24

I do not think that is the case. I have experienced this exact problem and I know I was using the full e.164 format (+1NXXNXXXXXX for a NA number) and it was not returning properly.

I won't be able to do it until later this week but if it is useful I can setup a machine to test against our ENUM databases to see if it is still broken. Last time I tested OpenSER worked just fine but Asterisk failed on the exact same lookups in the exact same DNS server.

At the time I was using Asterisk 1.4.4 if I remember correctly and it was broken in trunk at that time as well.
By: James Golovich (jamesgolovich) 2007-08-13 16:53:12

Please provide an example that doesn't work.  Using the provided information    
above:

exten => *11,1,Set(foo=${ENUMLOOKUP(43158058304)})
returns:
[Aug 13 14:48:23] WARNING[3967]: enum.c:247 parse_naptr: NAPTR Regex match failed.
[Aug 13 14:48:23] WARNING[3967]: enum.c:363 enum_callback: Failed to parse naptr :(
[Aug 13 14:48:23] WARNING[3967]: dns.c:226 dns_parse_answer: Failed to parse result
[Aug 13 14:48:23] WARNING[3967]: dns.c:267 ast_search_dns: DNS Parse error for 4.0.3.8.5.0.8.5.1.3.4.e164.arpa
   -- Executing [*11@internal:1] Set("Zap/1-1", "foo=") in new stack


exten => *11,n,Set(foo=${ENUMLOOKUP(+43158058304)})
returns:
-- Executing [*11@internal:2] Set("Zap/1-1", "foo=304@rtr.at") in new stack

So +43158058304 works just fine, and does not work without the +
By: John Todd (jtodd) 2007-08-14 20:49:42

I also get the "correct" answer using the leading +.   I should read my own notes (I wrote those sections of enum.txt!) more often.

Connected to Asterisk SVN-trunk-r78347 currently running on jt-test (pid = 29014)
Verbosity was 0 and is now 3
 == Using TOS bits 0
 == Using CoS mark 5
   -- Executing [333@from-sip:1] Set("SIP/1234-09eb5228", "foo=304@rtr.at") in new stack
   -- Auto fallthrough, channel 'SIP/1234-09eb5228' status is 'UNKNOWN'
   -- Executing [h@from-sip:1] Hangup("SIP/1234-09eb5228", "") in new stack
 == Spawn extension (from-sip, h, 1) exited non-zero on 'SIP/1234-09eb5228'
jt-test*CLI>


Now, this doesn't mean there aren't other bugs in ENUMLOOKUP...

Johann - can you let us know what problems you're running into that appear to be related to this?  Otherwise we'll close this out after some time.
By: James Golovich (jamesgolovich) 2007-08-18 02:50:48

I'd like to see any other case that isn't working.  One thing we are up against when it comes to the regular expression handling is that we use the libc regex library to process them, so if there is a regexp we aren't handling properly I'm not sure what we can do besides find a diff regexp library to use, create our own regexp library, or add code to deal with these special instances (which could be a slippery slope)
By: Jon Creasy (johann8384) 2007-08-21 21:14:02

I could not recreate any problem I may have had with it.
By: Joshua C. Colp (jcolp) 2007-08-22 11:07:58

Alrighty then since johann8384 has reported back that it seems to be fine... I'm closing this out. If anyone can come up with a situation that actually causes this to happen feel free to reopen.