ASTERISK-00048: [patch] Set caller ID blocking from dialplan

[Home]

Summary: ASTERISK-00048: [patch] Set caller ID blocking from dialplan

Reporter: John Todd (jtodd) Labels:

Date Opened: 2003-08-05 13:36:09 Date Closed: 2011-06-07 14:05:15

Priority: Major Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: The ability to set the PRES_PROHIB_USER_NUMBER_NOT_SCREENED (or whatever the value should be...) during the creation of an outbound call is important for Zap channels so that caller ID can be transmitted to the upstream switch but the switch should be instructed to not display the caller ID to the remote terminal. This is part of the q931 specification.

****** ADDITIONAL INFORMATION ******

Here's a clip of code that someone did that doesn't seem complete, since there is still no indication as to how this gets set from within a dialplan:

From: "Lorenzo Pallara" <lpallara@cineca.it>
To: <asterisk-users@lists.digium.com>
Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still passing ANI?
Reply-To: asterisk-users@lists.digium.com
Date: Tue, 5 Aug 2003 10:52:12 +0200

We did something like this in chan_zap at pri_call() time:

case SIG_PRI:

[...]

if (ast->callerid) {
strncpy(callerid, ast->callerid, sizeof(callerid)-1);
ast_callerid_parse(callerid, &n, &l);
if (l) {
ast_shrink_phone_number(l);
if (!ast_isphonenumber(l))
l = NULL;
}
}

[...]

if (l) {
pres = ast->hidecallerid ?
PRES_PROHIB_USER_NUMBER_NOT_SCREENED :
PRES_ALLOWED_USER
} else
pres = PRES_NUMBER_NOT_AVAILABLE;

