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