Summary:ASTERISK-00585: Enum regexp replacements error
Reporter:Olle Johansson (oej)Labels:
Date Opened:2003-11-27 15:14:10.000-0600Date Closed:2011-06-07 14:05:29
Versions:Frequency of
Environment:Attachments:( 0) diff.enum.c.txt
Description:Somethings wrong with ENUM, the ENUM debug stub in enum.c does not work any more (I don't know if it ever has, but it looks right:
 strcpy(regexp, "!^\\+43(.*)$!\\1@bla.fasel!");

I get this:
Regexp: !^\+43(.*)$
Pattern: ^\+43(.*)$
Subst: \1@bla.fasel!
WARNING[20501]: File enum.c, Line 193 (parse_naptr): Regex match failed.
WARNING[20501]: File enum.c, Line 238 (enum_callback): Failed to parse naptr :(


I've enable the DEBUG output that prints "Pattern:" etc.

Comments:By: Olle Johansson (oej) 2003-11-27 15:32:55.000-0600

Additional output. Regexp1 is the one in DNS, Regexp 2 is the stripped one after picking out pattern and subst.

Regexp 1: !^+000462(.*)$!sip:\1@vx.runbo.webway.org!
Regexp 2: !^+000462(.*)$
Pattern: ^+000462(.*)$
Subst: sip:\1@vx.runbo.webway.org
Naptrinput: +0004623000
WARNING[22549]: File enum.c, Line 186 (parse_naptr): Regex compilation error (regex = "!^+000462(.*)$").
WARNING[22549]: File enum.c, Line 242 (enum_callback): Failed to parse naptr :(

By: Brian West (bkw918) 2003-11-27 15:39:25.000-0600

show me your full enum NAPTR record.  I use enum daily and it works flawlessly.

By: Olle Johansson (oej) 2003-11-27 16:04:35.000-0600

I try all versions: IN NAPTR 100 10 "u" "E2U+IAX2" "!^\\+*(.*)$!iax2:webwayvx/3000!" .
*. IN NAPTR 100 10 "u" "E2U+SIP" "!^\\+000767(.*)$!sip:\\1@fwd.pulver.com!" .
*. IN NAPTR 100 10 "u" "E2U+SIP" "!^\\\\+000461(.*)$!sip:\\\\1@edvina.net!" .

Thank you for looking into this.

By: Olle Johansson (oej) 2003-11-27 16:05:35.000-0600

Working NAPTR record from Jeremy McNamara:

; Mecosta Test routing
*.         IN      NAPTR 100 10 "u" "E2U+X-IAX2" "!^\\+(.*)$!iax2:gw-mecosta/\\1!" .

By: Olle Johansson (oej) 2003-11-27 16:06:51.000-0600

Example from enum.c (not working if I understand BKW):

      strcpy(regexp, "!^\\+43(.*)$!\\1@bla.fasel!");

By: Brian West (bkw918) 2003-11-27 16:09:18.000-0600



This looks correct:

Tell me if that helps.

By: Olle Johansson (oej) 2003-11-28 01:33:43.000-0600

I know what confused me. The printf swallows the \1 and prints only 1, even though the "\" is there. That's why the debug output is wrong. Maybe we need to fix something with the debug output so other people doesn't fall into the same trap.

I'll continue testing. Thank you for your assistance.

By: Brian West (bkw918) 2003-11-28 10:30:15.000-0600

so we need to fix the debug output.. :)

By: Olle Johansson (oej) 2003-11-29 03:17:26.000-0600

This is nasty. Discovered that a zone transfer between my DNS servers removes slashes. The same zone serial no, different zones. Bug in Bind? Investigating.
Asterisk still not handling the regexp...

By: Olle Johansson (oej) 2003-11-30 02:59:30.000-0600

I updated all my DNS servers to bind 9, so there's no problem there any more. However, the EnumLookup on my FreeBSD server works correct, but not on my Linux server using the same DNS server.
Which regexp library is used?

By: Olle Johansson (oej) 2003-11-30 04:41:57.000-0600

The app enum_lookup doesn't treat TEL uri:s according to the standard. A plus sign is _not_ required.
ast_log(LOG_NOTICE, "tel: uri must start with a \"+\" (got '%s')\n", c);

By: Brian West (bkw918) 2003-11-30 11:07:52.000-0600

Read the RFC.. a plus sign is required.

By: Olle Johansson (oej) 2003-11-30 11:13:21.000-0600

Example from the rFC 2916:

   IN NAPTR 10 10 "u" "tel+E2U"    "!^.*$!tel:+46-8-9761234!"       .

And the tel draft:

            This URI points to a phone number in Finland. The hyphens
            are included to make the number more human-readable; they
            separate country, area codes and subscriber number.


            The URI describes a local phone number valid within the
            context "cs.columbia.edu".


            The URI describes a local phone number that is valid within
            a particular phone prefix.

Guess we have to be prepared for all three cases. It'll bee interesting writing
dial plans to be prepared for this.
And, as you see, the plus sign is not required.

By: Olle Johansson (oej) 2003-11-30 11:14:27.000-0600

The above cut from an earlier mail on asterisk-dev.

By: Olle Johansson (oej) 2003-11-30 11:20:02.000-0600

The TEL url is documented here
Revision in process by

...which RFC did you refer to?

edited on: 11-30-03 11:12

By: otmar (otmar) 2003-12-01 07:51:14.000-0600

As the one responsible for some of the code under question here:

According to my RFC research prior to writing the tel: code, the + is
required. Re-reading rfc2806 tells me, that we have:

Phone numbers can be either "global" or "local". Global numbers are
unambiguous everywhere. Local numbers are usable only within a
certain area, which is called "context", see section 2.5.2.

In an ENUM setting, where you don't know where the querier of the NATPR is, these "local numbers" do *not* make sense. One might work around that with the phone context, but that's IMHO a bad hack.

To answer the other questions:

* The regexp library is the system POSIX library (on linux: within libc)

* The code already copes with non-digit spacers in tel uris.


By: Olle Johansson (oej) 2003-12-01 08:44:49.000-0600

In e164.arpa I would think the plus sign is required, since the root is country codes and it's used globally.

When using ENUM-like structures for local routing, the plus sign is not required in the TEL url. For me, it's very useful for local routing without the plus, since the plus sign would indicate a global PSTN telephone number and I use it for local Asterisk extensions and need to make a distinction between global ENUM (e164.arpa) and my local routing this way.

I still believe it's an error to make it an error. Can't we make it a warning, not an error? That way, it's up to me if I want to use it or not.

By: otmar (otmar) 2003-12-01 08:52:21.000-0600

Make it a config-file option. (defaulting to ERROR)

And you might want to add code to save the phone-context to another variable.

By: Brian West (bkw918) 2003-12-06 11:09:58.000-0600

If this is still a problem message me on IRC and we will reopen it.

By: Olle Johansson (oej) 2003-12-07 07:31:58.000-0600

Have small patch - I've added explanations and comments to the source while digging...