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