Summary:ASTERISK-05378: [patch] Carrier ENUM support + some rewrites for ENUMLOOKUP()
Reporter:otmar (otmar)Labels:
Date Opened:2005-10-27 08:26:08Date Closed:2008-01-15 16:55:58.000-0600
Versions:Frequency of
Environment:Attachments:( 0) c-enum2.diff
Description:This patch adds experimental support for carrier ENUM as proposed by ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-haberler-carrier-enum-01.txt.

Furthermore, it contains a cleanup of the ISN/ITAD code (which is no longer active by default) and more verbose (configurable in enum.conf) tracing output.

I don't consider this patch to be fully tested yet. Don't run it on production systems. This release is to get some feedback on the design decisions I have made. e.g.

* The options parameter can now take multiple flags. e.g. "2i" take the second URI from a ISN-enabled ENUM lookup. "cr" count URIs in a carrier ENUM tree.

* I've removed the "prepend 'n' to number to disable ISN hack. ISN is now only turned on via a options parameter.

* some more verbosity

I'd appreciate feedback on the code. I you have comments on the general idea of this carrier ENUM functionality, please subscribe to the IETF enum mailinglist and join the discussion there. I see little value in duplicate the discussion here. (see http://www.ietf.org/html.charters/enum-charter.html)


From the README.enum:

 k) Carrier ENUM usage: If "r" is contained in the options field, then
 the lookup will follow the Carrier ENUM rules as proposed in
 Summary: an additional label will be inserted into the ENUM domain
 name to branch off the carrier tree from the defaul user-ENUM tree.

 The label to insert is configured in enum.conf as:

 branchlabel     => carrier


 The position of this label within the DNS tree is controlled by the blr_alg
 parameter (also in enum.conf). Currently, there are two algorithms to
 choose from:

 blr_alg         => cc
 This algorithm always inserts the carrier label at the country-code level.
 Examples: carrier.1.e164.arpa, carrier.3.4.e164.arpa, carrier.2.5.3.e164.arpa
 This is the default.

 blr_alg         => txt
 With this setting, ENUMLOOKUP will look for a TXT record at
 <branchlabel>.<reverse-country-code>.<apex> to indicate after how many digits the
 carrier label should in inserted. e.g. a

 carrier.1.e164.arpa.  IN      TXT     "4"

 record will tell the module to look for carrier ENUM for +1 234 5678 999 at
Comments:By: Olle Johansson (oej) 2005-10-27 08:34:36

Great. Will have to look into this, but after 1.2 is out. Thank you for contributing! Keep testing... :-)


By: John Todd (jtodd) 2005-10-31 15:56:27.000-0600

I'd probably want to see the additional feature specifications find their way into the function call instead of being included in a configuration file that is outside the reach of the dialplan administrator.  Is that possible?

PS: I've tested basic functionality; seems to work.

Also: is the "+" sign being added within the code by default again?  I can't tell easily.  This was removed for a reason: some private ENUM trees don't use "+" since they're not rooted in e.164, so I opted to let the user figure out that they needed to add "+" to the query string instead of adding it in a hidden way in the code.

By: otmar (otmar) 2005-11-01 12:25:53.000-0600

I certainly could convert the two parameters I take from the config-file into two more arguments of the function call. As we're up to 3 arguments already I'm not that comfortable with this idea. The parameters are of a very generic "what kind of draft/rfc do we use"-type which even might go away once the standard stabilizes.

About the "+", I certainly did not make a conscious change in that respect. I will check, though.

Are you comfortable with the changes I made to the ISN/ITAD syntax? (no longer default, own flag, no more prefix-n to disable)

By: John Todd (jtodd) 2005-11-02 01:10:53.000-0600

I am not certain on the behavior of the + now; I was just lazy and haven't checked all iterations of the code.  

I'm fine with the ISN changes; having this as an option instead of a hidden "automatic" conversion makes more sense.

By: Mark Spencer (markster) 2006-01-07 17:26:54.000-0600

Is this ready for merger?

By: Olle Johansson (oej) 2006-02-22 09:43:27.000-0600

This patch does not apply cleanly to svn trunk. Can we please get an update?

By: Olle Johansson (oej) 2006-02-22 09:45:43.000-0600

On my OS/X, I get a linking error for cclen and blr_text

enum.c:502: warning: implicit declaration of function 'cclen'
enum.c:511: warning: implicit declaration of function 'blr_txt'


