presentationIndicator and Calling Party Number

[Paul Long]

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
>