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