caller ID and implementer's guide

[Kaynam Hedayat]

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 at 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 at mailbag.cps.intel.com>

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


-------------- next part --------------


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