caller ID and implementer's guide

Glen Freundlich ggf at lucent.com
Mon May 10 11:04:36 EDT 1999


Paul, Chris, and others interested,

In APC-1527 of the Monterey meeting, I had proposed adding presentation
and screening indicators in the ASN.1 definitions for several
H.225/Q.931 messages. These were needed in the event the Calling Party
Number IE is not used (e.g., when using an alias address that is not a
telephone number). This would go into V3 and would seem to not create
any interop problems among versions of H.225. It means waiting until V3,
and may not be a good general fix to other potential inconsistencies
between Q.931 and H.225, if they exist.

Glen


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

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