H.225.0 v4 inconsistencies/errors found

Paul Long Plong at SMITHMICRO.COM
Wed Jun 7 23:02:31 EDT 2000


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 at ICN.SIEMENS.DE]
Sent: Wednesday, June 07, 2000 10:29 AM
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
the ASN.1 elements ScreeningIndicator and PresentationIndicator.
Comments no. 1-4 should be corrected by the editor in v4, since these
inconsistencies/errors. Comment 5 could be solved later.

1) 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" if octet 3a is

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list