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

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

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 1.

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

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

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

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

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

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

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 that the previous optionally put source process the

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

set with "presentation restriction". If the presentation shall be allowed, NO octet 3a shall be sent (no octet 3a means "presentation allowed"

be per

default).

Regards,

Karl