caller ID and implementer's guide

Pete Cordell pete.cordell at BTINTERNET.COM
Thu May 20 06:21:21 EDT 1999


Paul,

Here is an attempt to generalise your paragraph to allow for multiple
gatekeepers and border elements etc.  Hardly Shakespeare, but hopefully it
will do.

"The octet-3 extension bit of calling party number IE in SETUP may be set to
0
or 1, The behavior relating to this bit and octet 3a is defined in Q.931
with
the following exceptions. An unregistered EP shall set this bit to 1. A
registered EP shall set this bit to 1 if the callModel component of
AdmissionConfirm is set to direct or callModel is set to gatekeeperRouted
and
the GK is v1 or v2. A GK shall set this bit to 1 and remove octet 3a
from the corresponding outgoing SETUP if "presentation allowed" is
indicated and the entity to which the message is sent to is v1 or v2. A GK
shall remove the calling party number IE from the corresponding outgoing
SETUP if "presentation restricted" is
indicated and the message is sent to a v1 or v2 entity."

We will probably have to see what happens in Santiago, but I worry that,
although the above approach will work, it is complex and a badly behaved
implementation could invoke unexpected behaviour in other entities down the
line which will make debugging installations troublesome.

Using the new IE approach seems a lot safer to me as it is simpler and I
can't see that a bad implementation will cause spurious faults to occur
elsewhere.  It is fail-safe whereas the above solution is more
fail-disaster!

I think there also needs to be a clear purpose/policy statement on what the
feature is to be used for.  Something along the lines of the following might
be appropriate:

"Implementers should be aware of the limitations inherent in the scheme for
calling party address identification and the privacy of this information.
By itself, the screening indicator provides no guarantee that the
information supplied is correct, and thus needs to be used in conjunction
with other mechanisms to establish its authenticity.  Likewise, by itself,
there is no implicit guarantee that a destination node will honour the
'Presentation Restricted' request in the calling party address field, and
thus, depending on the intended use of the feature, may contravene privacy
laws in certain legal jurisdictions."

Pete
=============================================
Pete Cordell
pete.cordell at btinternet.com
=============================================

-----Original Message-----
From: Paul Long <Plong at SMITHMICRO.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 19 May 1999 00:40
Subject: Re: caller ID and implementer's guide


>Pete,
>
>I like it! We can put something like this in v3:
>
>"The octet-3 extension bit of calling party number IE in SETUP may be set
to 0
>or 1, The behavior relating to this bit and octet 3a is defined in Q.931
with
>the following exceptions. An unregistered EP shall set this bit to 1. A
>registered EP shall set this bit to 1 if the callModel component of
>AdmissionConfirm is set to direct or callModel is set to gatekeeperRouted
and
>the GK is v1 or v2. A GK shall set this bit to 1 and remove octet 3a if
>"presentation allowed" is indicated and the destination EP is v1 or v2. A
GK
>shall remove the calling party number IE if "presentation restricted" is
>indicated and the destination EP is v1 or v2."
>
>You need to integrate the "next routing entity" stuff, because I haven't
been
>keeping up with it.
>
>Mind you, adding a new calling party number IE that allows this bit to be
set
>to 0, which someone suggested, would allow _all_ entities to interoperate
>regardless of version. However, if we absolutely must use the existing IE,
>your proposed work-around is a good compromise.
>
>Paul Long
>Smith Micro Software, Inc.
>
>        -----Original Message-----
>        From:   Pete Cordell [SMTP:pete.cordell at BTINTERNET.COM]
>        Sent:   Tuesday, May 18, 1999 4:16 AM
>        To:     ITU-SG16 at MAILBAG.INTEL.COM
>        Subject:        Re: caller ID and implementer's guide
>
>        Dear All,
>
>        One solution to the version number paradox might work in the
>gatekeeper
>        routed mode.  An endpoint can find out during registration and
prior
>to
>        sending SETUP the version number of the gatekeeper .  Based on the
>version
>        of the GK, an endpoint can decide whether to send presentation
>restricted
>        information to the GK.  If the remote endpoint, or the next
'routing
>entity'
>        is also registered with the GK, it will know its the version.  The
GK
>could
>        remove the IE based on this information.
>
>        On a wider scale, this also requires such information to be
included
>in
>        Annex G.  Is it?
>
>        Pete
>
>        =============================================
>        Pete Cordell
>        pete.cordell at btinternet.com
>        =============================================
>



More information about the sg16-avd mailing list