AW: presentationIndicator and Calling Party Number

[Horvath Ernst]

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