At 10:43 AM 5/7/99 +0200, 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) !
I agree. I might be okay in an enterprise environment, but in a Service Provider environment the lack of Octet 3a makes it impossible to support the CLIP/CLIR service as defined in Q.951 in an standard manner.
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 informationelements 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.
The only problem I see is the optional STATUS message. Implementations using the STATUS message option will generate unnecessary traffic. In a low-volume environment, this shouldn't be too bad.
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).
In the case of interoperating with a v1/v2 implementation that doesn't recognize Octet 3a, the receiver will drop the Information Element and, worst case, send a STATUS message. Thus, worst case is that the Calling Party Number will not be available to the receiving endpoint. This seems to be a sufficient failsafe to me.
Since the SCN Gateway must implement policy anyway, it could also have a policy to act on Octet 3a differently (e.g., drop the Calling Party Number if "presentation restricted" is encoded or the digits aren't available and pass it on without Octet 3a otherwise.).
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
-------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------