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