AW: presentationIndicator and Calling Party Number
Hi, see inserted answers below. Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: henri.maenpaa@NOKIA.COM [mailto:henri.maenpaa@NOKIA.COM] Gesendet am: Mittwoch, 3. November 1999 15:55 An: ITU-SG16@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
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@SIEMENS.AT] Sent: Wednesday, November 03, 1999 10:06 AM To: ITU-SG16@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@NOKIA.COM [mailto:henri.maenpaa@NOKIA.COM] Gesendet am: Mittwoch, 3. November 1999 15:55 An: ITU-SG16@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
participants (2)
-
Horvath Ernst -
Paul Long