Hi,

H.323 V1 and V2 endpoints correctly assume that octet 3a is not present since H.225.0 states that it shall not be. Therefore there are endpoints that don't check for the extension bit of octet 3 (i.e. assume it is 1). I agree that it is useful to forward octet 3a but backward compatibility must be met.

Kaynam

Rich Bowen rkbowen@CISCO.COM on 05/07/99 03:49:54 PM

Please respond to Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@mailbag.cps.intel.com

To: ITU-SG16@mailbag.cps.intel.com cc: (bcc: Kaynam Hedayat/PicTel) Subject: Re: caller ID and implementer's guide

Glen, others,

I also would support the proposal to allow octet 3a. We have had requests from customers to allow this information.

Not knowing about APC-1527, I also submitted a contribution to allow octet 3a (D-264), with proposed text indicating that gateways "should" forward this information as received from the SCN. As Glen has indicated, however, we need to look further into interoperability issues.

Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Karl.Klaghofer@ICN.SIEMENS.DE wrote:

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