Summary:	ASTERISK-05518: [patch][post 1.4] Add NAPTR string parsing to ENUMLOOKUP function call
Reporter:	John Todd (jtodd)	Labels:
Date Opened:	2005-11-08 22:57:29.000-0600	Date Closed:	2007-01-17 08:17:37.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Functions/func_enum
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) enum.c-diff.txt ( 1) func_enum.c-diff.txt ( 2) README.enum-patch.txt
Description:	So, right now we have the function ENUMLOOKUP, which turns numeric strings into "."-separated DNS lookups.  Very nice, marginally useful, etc. I was thinking about why this is restricted to numerics.  Why can't ENUMLOOKUP do NAPTR lookups on "normal" DNS names in a given zone?  Reading the RFC, seems that NAPTRs were designed to do this.  It would seem a very small change to allow non-numeric strings to pass through unmodified, or perhaps another option to allow this to happen.  This would allow for DNS-based username-to-URI translations.  In fact, it seems that the current code is going out of its way to not allow this to happen, since currently it looks like the leftmost portion of the DNS query is not being sent if it is not a number. In the theoretical world, "${ENUMLOOKUP(jtodd,,,phone.loligo.com)}" should equal "2203@loligo.com" if the following is in DNS: jtodd.phone.loligo.com. 3600 IN NAPTR 30 100 "u" "sip+E2U" "!^\\jtodd$!sip:2203@loligo.com!" . Why would I want this?  Easy.  Let's say I have a large number of users.  In order to provide for user-to-phone mappings in Asterisk for SIP URI dialing, I would create some exhaustive email-to-extension mapping or variable setting like this: [from-internet] exten => jtodd,1,Dial(SIP/2203) exten => bbanzai,1,Dial(SIP/2204) [etc., etc.] If I had all this data in DNS, I could just do an ENUMLOOKUP on the username, and I'd never have to modify my Asterisk configs again every time I wanted to add a new user, like this: ; this assumes no all-numeric usernames or usernames starting with numbers [from-internet] exten => _[a-z].,1,Dial(SIP/${ENUMLOOKUP(${EXTEN},sip,,phone.loligo.com)}) This seems a bit easier than creating some type of external SQL database and integrating it into my dialplan.  Of course, I could just use the LDAPget routines (http://www.mezzo.net/asterisk/app_ldap.html) but that would then imply setting up an LDAP server.  I'm lazy; DNS is all I need, and I'm running it already, and it seems that Asterisk should be able to do more with the NAPTR lookup routines it has. $25 to anyone who can "repair" the functionality in ENUMLOOKUP.  It would make sense if this was an option flag, so that numbers could be specified as strings instead of as ENUM-style domain sequences  (i.e.: "s" for string). so, the final syntax would be something like this: exten => _[a-z].,1,Dial(SIP/${ENUMLOOKUP(${EXTEN},sip,s,phone.loligo.com)}) and then my system would dial 2203@loligo.com (with associated SRV lookups, of course.) So, I paid someone to write it.  :-)  Here it is.  For testing, try this on for size (it "dials" www.loligo.com) exten => 1234,1,Dial(SIP/${ENUMLOOKUP(www,,s,loligo.com)})
Comments:	By: Kevin P. Fleming (kpfleming) 2005-11-15 20:49:23.000-0600 This looks like a fine addition, but it definitely qualifies as a new feature :-) By: John Todd (jtodd) 2005-11-20 22:30:09.000-0600 Something wrong with my brain a few days ago.  I've attached the REAL func_enum.c patch, I think. By: Olle Johansson (oej) 2005-11-21 08:22:18.000-0600 I don't think we should relate this to ENUM and overload ENUM-lookup. We have TXTCIDNAME, ENUMLOOKUP already, both are DNS-related. Hmmm... By: John Todd (jtodd) 2005-11-22 17:56:36.000-0600 I don't see anyone volunteering to take this all apart and write a full DNS library in application-space, so I'd propose applying this patch until then.  :-) By: twisted (twisted) 2005-11-23 23:32:52.000-0600 I have to agree.  This looks nice ;)   oej:  perhaps there should be a dns resource that will deal with this stuff as needed (and called by the funcs).  Then, perhaps, we can also offload some of ther useful features into it.  For now though, this would be a great addition to the enum function, as it does operate in a very similar fashion. By: Matt O'Gorman (mogorman) 2006-01-08 11:13:17.000-0600 is all the code in enum.c or is there something missing because both func_enum.c-diff.txt and readme look the same. I agree with twisted and you that this should go in now as is.  thanks By: Olle Johansson (oej) 2006-01-09 00:55:17.000-0600 This really has nothing to do with ENUM and needs to be separated, it will confuse things. ENUM is strictly E164 lookups and this is much more generic. enumlookup should be for enum alone. let's implement a DNSLOOKUP function that looks up NAPTR, SRV and other records. By: Olle Johansson (oej) 2006-03-04 05:04:32.000-0600 Any feedback? By: John Todd (jtodd) 2006-03-04 11:22:25.000-0600 I think the feedback is until someone steps up with a totally re-written patch that splits functionality, that we should put this in as it stands.  :-) By: Olle Johansson (oej) 2006-03-04 15:13:21.000-0600 I'll try to find someone then... Somewhere, under a hidden stone... By: Olle Johansson (oej) 2006-03-04 15:14:03.000-0600 Because if we put it in, we have to stand by it for a long time to keep backwards compatibility and all that, you know. Better to make it right from start :-) By: John Todd (jtodd) 2006-03-04 17:35:42.000-0600 I agree with you.  However, several (English) sayings come to mind: "Rough consensus and running code." "There is more than one way to do it." "A bird in hand is worth two in the bush." As a project, Asterisk has not shied away from new features which replace the old. Minimally, the only thing I could suggest towards enacting something that would satisfy your caution would be that ENUMLOOKUP becomes NAPTRLOOKUP to be more reflective of the new ways of functioning in this proposal.  This is not a major functionality change. By: Serge Vecher (serge-v) 2006-05-25 21:57:23 jtodd: did you have a chance to work further on this? By: Serge Vecher (serge-v) 2006-06-08 12:38:36 otmar: since you are working on the other open ENUM bug, you may want to take a look at this one also. Thanks. By: otmar (otmar) 2006-10-04 10:23:28 I haven't looked at the code here, but this scheme fits in very nicely with what I've done to the ENUM code recently. I've added support for this idea to my latest patch. See http://bugs.digium.com/view.php?id=8089 By: jmls (jmls) 2006-11-03 03:39:31.000-0600 ping. housekeeping. Can we move this forwards ? By: Serge Vecher (serge-v) 2007-01-17 08:17:36.000-0600 as per note in 8089, further work on this report is being done in patches there.