ITU Red Bank Minutes - COMMENTS

Morgan Potter morgan.potter at BT.COM
Wed Nov 3 13:56:15 EST 1999


H.225.0 says that the extension bit cannot be 0. Setting it to 1 violates
the standard. Besides, there may be compliant EPs that justifiably assume
this bit to be set correctly. As with all non-compliant behavior, the result
is non-determinant. The compliant EP may, for example, accept the
transgression, reject the call, or crash. We've been through this before.
We'll just have to agree to disagree.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Horvath Ernst [mailto:ernst.horvath at SIEMENS.AT]
Sent: Wednesday, November 03, 1999 11:39 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: AW: presentationIndicator and Calling Party Number


Paul,

from H.225.0 subclause 7.2.2 it is clear that the general encoding rules
of
Q.931 apply. Setting bit 8 of octet 3 to 1 was correct as long as octet
3a
was forbidden in H.225.0. Now, since octet 3a is allowed, bit 8 must
follow
the rules for an extension bit.

I recognize your backwards compatibility issue, but a proper
implementation
of Q.931 encoding and error rules should allow an old implementation to
cope
with this situation gracefully.

Ernst Horvath
Siemens AG


> -----Ursprüngliche Nachricht-----
> Von: Paul Long [mailto:plong at SMITHMICRO.COM]
> Gesendet am: Mittwoch, 3. November 1999 17:33
> An: ITU-SG16 at mailbag.cps.intel.com
> Betreff: Re: presentationIndicator and Calling Party Number
>
> H.225.0 has always required that the octet-3 extension bit in
> calling party
> number be set to 1. Regardless of the reason for it being
> this way, setting
> it to 0 renders an EP non-compliant and risks
> interoperability problems. In
> addition, H.225.0 cannot be changed in this regard in a future version
> without risking interoperability problems.
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Horvath Ernst [mailto:ernst.horvath at SIEMENS.AT]
> Sent: Wednesday, November 03, 1999 10:06 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: AW: presentationIndicator and Calling Party Number
>
>
> Hi,
>
> see inserted answers below.
>
> Ernst Horvath
> Siemens AG
>
> > -----Ursprüngliche Nachricht-----
> > Von: henri.maenpaa at NOKIA.COM [mailto:henri.maenpaa at NOKIA.COM]
> > Gesendet am: Mittwoch, 3. November 1999 15:55
> > An: ITU-SG16 at mailbag.cps.intel.com
> > Betreff: presentationIndicator and Calling Party Number
> >
> > All,
> >
> > First, there seems to be some inconsistency about the use of
> > 3a octet of
> > Q931 CallingPartyNumber field in H.225.0. Hopefully this is just an
> > editorial mistake.
> >
> > Q931 (05/98) states the following (chapter 4.5.1 Coding Rules):
> > c)      An octet group is formed by using some extension
> > mechanism. The
> > preferred extension mechanism is to extend an octet (N)
> > through the next
> > octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an
> > extension bit.
> > The bit value "0" indicates that the octet continues through
> > the next octet.
> > The bit value "1" indicates that this octet is the last
> > octet. If one octet
> > (Nb) is present, also the preceding octets (N and Na) must
> be present.
> >
> > Whereas H.225.0v3 (09/99) seems to do the opposite in Calling
> > Party Number
> > field by telling to set the octet 3 extension bit to 1, and
> > use octet 3a as
> > "encoded following the values and rules of table 4-9/Q931."
> >
>
> [EH:] This can only be an oversight. The correct text must be
> for bit 8
> of
> octet 3: Set to '1' if octet 3a is not present, set to '0' otherwise.
>
> >
> > Second, I am also wondering why H.225.0 currently allows two
> > methods for
> > CLIP/CLIR indication:
> > Octet 3a and the ASN.1 side presentationIndicator IE. OK,
> the standard
> > states strictly that octet 3a overrides the other, and
> therefore there
> > should not be insolvable conflicts at the receiving entity,
> > but still why
> > they were both included?
> >
>
> [EH:] H.225.0 allows two places to include calling party information
> (both
> optional): the Calling party number information element and the
> sourceAddress field in User-user. The presentationIndicator field is
> intended for the latter one.
>
>
> > -Henri Mäenpää, Nokia
> >
>



More information about the sg16-avd mailing list