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@ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, May 07, 1999 3:43 AM To: ITU-SG16@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@icn.siemens.de
> -----Ursprüngliche Nachricht----- > Von: Glen Freundlich [SMTP:ggf@lucent.com] > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > An: ITU-SG16@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@lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA