caller ID and implementer's guide

Rich Bowen rkbowen at CISCO.COM
Fri May 7 15:49:54 EDT 1999


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 at cisco.com                      Research Triangle Park, NC
--------------------------------------------------------------------
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) !
> 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



More information about the sg16-avd mailing list