Summary:	ASTERISK-02063: [Design & patch] app_privacy & confused users
Reporter:	Steve Murphy (murf)	Labels:
Date Opened:	2004-07-19 11:46:36	Date Closed:	2008-01-15 15:16:23.000-0600
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_privacy.patch ( 1) app_privacy.patch2 ( 2) privacy-prompt.gsm
Description:	I've gone thru my call records. 13% of all those with unlisted/unavailable numbers, input their number with a leading "1". This means the last digit of their input number is missing. I've added some simple code to detect this situation, and then tell them to re-enter the number, and leave out the "1" at the beginning, then, wipe out the CID, and try the privacy app again... but... there must be a better way. ****** ADDITIONAL INFORMATION ****** I have a few different ideas how to handle this. First, a different way to gather the numbers, where if a 1 is the first entered digit, you ignore it and continue collecting the remaining 10 digits. Otherwise, you could ask them to terminate the number with a #, and collect a max of maybe 15 or 16 numbers or something. Also, I find I know nothing about international CID. If I get a call from Ireland, will they supply CID? And will it always be exactly 10 digits in length? No one ever calls me from overseas, so I just plain don't know what you get from over there. And if I were in, say, Zimbabwe, and IF CID is available there, would the numbers all be 10 digits? Seems the city code stuff allows variable length numbers, each city having its own length...?
Comments:	By: Brian West (bkw918) 2004-07-19 18:22:19 I guess you're amazed that people can't listen and follow instructions?    app_privacy will accept the first 10 digits of the number(even if it starts with a 1) and pass the call on thru with what we received.  This isn't a bug or anything that we can fix.  You idiot proof it and someone will make a better idiot. Now we could make it a config option. :P edited on: 07-19-04 18:07 By: Steve Murphy (murf) 2004-07-20 09:52:20 bkw-- I can't blame you for your view on the subject. It is true. No matter how hard you try, there will a certain percentage of folks that "won't get it". But, my view is, communication is a two-way street, and the better you are at communicating, the fewer the confused in number. The BEST software confuses no-one. The worst software confuses everyone. I do think that we could do better than confusing 13% of our "customers". In the end, everyone will judge asterisk on how confusing it is to install, use, etc. The less the confusion, the better the software, the happier the "customers", the more successful the product, the easier to maintain. Right? If nobody else wants to fix this, I will. But I have a feeling that the current algorithm, as it stands, is also hurting via international standards, and the best solution is to fix it so it works as well in the US as it does in Ireland, Kigali, and Moscow. By: Mark Spencer (markster) 2004-07-20 10:10:25 If there is ever a progmatic way to avoid problems with the user, that's better than trying to fix the user. Our options as I see them are: 1) The "1+ kludge" 2) Requiring them to press "#" 3) Setting a longer number with a relatively brief digit timeout at the end. Thoughts? By: twisted (twisted) 2004-07-20 22:47:01 Simple solution - change the prompt to say please enter phone number area code first, without the leading 1. Another thought would be to check the number entered, get the length, if it's 11 digits, strip the first digit, otherwise, the caller may be out of country, and we  want the other digits. By: Brian West (bkw918) 2004-07-20 22:50:39 But will they listen?  It now says enter your 10 digit number... wonder... hrm. By: Steve Murphy (murf) 2004-07-21 01:09:00 My input: Martin List-Petersen was kind enough to answer my query about CID internationally,  and here seems a good place to document his words: -------------- CID is esentially part of any digital subscriber line anywhere in the world, so everybody uses it. On PSTN there are 3 (maybe more) standards: the way it's done in the US, UK and Sweden (which also is used in Denmark and the Netherlands). Asia might use something different again, or not. International calls CID look depends on the Telco you are connected to. If you are on PSTN, usually they would add the "00" or in the U.S. the "011" in front of the international dialcode and then let the number follow. On digital subscriber lines (at least the DSS1 specs), you will get the number without prefix and the information, what dialplan it belongs to (international, national, local, unscreened, etc.) The number itself depends on the dialplan used in that country (Ireland: variable, but national prefix + subscriber no. allways 6 digits, not counted the "0" in front, Denmark: fixed 8 digits, Norway: fixed 8 digits, Sweden: variable, Germany: variable) So all in all, your CID can have any length, depending on the countries dialplan, where somebody would be calling you from. Kind regards, Martin List-Petersen ---------------------------- Because of this, I'd opt for "all of the above": 1. Set maybe a 2 to 4 second timeout, which amount of silence will end the string of input numbers. 2. Using the "#" will also terminate the sequence. 3. we can opt to either strip a leading "1" from the number, or leave it in, and pass it back via the CID in asterisk. The leading "1" isn't all that useless-- it does tell you the remainder of the number was definitely in the US/Canada/Carib/etc dial plan. For those who desire 10 digit purity, they can strip the leading 1 if it is there, via a simple statement in the extensions.conf context.  Since the number is hand-entered, it may or may not have an '011' in the front if it from outside the country; and I don't think it appropriate to give a 10 minute discussion on how to enter the number as a prompt for the caller. If you are really keen on getting the most from the CID, you might note that 212 or 213 are both valid as a North American area code, and  as country codes. Only the length of the number might supply a clue as to origin of the call. 4. The prompt should be changed to ask for the caller's number, and to press "#" when finished. If they forget the "#", they'll have to suffer a few extra seconds of silence. I've been hearing that international rates are so cheap, that telemarketers are calling from England, among other places, to the US, and complaints about them not honoring the No-Call list fall on deaf ears. Whether these folks would bother to enter any CID when the privacy app kicks in, and what they might enter will truly be a study of human behavior. And, then, if you had an unlisted number, and called a friend in Norway, say, and got the privacy app on his system there, what would you enter? Would it start with a 1? Given that there, the phone numbers are 8 digits, he might have modified app_privacy.c to cut the length to 8 from 10, and your CID would be cut short... By: Olle Johansson (oej) 2004-08-08 16:22:41 Closing report, it will stay in archive. If there's any interest in continuing the discussion, please re-open. By: Steve Murphy (murf) 2004-08-11 11:05:01 Here's a patch for the app_privacy.c that hopefully fits the bill. I added another config item-- minlength. It should be 10 by default. It will now accept up to 30 digits. Silence terminates the input number. If the number is less than "minlength" digits, the input is invalid, as before. The sound files need to be edited. If I could get audacity to work with gsm files, I'd have edited out the 10-digit stuff, and had them ready to go by now. By: twisted (twisted) 2004-08-24 13:39:40 Status?   Audacity can edit wav files just fine... use sox to convert to wav, edit, save, and convert back to gsm.  Seems to work pretty well for me ;) By: Steve Murphy (murf) 2004-08-26 11:12:01 Just added a new version of privacy-prompt.gsm to go along with the patch. I chopped out the "10 digit" words, so now it just says "Please enter your phone number, starting with the area code". Thanks for the idea, twisted! Just wasn't thinking. sox'd it to wav file, edited that with audacity, and then sox'd it back. Sometimes I just have to admit to myself, that if I got any dumber, I'd have to be watered twice a week! By: Brian West (bkw918) 2004-08-26 22:03:30 While were at it... why not make it say "starting with your city code, country code or areacode"  and really confuse them :P Dont know about you but on Dialup Networking on windows I can't count the number of people that put their zipcode in the area/citycode field.... thus dialing 1+ZIPCODE+Phone Number...... bkw By: Steve Murphy (murf) 2004-08-27 00:14:42 That's the thing. They can put ANYTHING they want in. As it now stands, as long as they put in 10 digits they are OK with the privacy app. I've written a smallish program that will try to make sense of what they put in. There are over 300 valid area codes. The number may or may not be preceded by a one, depending on the whim of the caller. The number may or not have a Zip code instead of an area code, for instance. The number could even be an international 011- type number with an European city code instead of a NA area code. It would be pretty difficult to accurately diagnose whether the input is "valid". The only thing I can check for right now here is that the last 7/10 digits aren't MY phone number. It really ticks me off if they enter MY phone number! My guess is that 88% of the time, you'll get what you expect to be entered. And if what they entered doesn't make sense, you can write extra extensions file code to explain what you want and let them try again... or just hang up on them. Or whatever. Making the privacy "intelligent", and try to "validate" the number given would be next to impossible. By: Danny Froberg (dfroberg) 2004-10-01 11:55:59 Hi, Dont know if this could be usefull in the "Analyzing Numbers" department but a look at http://www.numberingplans.com/index.php?goto=analysis and related pages might give a hint. By: twisted (twisted) 2004-10-27 16:05:07 Any update on this?  Can we agree on a way to move forward? By: Steve Murphy (murf) 2004-10-27 18:54:59 I've uploaded a new patch for app_privacy, as the current version has some changes for the cid in the channel struct. The main diffs are in the doc for the app, and using functions streamfile/waitstream/readstring instead of the combined func ast_app_getdata, so both silence and a # will end the number. The new config var, minlength, is added. Some logic had be modified, because readstring returns diff. values than getdata. As to what to do with the number the caller gives, well, that's a matter for AGI/extensions/etc. Not in app_privacy.c. Everyone agree? By: Steve Murphy (murf) 2004-10-27 18:56:48 Oh, and by the way, the 'diffs' I mention in the last note are not new-- I made no substantive changes since the original patch. I'm just summarizing the patch, maybe redundantly. By: twisted (twisted) 2004-11-14 21:26:21.000-0600 Requesting update once again. --Housekeeping By: Steve Murphy (murf) 2004-11-23 08:36:03.000-0600 The patch is still working fine here. Waiting for "housekeeping" to either sweep it into the tree, or sweep it into the bit-bucket, whichever they prefer. By: Mark Spencer (markster) 2004-12-12 09:46:48.000-0600 Added to CVS, thanks! By: Russell Bryant (russell) 2004-12-19 08:24:11.000-0600 murf:  Can you email me to verify that you have a disclaimer on file with Digium? Thanks! russelb@clemson.edu By: Russell Bryant (russell) 2004-12-24 14:27:30.000-0600 not included in 1.0 By: Digium Subversion (svnbot) 2008-01-15 15:16:23.000-0600 Repository: asterisk Revision: 4433 U   trunk/apps/app_privacy.c U   trunk/sounds/privacy-prompt.gsm U   trunk/sounds.txt ------------------------------------------------------------------------ r4433 | markster | 2008-01-15 15:16:23 -0600 (Tue, 15 Jan 2008) | 2 lines Merge privacy enhancements (bug ASTERISK-2063) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4433