Summary:ASTERISK-00044: [patch] hide blocked caller IDs
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-08-04 13:13:51Date Closed:2004-09-25 02:46:18
Versions:Frequency of
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.


--- 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.


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)
 chan->ani is actual number (and name if available)
 chan->callerid is the same as chan->ani

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.