caller ID and implementer's guide

[Paul Long]

Karl,

It may have been a mistake to exclude octet 3a, but it is far too late to
"fix" this through its inclusion. H.323 is not merely an academic work that is
forever in progress, with no real repercussions if we change it. Compliant
products have been shipped according to what is written in the H.323
Recommendation. Moreover, because an EP cannot determine the H.323 version of
the remote EP before sending its SETUP, octet 3a must forever be excluded in
H.323.

Here is a way we can maintain H.323's integrity and provide the apparently
much needed information in octet 3a. Carry the value for octet 3a in
H323-UU-PD.nonStandardData. Have boundary entities between the packet network
and the SCN move this value between the real octet 3a on the SCN side and the
octet-3a proxy on the packet side. Smith Micro would "donate" our H.221
identifier, but we could use anyone's. The nonStandardData.data octet string
would hold an ASN.1 encoding of this type:

H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE
{
callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL,
...
}

Practically speaking,
if h323-message-body is setup,
h323-uu-pdu.nonStandardData is present,
h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard,
h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStandard is {181, 0,
30324}, and
bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1
(callingPartyNumberIEOctet3a is present), then
h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a.

Note that, according to ASN.1 PER aligned encoding, bits 6 through 1 of
h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit 8 indicates
whether other, TBD components are present that are not in the root extension.
This allows us to provide other info in the future if needed.

This is what H323-UU-PD.nonStandardData would typically be set to:
{
        h221NonStandard { 181, 0, 30324 },      -- Smith Micro's H.221
identifier
        { 64, x }               -- x is octet 3a from calling party number
information element
}

This is similar to an H.324 fix, so there is precedent for this sort of thing.

Paul Long
Smith Micro Software, Inc.

        -----Original Message-----
        From:   Karl.Klaghofer at ICN.SIEMENS.DE
[SMTP:Karl.Klaghofer at ICN.SIEMENS.DE]
        Sent:   Friday, May 07, 1999 3:43 AM
        To:     ITU-SG16 at MAILBAG.INTEL.COM
        Subject:        AW: caller ID and implementer's guide

        Glen and others,

        It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2)
Calling
        party number IE.  It has led to interoperability problems with the SCN
in
        the past (where octet 3a is used) !
        Now, it is time to fix this error as discussed in the Monterey
Rapporteuts
        meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via
        Implementors Guide !). There may be procucts already planning on that
        announced correction.

        An endpoint B - not supporting octet 3a of Calling Party Number
Information
        element - should treat this situation as a "non-mandatory information
        element content error". The reaction to such an type of error shall
be:
        *       Take actions on the SETUP received and on all the information
        elements that are recognized and have valid contents; i.e. ignore only
the
        Calling party Number IE
        *       A STATUS may optionally be returned with Cause #100.

        Refer also to Q.931 clause 5.8.7.2 (which should applicable also to
H.225.0,
        since H.225.0 is so much based on the Q.931).

        So, if such an endpoint B receives an octet 3a in Calling party Number
set
        to "presentation allowed", all that happens is that the Number would
not be
        displayed at B.
        But for the really critical case where the octet 3a is received by
such an
        endpoint B being set to "presentation restrictet", we have even the
behavier
        we intend, namely NOT to display the number to the endpoint B (since
the
        whole IE should be ignored anyway).

        A miscoded optional Information element should never lead to a
clearing of
        the call !

        Regards,
        Karl
        ------------------------------------------------
        Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1
        Hofmannstr. 51, D-81359 Munich, Germany
        Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
        e-mail: karl.klaghofer at icn.siemens.de


        > -----Ursprüngliche Nachricht-----
        > Von:  Glen Freundlich [SMTP:ggf at lucent.com]
        > Gesendet am:  Donnerstag, 6. Mai 1999 22:11
        > An:   ITU-SG16 at mailbag.cps.intel.com
        > Betreff:      caller ID and implementer's guide
        >
        > At the Monterey meeting we discussed the possibility of an addition
to
        > the Implementer's Guide to support caller ID features (APC-1527).
        > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party
        > Number IE (and also specifies that the octet 3 extension bit shall
be
        > set to 1). The proposal calls for removing the restriction through
the
        > Implementer's Guide. (See also the meeting report in APC-1554b.)
        >
        > Fixing this brings up the possibility of interoperability problems
with
        > existing products. Please respond if you think this change will be a
        > problem. You can respond to me individually, rather than to the
entire
        > list, if you prefer.
        >
        > Thanks,
        > Glen
        >
        >
        > --
        > Glen Freundlich                           ggf at lucent.com
        > Lucent Technologies                       office: +1 303 538 2899
        > 11900 N. Pecos                            fax: +1 303 538 3907
        > Westminster, Colorado 80234  USA