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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >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 > >> > [EMAIL PROTECTED] > >> > http://lists.digium.com/mailman/listinfo/asterisk-users > >> > > >> > >> _______________________________________________ > >> Asterisk-Users mailing list > >> [EMAIL PROTECTED] > >> http://lists.digium.com/mailman/listinfo/asterisk-users > >> > >> > > > >_______________________________________________ > >Asterisk-Users mailing list > >[EMAIL PROTECTED] > >http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
