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@btinternet.com =============================================

-----Original Message----- From: Paul Long Plong@SMITHMICRO.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@BTINTERNET.COM]
   Sent:   Tuesday, May 18, 1999 4:16 AM
   To:     ITU-SG16@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@btinternet.com
   =============================================