My two cents - each worth one cent each...

1) You should only send private information in a clear text field to an entity that you trust to honour the request not to display it. If you know enough about the entity to trust it, you probably know enough about it to know whether it will accept octet 3a.

2) If you must send this information to an entity that you don't know anything about, you could take further ownership of the use of Q.931 and define a new IE and IE identifier (such as 0x6e or hi-jack one of the ids that you are very unlikely to use - 0x43) to mean 'calling party number with presentation restriction'. This would have the same format as a normal Q.931 calling party number.

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: 11 May 1999 17:05 Subject: Re: caller ID and implementer's guide

Karl,

H.225.0 is the _referencing_ Recommendation for Q.931. Therefore, H.225.0 can--and quite often does--modify aspects of Q.931. One of the many ways

that

H.225.0 modifies Q.931 is by requiring that the octet 3 extension bit in

the

calling party number IE be set to 1, which precludes the presence of octet

3a.

It does not say that it _should_ or _may_ be set to 1; it says that it "_shall_ be set to '1'." Therefore, discussion of what a receiving EP

shall

do when the extension bit is set to 0 is kind of moot, because this bit is always set to 1 for communication between compliant EPs starting with

version

However, we can discuss the behavior of a compliant EP in communication

with a

non-compliant EP which sends a SETUP with the octet 3 extension bit in the calling party number IE set to 0. Upon further consideration of your

previous

post, I have to agree with you that an EP shall ignore the IE and

optionally

send STATUS and that it clearly shall not clear the call or accept the IE

but

ignore octet 3a.

Here's the only completely safe solution I can think of that fulfills everyone's needs, if not wants.

1. State in the Implementers Guide that the calling party number IE is only

included if presentation is allowed. We don't need to say anything about

not

encoding octet 3a because this is already precluded.

2. Extend the H323-UU-PDU type in v3 with the following component and allow

the calling party number to be placed in there. Border entities move the

value

between the real IE on the SCN side and this IE proxy on the H.323 side.

   callingPartyNumberIE OCTET STRING SIZE(2..131) OPTIONAL

If present, the calling party number can be placed in either location but

not

both, so on the H.323 side a v3+ EP could always place the calling party number in the IE proxy or place it in the real IE if presentation is

allowed.

How about this solution? It's straightforward, easy to implement, maintains the integrity of H.323, doesn't set a bad precedent, and maintains interoperability among all shipping and future products. It's admittedly inelegant, but the only elegant solution is to go back in time a few years

and

rewrite H.225.0v1.

Paul Long Smith Micro Software, Inc.

   -----Original Message-----
   From:   Karl.Klaghofer@ICN.SIEMENS.DE

[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Tuesday, May 11, 1999 5:49 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: AW: caller ID and implementer's guide

   Paul, Chris, Glen,

   1)  I have to agree with Chris, the nonStandard field is not

suitable

to carry standardized information, due to the mentioned reasons.

   2) I have thought about the alternative Chris proposed: I think to

put

the presentation indicator bits in a new standardized

H.225.0/Setup-UUIE

field to control the handling of the presentation of Calling Party Number

IE

   contents is not "save" either, since an endpoint (not yet

supporting

this additional coding) would display the Calling party Number contents although the intention of the calling party was probably NOT to display it

at

the destination (in case of "presentation restriction" being set).

   3) I did not hear any opinion on the expected error procedures in

H.225.0 upon receiving optional information elements having a content error

?

   Again, if I follow Q.931, section 5.8.7.2 - which should be the

source

for H.225.0 - then a receiving endpoint not knowing the proposed "new" octet 3a in Calling Party Number IE, would find octet3/bit8 set to "0" and would (acc. to Q.931) treat this as an information element contents error

of

an optional information element and therefore ignore the IE but

process

the message. This has the advantage that no unintended display of a restricted number would take place. It has the disadvantage that if 3a is set to "presentation allowed", the number would not be displayed either. Solution: In

the

   Implementors Guide we can say that octet 3a in H.225.0v2 shall only

be

set with "presentation restriction". If the presentation shall be

allowed,

NO octet 3a shall be sent (no octet 3a means "presentation allowed"

per

   default).

   Regards,

   Karl