caller ID and implementer's guide
Chris Purvis
Chris.Purvis at MADGE.COM
Mon May 10 05:22:41 EDT 1999
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