if (pri_call(p->pri->pri, p->call,
p->digital ? PRI_TRANS_CAP_DIGITAL : PRI_TRANS_CAP_SPEEC
p->prioffset, p->pri->nodetype == PRI_NETWORK ? 0 : 1, 1, l,
p->pri->dialplan - 1,
c + p->stripmsd, p->pri->dialplan - 1,
((p->law == ZT_LAW_ALAW) ?PRI_LAYER_1_ALAW : PRI_LAYER_1_ULAW)))
{

[...]

where hidecallerid is a new field we added in ast_channel structure and it's
set by our apps...
As far as we can understand this should be more compliant to the q931 specs.
(and it works for us in Italy ;-)

my 2 cents,
Lorenzo

----- Original Message -----
From: "Martin Pycko" <martinp@digium.com>
To: <asterisk-users@lists.digium.com>
Sent: Monday, August 04, 2003 8:34 PM
Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still passing
ANI?

> l is set a couple of lines above. Basically l carries the nubmer so if
> there is no callerid in 'l' then we send this other flag 'callerid not
> available'.
>
> You need to choose one of these flags:
> /* Presentation */
> #define PRES_ALLOWED_USER_NUMBER_NOT_SCREENED 0x00
> #define PRES_ALLOWED_USER_NUMBER_PASSED_SCREEN 0x01
> #define PRES_ALLOWED_USER_NUMBER_FAILED_SCREEN 0x02
> #define PRES_ALLOWED_NETWORK_NUMBER 0x03
> #define PRES_PROHIB_USER_NUMBER_NOT_SCREENED 0x20
> #define PRES_PROHIB_USER_NUMBER_PASSED_SCREEN 0x21
> #define PRES_PROHIB_USER_NUMBER_FAILED_SCREEN 0x22
> #define PRES_PROHIB_NETWORK_NUMBER 0x23
> #define PRES_NUMBER_NOT_AVAILABLE 0x43
>
> I think it might be PROHIB....PASSED_SCREEN but not sure. Check q931
> specs.
>
> Martin
>
>
> On Mon, 4 Aug 2003, John Todd wrote:
>
> >
> > I have a question regarding the flags for hiding caller ID presentation:
> >
> > My customer has a requirement that they are able to specify if
> > outbound calls (on a T100P) will have the caller ID displayed or not.
> > This could be easily solved, of course, by not setting a caller ID
> > when creating the outbound call. However, the PRI to which this
> > T100P is connected _must_ see a valid caller ID, and the caller ID is
> > used for billing purposes.
> >
> > I know that there is the ability to hide caller ID within the Zaptel
> > libraries, using the presentation flags. If set correctly, the
> > expected behavior would be that the ANI would be sent to the switch,
> > but with a flag that would tell the remote switch to suppress the
> > caller ID from being transmitted to the end user.
> >
> > How does one activate that presentation switch from within a dialplan?
> >
> > Searching the archives gives me some hints, but no answers.
> > Searching the code, I see in channels/chan_zap.c around line 1399
> > that the PRES_ALLOWED_USER_NUMBER_PASSED_SCREEN and
> > PRES_NUMBER_NOT_AVAILABLE are referenced, but I'm not clear on where
> > "l" is set, or even if that is a trigger. Can someone give me a hand
> > on syntax on this?
> >
> > JT
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users@lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
>

_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users

Comments: By: John Todd (jtodd) 2003-08-05 13:36:43

More data:

From: "Linus Surguy" <linus@magrathea-telecom.co.uk>
To: <asterisk-users@lists.digium.com>, <asterisk-dev@lists.digium.com>
Subject: [Asterisk-Dev] Re: [Asterisk-Users] Syntax for hiding caller ID but still passing ANI?
Reply-To: asterisk-dev@lists.digium.com
Date: Tue, 5 Aug 2003 08:13:48 +0100

(as a follow up to my own post)

> > It seems that there are two options that block the presentation: 0x23
and
> 0x21
>
> No no! Protocol wise, they are different flags in each nibble. If the high
> nibble is not zero then the number is not for general use. Any number
> presentation block in PRI->SIP conversion should only pass the CLI if the
> high nibble is zero.

Cut and paste from the ITU Spec Q931

Presentation indicator (octet 3a)

Bits
7 6 Meaning

0 0 Presentation allowed
0 1 Presentation restricted
1 0 Number not available due to interworking
1 1 Reserved
NOTE 1 - The meaning and the use of this field is defined in 3/Q.951 and
4/Q.951.

Screening indicator (octet 3a)

Bits
2 1 Meaning

0 0 User-provided, not screened
0 1 User-provided, verified and passed
1 0 User-provided, verified and failed
1 1 Network provided

NOTE 2 - The meaning and the use of this field is defined in 3/Q.951 and
4/Q.951.

Linus

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
By: John Todd (jtodd) 2003-08-05 13:43:56

More stuff if someone is feeling energetic. Perhaps there is some way to set this on a global manner, so that translations between SIP->PRI channels is seamless. Of course, a manual intervention of variable setting would be required, as well, if this were to be useful.

To: asterisk-users@lists.digium.com
From: John Todd <jtodd@loligo.com>
Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still
passing ANI?
Reply-To: asterisk-users@lists.digium.com
Date: Mon, 4 Aug 2003 15:56:53 -0700

OK, I can understand that, and I suppose that your answer perhaps indicates that there is currently no method within Asterisk that is easily accessible that permits such tagging of outbound PRI calls.

Putting such a patch or feature together is beyond my ability. Ultimately, I'd like to set this flag from within the dialplan somehow such that the call is flagged with that option upon creation. I suppose I'll put this on my little pile of things that would be nice to have, but I can't afford. :)

I did a little digging, and found that there is even an RFC Draft for SIP extensions for privacy that translates to PRI signalling, which would be nice to have, though certainly all I'm shooting for is a flag to set in the dialplan (through a SetVar command maybe?)

Anyway, if anyone gets ambitious about handling it, here's the well-written Cisco documentation on how they implement a version of it:

SIP Extensions for Caller Identity and Privacy
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftsipext.htm#1027188

It seems that there are two options that block the presentation: 0x23 and 0x21

JT
By: John Todd (jtodd) 2003-08-06 12:49:23

More discussions, with better explanation as to how the CLI/ANI blocking features are understood in the Q.931 protocol.

From: "Linus Surguy" <linus@magrathea-telecom.co.uk>
To: <asterisk-users@lists.digium.com>, "John Todd" <jtodd@loligo.com>
Cc: <lpallara@cineca.it>, <asterisk-dev@lists.digium.com>
Subject: caller display in a telco environment.
Date: Wed, 6 Aug 2003 11:41:01 +0100

Hi John,

In response to your question, and a couple of other items seen recently,
I've produced this, which is my view on the Q931/PRI caller display issues.

(Due to different terminology I'm using the UK abreviation CLI, caller line
identity in the following text, but it could also be termed caller display
or ANI or 'A' Number)

There have been a number of threads recently regarding CLI both entering *
from a PRI, or being delivered from * to a PRI and in most cases this is
handled 'incorrectly' if the equipment is to be used in a telco environment.
I'm not currently that famililar with the * code, but this should help those
that are make the correct choices when making patches.

Firstly, some definitions. Q931 specifies two seperate flags, which the
'zap' libraries incorrectly bundle into the one set of 'presentation'
#defines.

The first is the presentation indicator, which has three primary values:
0 which indicates that the CLI if present is freely available for display
purposes,
1 which indicates that the user/users system has made a decision not to make
the number available for display, or
2 which indicates that the number cannot be used for display, but this is
not because of user choice action. (although the title is 'number not
available due to interworking' this doesnt mean there is not a number)
(These are in bits 7 & 6 and so take the values in the field of
0x00,0x20,0x40,0x60)

The second is the screening indicator. These values are:

0 - The user equipment has provided the number and no network equipement has
attempted to verify the number. (In all these definitions, network equipment
refers to authoritive switching systems that are part of the PSTN and can be
trusted to provide genuine information).
1 - The user equipment has provided the number and network equipment has
validated it.
2 - The user equipment has provided the number and network equipment has
rejected it.
3 - Number has been provided by authoritive network equipment.

Now, dealing first with calls arriving from a PRI. As a telco, connections
are generally classified as trusted or not trusted. Connections to a user
are always not trusted, connections using a protocol that does not support
withholding number display are not trusted and international connections are
not trusted. As far as Asterisk is concerned sensible defaults would be to
count PRI as trusted and all none PRI (SIP, IAX etc) as none trusted, but
this should be a per trunk/user configuration option (trustwithcli=yes|no?).

Thus if Asterisk is delivering a call that arrives on a PRI it should only
pass CLI if the presentation indicator is zero unless the trunk is 'trusted'
in which case the CLI can be passed in all cases, with whatever flags the
outgoing protocol allows to closely mirror the PRI flags - especially the
presentation indicator.

Secondly, dealing with calls being delivered out from Asterisk on a PRI, to
be standards compliant, (unless the call also arrived on a PRI), all calls
should send the CLI provided but marked 'number not available due to
interworking', and 'user provided not screened' - a byte value of 0x40. A
second per user/trunk configuration item should be provided
(clivalid=yes|no?) which then overrides this behaviour and then allows the
number to be delivered to the PRI with the flags set as presentation
allowed, user provided not verified, a byte value of 0x00.

Whilst the above doesnt show any code, hopefully it is enough to help!

Linus
Magrathea

----- Original Message -----
From: "John Todd" <jtodd@loligo.com>
To: <asterisk-users@lists.digium.com>
Cc: <linus@magrathea-telecom.co.uk>; <lpallara@cineca.it>
Sent: Tuesday, August 05, 2003 7:25 PM
Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still passing
ANI?

>
> Lorenzo -
> I've submitted a feature request with this patch
> (http://bugs.digium.com/bug_view_page.php?bug_id=0000052). Your
> patch isn't completely descriptive, since I still don't know how you
> set the hidecallerid value from within a dialplan. Can you explain a
> bit more, please? Have you submitted a disclaimer to Digium so this
> patch might be added if it's seen as a useful addition?
>
> Linus -
> Thanks for the specifications. Did you have a patch or comments on
> how this might be implemented in the code?
>
> JT
>
>
> >We did something like this in chan_zap at pri_call() time:
> >
> >case SIG_PRI:
> >
> >[...]
> >
> >if (ast->callerid) {
> > strncpy(callerid, ast->callerid, sizeof(callerid)-1);
> > ast_callerid_parse(callerid, &n, &l);
> > if (l) {
> > ast_shrink_phone_number(l);
> > if (!ast_isphonenumber(l))
> > l = NULL;
> > }
> >}
> >
> >[...]
> >
> >if (l) {
> > pres = ast->hidecallerid ?
> >PRES_PROHIB_USER_NUMBER_NOT_SCREENED :
> >PRES_ALLOWED_USER
> >} else
> > pres = PRES_NUMBER_NOT_AVAILABLE;
> >
> >if (pri_call(p->pri->pri, p->call,
> > p->digital ? PRI_TRANS_CAP_DIGITAL : PRI_TRANS_CAP_SPEEC
> > p->prioffset, p->pri->nodetype == PRI_NETWORK ? 0 : 1, 1, l,
> > p->pri->dialplan - 1,
> > c + p->stripmsd, p->pri->dialplan - 1,
> > ((p->law == ZT_LAW_ALAW) ?PRI_LAYER_1_ALAW : PRI_LAYER_1_ULAW)))
> >{
> >
> >[...]
> >
> >where hidecallerid is a new field we added in ast_channel structure and
it's
> >set by our apps...
> >As far as we can understand this should be more compliant to the q931
specs.
> >(and it works for us in Italy ;-)
> >
> >my 2 cents,
> > Lorenzo
> >
> >
> >----- Original Message -----
> >From: "Martin Pycko" <martinp@digium.com>
> >To: <asterisk-users@lists.digium.com>
> >Sent: Monday, August 04, 2003 8:34 PM
> >Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still
passing
> >ANI?
> >
> >
> >> l is set a couple of lines above. Basically l carries the nubmer so if
> >> there is no callerid in 'l' then we send this other flag 'callerid not
> >> available'.
> >>
> >> You need to choose one of these flags:
> >> /* Presentation */
> >> #define PRES_ALLOWED_USER_NUMBER_NOT_SCREENED 0x00
> >> #define PRES_ALLOWED_USER_NUMBER_PASSED_SCREEN 0x01
> >> #define PRES_ALLOWED_USER_NUMBER_FAILED_SCREEN 0x02
> >> #define PRES_ALLOWED_NETWORK_NUMBER 0x03
> >> #define PRES_PROHIB_USER_NUMBER_NOT_SCREENED 0x20
> >> #define PRES_PROHIB_USER_NUMBER_PASSED_SCREEN 0x21
> >> #define PRES_PROHIB_USER_NUMBER_FAILED_SCREEN 0x22
> >> #define PRES_PROHIB_NETWORK_NUMBER 0x23
> >> #define PRES_NUMBER_NOT_AVAILABLE 0x43
> >>
> >> I think it might be PROHIB....PASSED_SCREEN but not sure. Check q931
> >> specs.
> >>
> >> Martin
> >>
> >>
> >> On Mon, 4 Aug 2003, John Todd wrote:
> >>
> >> >
> >> > I have a question regarding the flags for hiding caller ID
presentation:
> >> >
> >> > My customer has a requirement that they are able to specify if
> >> > outbound calls (on a T100P) will have the caller ID displayed or
not.
> >> > This could be easily solved, of course, by not setting a caller ID
> >> > when creating the outbound call. However, the PRI to which this
> >> > T100P is connected _must_ see a valid caller ID, and the caller ID
is
> >> > used for billing purposes.
> >> >
> >> > I know that there is the ability to hide caller ID within the Zaptel
> >> > libraries, using the presentation flags. If set correctly, the
> > > > expected behavior would be that the ANI would be sent to the
switch,
> > > > but with a flag that would tell the remote switch to suppress the
> > > > caller ID from being transmitted to the end user.
> >> >
> >> > How does one activate that presentation switch from within a
dialplan?
> >> >
> >> > Searching the archives gives me some hints, but no answers.
> >> > Searching the code, I see in channels/chan_zap.c around line 1399
> >> > that the PRES_ALLOWED_USER_NUMBER_PASSED_SCREEN and
> >> > PRES_NUMBER_NOT_AVAILABLE are referenced, but I'm not clear on where
> >> > "l" is set, or even if that is a trigger. Can someone give me a
hand
> > > > on syntax on this?
> >> >
> >> > JT
> >> > _______________________________________________
> >> > Asterisk-Users mailing list
> >> > Asterisk-Users@lists.digium.com
> >> > http://lists.digium.com/mailman/listinfo/asterisk-users
> >> >
> >>
> >> _______________________________________________
> >> Asterisk-Users mailing list
> >> Asterisk-Users@lists.digium.com
> >> http://lists.digium.com/mailman/listinfo/asterisk-users
> >>
> >>
> >
> >_______________________________________________
> >Asterisk-Users mailing list
> >Asterisk-Users@lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-users
>
By: John Todd (jtodd) 2003-09-11 13:59:28

This is probably solved more cleanly by http://bugs.digium.com/bug_view_page.php?bug_id=0000244 - unless someone has particular comments on how bug 244 is not a better or more full implementation of these features, I will close this request.