[Asterisk-Dev] caller display in a telco environment.

Linus Surguy linus at magrathea-telecom.co.uk
Wed Aug 6 03:41:01 MST 2003


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