caller ID and implementer's guide

Tue May 11 15:36:00 EDT 1999

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 at btinternet.com
=============================================

-----Original Message-----
From: Paul Long <Plong at SMITHMICRO.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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
>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 at ICN.SIEMENS.DE
>[SMTP:Karl.Klaghofer at ICN.SIEMENS.DE]
>        Sent:   Tuesday, May 11, 1999 5:49 AM
>        To:     ITU-SG16 at 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
>