AW: caller ID and implementer's guide

[Chip Sharp]

At 10:43 AM 5/7/99 +0200, Karl.Klaghofer at 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 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.

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 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

--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085
Cisco Systems              Consulting Eng. - Telco
Reality - Love it or Leave it.
--------------------------------------------------