| Summary: | ASTERISK-01427: [patch] enum patch to get a caller name stored in TXT dns record | ||
| Reporter: | duane (duane) | Labels: | |
| Date Opened: | 2004-04-18 06:36:53 | Date Closed: | 2008-01-15 14:55:04.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) callername.patch | |
| Description: | Simple patch to pull a caller name stored in DNS TXT record... ****** ADDITIONAL INFORMATION ****** A friend and I setup e164.org to do enum lookups on POTS numbers and then thought wouldn't it be nice to store a name with the voip URL, so we hacked up a patch, he's sending in the disclaimer by fax on behalf of both of us working on e164.org | ||
| Comments: | By: duane (duane) 2004-04-18 08:38:51 Later version patch only does TXT DNS lookups if there is a valid NAPTR record in DNS, and added the option for people to enable TXT lookups in enum.conf, rather then being on by default... By: Brian West (bkw918) 2004-04-18 19:12:01 Is this part of the enum standard? By: Brian West (bkw918) 2004-04-18 19:18:07 I don't see where this is useful... we are calling the voip URL why would we need their callerid? We are sending OURS not theirs. bkw By: duane (duane) 2004-04-18 19:44:40 enum standard uses NAPTR, this uses TXT, and is off by default, this neither interferes with nor breaks anything as you can have any number of types for each record in DNS. The purpose is simple, people are listing themselves in DNS with their voip URL, we just extended it to include a way to pull their name with the VOIP url for informational purposes to use SetCIDName(). I should have stated it here that our C skills are pretty rusty and this may not have been the most elligant solution to pulling a TXT record given a CID, however it was the simpliest to interface with that we could think of... edited on: 04-18-04 18:38 By: Brian West (bkw918) 2004-04-18 20:03:01 But see you are calling the person listed in ENUM via NAPTR why would you need their callerid to call SetCIDName with? Wouldn't you be putting YOUR callerid in before calling the result via enum? bkw By: duane (duane) 2004-04-18 20:08:42 Just because you do an EnumLookup doesn't mean the next line has to be dial... Again possibly not the most elligant solution, but it does work... For testing purposes I have in my extensions.conf for incoming calls via pstn: exten => _.,1,NoOp(61${CALLERIDNUM:1}) exten => _.,2,EnumLookup(61${CALLERIDNUM:1}) exten => _.,3,NoOp(${ENUMTXT}) edited on: 04-18-04 19:02 By: duane (duane) 2004-04-19 20:41:30 Ok new patch seperating the calls for TXT records into a new app_* file, changed variable names etc to reflect this, it's now TXTCIDName instead of ENUMTXT... By: Brian West (bkw918) 2004-04-19 23:15:22 Ok I just had a really nice idea for this.... we could store RSA keys in DNS for communictions via iax2 or such... maybe we could store md5 hases ... maybe complete ready made dial strings... maybe our very own ENUM type setup using txt records for IAX (since IAX isn't really a global standard YET!) This is more than just TXTCIDName... I think the applications of this could be even wider.... By: duane (duane) 2004-04-20 00:14:20 RFC's already cover RSA/PKI data in DNS, so yes this is possible and already worked out for us from a DNS perspective: ftp://ftp.ietf.org/rfc/rfc2437.txt - pki keys in DNS ftp://ftp.ietf.org/rfc/rfc2535.txt - rsa keys in DNS We can match incoming caller IP and Caller ID to NAPTR records and handle the calls from that point of view, which leaves us with bug in tact and adding the other niceities as other patches :) By: Olle Johansson (oej) 2004-04-20 08:51:14 Moving this to experimental features as of now. It will not be considered for 1.0/1.1 and needs more testing and implementation. By: Olle Johansson (oej) 2004-04-20 08:52:31 There's a lot of privacy concerns here. There is a reason why no e-mail directory ever succeeded on the internet... By: duane (duane) 2004-04-20 09:01:18 The system is purely informational and purely voluntary, and as I stated before, turned off by default... I see a lot of businesses would find this useful for business to business, which is part of my reasons for coding it, not to mention others asking for a whitepages implementation in conjuction to the enum.164 system we've built... By: Olle Johansson (oej) 2004-04-20 09:10:26 If this takes off, it's a wonderful addition to Asterisk. However, it needs testing and we will not add extra functions to 1.0/1.1 at this points. It's also outside of standardization at this point, which means that it's an optional extra side order. It will be considered after 1.1, so hang on. By: duane (duane) 2004-04-24 20:13:47 New patch. this removes the need to mess with the enum.conf, the previous version which was integrated into the enumlookup function turned txt checking on/off by way of an extra parameter. Since the new code was seperated into it's own app this is no longer needed and is much more backward compatible as a result. Can someone please remove the older patches. Thanks. edited on: 04-24-04 19:10 By: heison (heison) 2004-05-05 17:15:07 older patches removed. By: Mark Spencer (markster) 2004-05-16 14:02:19 okay, added in this form, nicely done. By: Digium Subversion (svnbot) 2008-01-15 14:55:04.000-0600 Repository: asterisk Revision: 2986 U trunk/apps/Makefile A trunk/apps/app_txtcidname.c U trunk/enum.c U trunk/include/asterisk/enum.h ------------------------------------------------------------------------ r2986 | markster | 2008-01-15 14:55:03 -0600 (Tue, 15 Jan 2008) | 2 lines Add ability to look up callerid name by txt (bug ASTERISK-1427) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2986 | ||