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@mailbag.intel.com