presentationIndicator and Calling Party Number
plong at SMITHMICRO.COM
Wed Nov 3 11:33:22 EST 1999
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.
Smith Micro Software, Inc.
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
see inserted answers below.
> -----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
> 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
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
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