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.
- 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.
- 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) OPTIONALIf 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 inH.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