Paul,
having been through it a number of time does not solve a problem at all unless we fix it.
Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'.
Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul Long [mailto:Plong@SMITHMICRO.COM] Gesendet am: Donnerstag, 08. Juni 2000 05:03 An: ITU-SG16@mailbag.cps.intel.com Betreff: Re: H.225.0 v4 inconsistencies/errors found
Karl,
We've been through this before. Allowing the extension bit in octet 3 to be set to 0 causes H.225.0v4 to be inconsistent with earlier versions and potentially causes insurmountable backwards-compatibility problems between v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set to 0 under any circumstances. Since the calling EP cannot know the version of the called EP before it sends Setup, it would be sending an IE that would contain invalid content for a pre-v4 EP. According to Q.931, the receiving EP would then be required to terminate the call with ReleaseComplete. A safe solution would be to add a new Calling Party Number field where this bit is allowed to be set to 0.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Klaghofer Karl ICN SIB NL D1 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, June 07, 2000 10:29 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H.225.0 v4 inconsistencies/errors found
Rich, and others
Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since these are inconsistencies/errors. Comment 5 could be solved later.
- Calling Party Number IE (octet 3 extension bit 8)
The H.225.0v4 definition looks as follows:
Set to '1'This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read:
Set to '1' if octet 3a is not present; set to "0" ifoctet 3a is present.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com