Summary:	ASTERISK-06021: [patch] Set presentation to allowed whenever we set a callerid component
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2006-01-09 11:14:25.000-0600	Date Closed:	2006-01-10 18:05:49.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Functions/func_callerid
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20060109__reset_pres.diff.txt
Description:	We have a number of people who complain about a bug whenever they receive a call with caller presentation set to restricted, but after they set callerid, they still don't see a callerid (which confuses them).  My thinking is that if a callerid is set, they really don't want the presentation set to restricted, so we should automatically unrestrict it. The side effect of this change is that if anybody is depending upon the presentation to stay the same, they will have to reset restricted mode after changing the callerid.  I doubt this is the case, but a modification to UPGRADE.txt will document this change, just in case it is important to anybody.
Comments:	By: twisted (twisted) 2006-01-09 11:57:19.000-0600 while I see what you're doing there, I do not agree with this.  Just because the user gets confused doesn't mean we should change operational behavior of asterisk.   If the call comes in with a restricted flag, we shouldn't change it unless the user explicitly wants to change it.  that's what setcallingpres is for. By: twisted (twisted) 2006-01-09 11:59:40.000-0600 basically what I'm saying is don't punish the whole group just for a few confused people who don't know what they're doing. By: Tilghman Lesher (tilghman) 2006-01-09 12:19:16.000-0600 What I'm wondering is what purpose there would be in keeping it restricted after you set a callerid.  This isn't expected behavior, which is why I think it confuses so many people. By: twisted (twisted) 2006-01-09 12:30:14.000-0600 Purpose for CDR recording, etc.   Trust me, there are some sitautions where setting callerid/ANI but keeping calling presentation set to restricted is necessary - especially if you're talking to other providers.   The expected behavior is that "oh, i changed the callerid, it should show up", and that's true, assuming that the presentation bit is set to allow it to show up.  This is why it was such a big deal, for example, in sip to get RPID working both inbound and outbound.  Thinking logically about it can make sense.  LEC's and the like need to have records of all calls, wether their restricted bit is set or not; who they came from, and where they were going, etc.  If the calling party wants to restrict their callerid information, then by all means, we need to reflect that and preserve it even if we change their callerid data.  If i remember correctly, asterisk logs the callerid data into the CDR regardless of the presentation bit anyway.  (i might be wrong here, i'm just trying to pull this stuff out of memory). I still feel that we are doing the right thing in the way we operate today, and it should not change.  I do think it would be okay to make a note somewhere in the readme's that in order for any changes to the callerid/ani to show up on the callee's device(s), that the presentation bit must be set to allow.   What might make more sense also is to have the user look at the variable ${CALLINGPRES} to determine the presentation settings before just assuming it will show up if they change it.  It's a very simple thing to test the presentation bit before changing callerid, and if it's not allowed and we want it to be, then we set it allowed, and THEN change the callerid. By: Matthew Fredrickson (mattf) 2006-01-10 17:11:06.000-0600 Yeah, I'm not sure if this is "right".  Number presentation should be the same on a channel explicitly changed.  I'm not sure what would be a better solution to educate users, but generally speaking, making this sort of assumption just feels like it's the wrong answer to the problem.