H.225.0 v4 inconsistencies/errors found

Klaghofer Karl ICN SIB NL D1 Karl.Klaghofer at ICN.SIEMENS.DE
Wed Jun 7 11:28:32 EDT 2000


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.


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
present.


2) Calling Party Number IE in draft H.225.0v4 (editorial only)
There are two descriptions for "Type of number" in the H.225.0v4 draft - one
too much. The first one should be deleted.
".....
Type of number (octet No. 3, bits 5-7)
-       Encoded following the values and rules of Table 4-11/Q.931.

Type of number (octet No. 3, bits 5-7)
-       Encoded following the values and rules of Table 4-11/Q.931. A number
with the Numbering plan identification coded as '0000' (Unknown) shall be
coded as '000' (Unknown). A number with the Numbering plan identification
coded as '0001' (ISDN/Telephony Numbering Plan, Recommendation E.164) with
the Type of number coded as '000' (Unknown) may be used for backward
compatibility.
......."


3) Inconsistency of Screening Indicator usage

With use of Calling Party Number IE, the octet 3a allows for setting of all
four Q.931 defined Screening indicator values.

When using the Setup-UUIE.screeningIndicator (for controlling the
Setup-UUIE.sourceAddress), then the value "userProvidedVerifiedAndFailed" is
not allowed (according to the current ASN.1 comment of type
ScreeningIndicator definition).
This is inconsistent. Since the text in H.323v3, v4 clause 7.8 Caller
Identification Service allows the usage of all four values, the current
ASN.1 comment for ScreeningIndicator value (2) which reads "-- not used,
value reserved" should be deleted in v4.


4) Arguments presentationIndicator and screeningIndicator in Setup-UUIE
should be OPTIONAL
Why are they mandatory in H.225.0v4 ?  What if I do not include the
sourceAddress ?
Same comment applies to Alerting-UUIE, ReleaseComplete-UUIE, Connect-UUIE
Please also check v3.


5) Multiple alias addresses in Setup-UUIE.sourceAddress - how to apply
different screening indicators/presentation indicators
The Setup-UUIE.sourceAddress allows to put multiple aliases (sourceAddress
SEQUENCE OF AliasAddress) within the SETUP message. With the current
definition of types  ScreeningIndicator and PresentationIndicator it is not
possible to have different settings for the various aliases contained in
sourceAddress.
The same comment applies to busyAddress, alertingAddress and
connectedAddress.
Example 1: How to set e.g. the Setup-UUIE.screeningIndicator if the terminal
has provided an alias 1 in Setup-UUIE.sourceAddress (i.e. screeningIndicator
should be set to userProvidedNotScreened (0) for this alias) but the GK adds
an alias 2 (i.e. screeningIndicator should be set to networkProvided (3) for
this alias).
Example 2: Both aliases provided by terminal. GK screens both aliases - one
verification is successful (i.e. use value 1), the other is verified and
failed (i.e. value 2 should be used), .....

Regards,
Karl Klaghofer,
Siemens AG

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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