Summary: | ASTERISK-00044: [patch] hide blocked caller IDs | ||
Reporter: | John Todd (jtodd) | Labels: | |
Date Opened: | 2003-08-04 13:13:51 | Date Closed: | 2004-09-25 02:46:18 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | The PRI specification says that if a call is received with the call-screen flag set, then the device should not send the caller ID (ANI) information to the remote terminal. However, Asterisk does not appear to honor this flag, and sends caller ID under all circumstances. This patch looks for what I believe to be the "block caller ID" flag (0x7f) and then inserts a null into the caller ID. This patch is a kludge. What would be better would be a flag in zapata.conf that told each PRI to honor or not honor the caller ID blocking flag. That is left as an exercise to people with more coding clue than I. Note that this patch is pretty much required for any US-based CLEC to run Asterisk, since sending caller ID information on block-requested calls is illegal in the US. I expect the same is true for Europe, but I can't speak for the legality there with any knowledge. ****** ADDITIONAL INFORMATION ****** --- q931.c~ Sat Jul 26 15:14:44 2003 +++ q931.c Mon Aug 4 17:49:08 2003 @@ -741,6 +741,7 @@ q931_get_number(cnum, sizeof(cnum), ie->data + 2, len - 4); pri_message("%c Calling Number (len=%2d) [ Ext: %d TON: %s (%d) NPI: %s (%d)\n", prefix, len, ie->data[0] >> 7, ton2str((ie->data[0] >> 4) & 0x07), (ie->data[0] >> 4) & 0x07, npi2str(ie->data[0] & 0x0f), ie->data[0] & 0x0f); + if ((ie->data[1] & 0x7f) == 35) cnum[0] = '\0'; pri_message("%c Presentation: %s (%d) '%s' ]\n", prefix, pri_pres2str(ie->data[1]), ie->data[1] & 0x7f, cnum); } | ||
Comments: | By: John Todd (jtodd) 2003-08-04 13:45:30 From: "Linus Surguy" <linus@magrathea-telecom.co.uk> To: <asterisk-dev@lists.digium.com> Subject: Re: [Asterisk-Dev] Block caller ID patch submitted Reply-To: asterisk-dev@lists.digium.com Date: Mon, 4 Aug 2003 19:23:02 +0100 Dear All, I was going to look at this issue as well. In the UK CLI data is not allowed to be passed to the destination user if either a) the caller has withheld presentation of the number or b) the caller does not have the facility to control presentation of the number. A switch can pass a withheld number to another if a) it is capable of preserving the restricted flag, b) it does so and c) is passing to another 'trusted' network operator. As such, I would recommend that the default setting should be that if on a PRI call to Asterisk the calling number presentation is restricted then it must not be passed out. Any configuration option that changes this should then be on a per trunk basis. Whether you should then return 'blank' or the text 'Withheld' or similar is a matter for discussion. Linus Magrathea By: John Todd (jtodd) 2003-08-05 13:30:44 As Martin noted: "Why don't you use the PRES_PROHIB_NETWORK_NUMBER instead of 35 (0x23) ?" That variable would probably work better; didn't notice it was #define'd above. By: John Todd (jtodd) 2003-08-06 12:50:15 See bug ASTERISK-48, which has a much better explanation of incoming/outgoing CLI/ANI number blocking. By: Mark Spencer (markster) 2003-09-13 15:05:19 This is more complex. The behavior should be as follows: If callerid is blocked: chan->ani is still the actual number (and name if available) chan->callerid is NULL (or name only) else chan->ani is actual number (and name if available) chan->callerid is the same as chan->ani endif futher, when *placing* a call, we need a "sendani" flag in zapata.conf. If a channel is trusted with sendani, then we send the value in chan->ani, otherwise we send the value of chan->callerid (if known). This patch can only be implemented when the entirity is done. If it is important to know BLOCKED vs. UNAVAILABLE then we will need an additional flag. By: Mark Spencer (markster) 2003-09-13 15:06:51 One more thing -- the BLOCKED would need to be sent along with the outbound call as well in the case of sendani=yes. BLOCKED could be detected when chan->ani is non-NULL and chan->callerid is NULL or has no number in it. By: x martinp (martinp) 2003-11-03 15:54:07.000-0600 This is fixed as it comes to PRI-PRI or PRI-SIP. |