By: Olle Johansson (oej) 2006-02-22 09:47:18.000-0600

Reading the patch, something must have failed in the merging. Will try again...

By: Olle Johansson (oej) 2006-02-22 09:55:28.000-0600

Included in test-this-branch for testing by the hard working Asterisk community

By: Olle Johansson (oej) 2006-04-04 08:37:14

Any test results from the community?

By: Olle Johansson (oej) 2006-05-02 09:08:46

I need an update for the current svn trunk as well as some feedback. Don't want to give this up, but need some community work here, friends :-)

By: otmar (otmar) 2006-05-02 09:33:56

Austria will start with an Infrastructure ENUM trial ASAP.

We've changed the specs a bit and submitted some new documents to the IETF (draft-lendl-enum-branch-location-record-00, ...)

I've brought my patches to OpenSer up to speed last week and will overhaul the Asterisk side as well.

I'm off for the next 12 days, so don't expect any patch that quickly. But I will submit one as soon as I can.

By: Olle Johansson (oej) 2006-05-02 10:34:37

My problem is that it broke test-this-branch. I guess I will have to revert to plain enum.c while waiting. Have a nice trip!

By: otmar (otmar) 2006-05-19 10:40:11

I've started to work on this again.

This is not a final patch yet.

Meanwhile, someone broke the ENUM code:                                                                                
This patch changes the syntax of the ENUMLOOKUP funktion from                                                          
[splitting the options and the record# parameter.]                                                                    
The record# was ignored in the subsequent code.                                                                        
I'm not sure whether that change was simply the result of                                                              
the unclear synopsis of the older version.

I'll have a chat with oej on how to proceed.

By: Serge Vecher (serge-v) 2006-06-05 11:06:28

otmar: what's the status here?

By: otmar (otmar) 2006-06-06 09:37:59


I was attending a conference the last week and thus a bit distracted.

I'd like to have some guidance whether I should restore the API that was changed or whether I should fix up the code with the new API.

Can you comment on that?

By: Serge Vecher (serge-v) 2006-06-06 09:46:36

well, the change was to the standard application processing macros, so it's probably the latter. If possible, could you join the #asterisk-dev channel on IRC to confirm this?

By: otmar (otmar) 2006-07-06 12:46:10

Sorry, I've found less time to work on that issue than expected.

I'm off for 3 weeks of vacation now, I'll try to start working on this when I'm back.

By: otmar (otmar) 2006-10-04 10:25:36

I finally managed to clean up my patch, add some other ideas (see ASTERISK-5518) and clean up both code and documentation.

As someone else broke the ENUM code meanwhile, I've submitted it as a new bug:

By: Serge Vecher (serge-v) 2006-11-02 15:51:36.000-0600

test-this-branch has gone Tjad? Tjad?. We need an updated trunk patch here. Thank you, bye!

By: otmar (otmar) 2007-01-11 06:03:44.000-0600

I've submitted a new patch vs. trunk to ASTERISK-7871, see http://bugs.digium.com/file_download.php?file_id=12760&type=bug

Do else do you need to get that thing finally into the code-base for the next version?

By: Serge Vecher (serge-v) 2007-01-11 09:02:58.000-0600

otmar: we need test reports, hopefully positive ones. Also, do you want to update the patch in this issues as well?

By: otmar (otmar) 2007-01-11 09:13:49.000-0600


the patch in ASTERISK-7871 includes all the changes I originally proposed here. I don't see a point in posting the same diff-file to two bug-ids.

It might be helpful to close one of the two bug-ids to avoid misunderstandings.

Regarding test reports: I can provide one and publish a set of DNS test-cases.

But even without testing the new features: this patch removes some dead code which got obsoleted by the removal of app_enum.c and clarifies the ISN lookup code, thus even discounting new features, this is a step in the right direction.

By: Serge Vecher (serge-v) 2007-01-17 08:17:01.000-0600

as per note in 8089, further work on this report is being done in patches there.

By: Digium Subversion (svnbot) 2008-01-15 16:55:58.000-0600

Repository: asterisk
Revision: 10714

U   team/oej/test-this-branch/README.test-this-branch
U   team/oej/test-this-branch/doc/enum.txt
U   team/oej/test-this-branch/enum.c

r10714 | oej | 2008-01-15 16:55:57 -0600 (Tue, 15 Jan 2008) | 2 lines

Adding carrier ENUM support (patch ASTERISK-5378)