caller ID and implementer's guide

Rich Bowen rkbowen at CISCO.COM
Mon May 10 11:50:20 EDT 1999


All,

I would agree with Chris that the nonStandardData field is not
the most preferred place for the octet 3a information, although
the suggested solution from Paul is appreciated.

Although I believe that endpoints that did not understand octet
3a should have ignored it, I think we can include octet 3a and
adequately provide for backward compatibility if the new text
for the H.323 v2 implementors' guide indicates that:

 o Implementations that include octet 3a "must" provide a
   means to administratively disable its inclusion.
 o Implementations that do not understand octet 3a "should"
   ignore it.

Would this approach address the backward compatibility concerns?
Would it place an undue burden on implementors who wish to
include octet 3a?

To avoid propagating this error, text for H.323 v3 should reverse
"must" and "should" in the above two bullets.  For v3, the
"reasonable period of time" requirement of WTSC-96 Resolution 1
will have been met, and implementors will have received a warning
from the v2 implementors' guide assuming the above changes are
included.

Regards,
Rich
--------------------------------------------------------------------
Richard K. Bowen                       Cisco Systems, Inc.
rkbowen at cisco.com                      Research Triangle Park, NC
--------------------------------------------------------------------
Chris Purvis wrote:
>
> Paul,
>
> If we're going to standardise it, why should it be nonStandard?  In other
> words, if it is considered an important thing to add, and it is considered
> impossible to include it in its original place (on which I express no
> opinion), then it should be added to the standard as an information element
> in the H.225.0 message, not put in a standard bit of non-standard
> information.  If my reading of the ASN.1 is correct, and we were to follow
> your suggestion, it would be impossible to transmit a setup message with the
> addition you propose and also a non-standard parameter of my own devising
> (unless, of course, I could persuade Smith Micro to "like" my non-standard
> information and put it in their private non-standard parameter) - and I am
> sure this would be unacceptable to many.
>
> Regards,
> Chris
> --
> Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
> Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.  ENGLAND
> Phone: +44 1753 661 359  email: cpurvis at madge.com
>
> > -----Original Message-----
> > From: Paul Long [mailto:Plong at SMITHMICRO.COM]
> > Sent: 08 May 1999 3:22
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: caller ID and implementer's guide
> >
> >
> > Karl,
> >
> > It may have been a mistake to exclude octet 3a, but it is far
> > too late to
> > "fix" this through its inclusion. H.323 is not merely an
> > academic work that is
> > forever in progress, with no real repercussions if we change
> > it. Compliant
> > products have been shipped according to what is written in the H.323
> > Recommendation. Moreover, because an EP cannot determine the
> > H.323 version of
> > the remote EP before sending its SETUP, octet 3a must forever
> > be excluded in
> > H.323.
> >
> > Here is a way we can maintain H.323's integrity and provide
> > the apparently
> > much needed information in octet 3a. Carry the value for octet 3a in
> > H323-UU-PD.nonStandardData. Have boundary entities between
> > the packet network
> > and the SCN move this value between the real octet 3a on the
> > SCN side and the
> > octet-3a proxy on the packet side. Smith Micro would "donate"
> > our H.221
> > identifier, but we could use anyone's. The
> > nonStandardData.data octet string
> > would hold an ASN.1 encoding of this type:
> >
> > H323-UU-PD-SMSINonStandardParameter ::= SEQUENCE
> > {
> > callingPartyNumberIEOctet3a OCTET STRING SIZE(1) OPTIONAL,
> > ...
> > }
> >
> > Practically speaking,
> > if h323-message-body is setup,
> > h323-uu-pdu.nonStandardData is present,
> > h323-uu-pdu.nonStandardData.nonStandardIdentifier is h221NonStandard,
> > h323-uu-pdu.nonStandardData.nonStandardIdentifier.h221NonStand
> > ard is {181, 0,
> > 30324}, and
> > bit 7 (bit 8 is MSB) of h323-uu-pdu.nonStandardData.data[0] is 1
> > (callingPartyNumberIEOctet3a is present), then
> > h323-uu-pdu.nonStandardData.data[1] contains the value for octet 3a.
> >
> > Note that, according to ASN.1 PER aligned encoding, bits 6
> > through 1 of
> > h323-uu-pdu.nonStandardData.data[0] are always 0 and that bit
> > 8 indicates
> > whether other, TBD components are present that are not in the
> > root extension.
> > This allows us to provide other info in the future if needed.
> >
> > This is what H323-UU-PD.nonStandardData would typically be set to:
> > {
> >         h221NonStandard { 181, 0, 30324 },      -- Smith Micro's H.221
> > identifier
> >         { 64, x }               -- x is octet 3a from calling
> > party number
> > information element
> > }
> >
> > This is similar to an H.324 fix, so there is precedent for
> > this sort of thing.
> >
> > Paul Long
> > Smith Micro Software, Inc.
> >
> >         -----Original Message-----
> >         From:   Karl.Klaghofer at ICN.SIEMENS.DE
> > [SMTP:Karl.Klaghofer at ICN.SIEMENS.DE]
> >         Sent:   Friday, May 07, 1999 3:43 AM
> >         To:     ITU-SG16 at MAILBAG.INTEL.COM
> >         Subject:        AW: caller ID and implementer's guide
> >
> >         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