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 thegatekeeper 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 =============================================