[Asterisk-Dev] Re: caller display in a telco environment.
John Todd
jtodd at loligo.com
Wed Aug 6 10:42:34 MST 2003
Thanks for the excellent explanation. I've added your notes to:
http://bugs.digium.com/bug_view_page.php?bug_id=0000052
Hopefully this will allow a better-built (and legal) system for
handling PRI calls. Still missing is the method by which an
individual call would tag an outbound call request as "private"
(CLI/ANI blocked) as an exception case from within the dialplan. I
would suggest a variable gets set before the call is created.
JT
>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 at loligo.com>
>To: <asterisk-users at lists.digium.com>
>Cc: <linus at magrathea-telecom.co.uk>; <lpallara at 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 at digium.com>
>> >To: <asterisk-users at 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 at lists.digium.com
>> >> > http://lists.digium.com/mailman/listinfo/asterisk-users
>> >> >
>> >>
>> >> _______________________________________________
>> >> Asterisk-Users mailing list
>> >> Asterisk-Users at lists.digium.com
>> >> http://lists.digium.com/mailman/listinfo/asterisk-users
>> >>
>> >>
>> >
>> >_______________________________________________
>> >Asterisk-Users mailing list
>> >Asterisk-Users at lists.digium.com
>> >http://lists.digium.com/mailman/listinfo/asterisk-users
>>
More information about the asterisk-dev
mailing list