Hi Karl,

Klaghofer Karl ICN SIB NL D1 wrote:

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.

I agree.

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

Oops! OK.

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.

This is also in v3. I'm curious as to why the "not used" comment was included in v3. It does not appear in the original contribution APC-1527/Monterey, or in the Monterey meeting report. I agree there is a conflict, but I'm not certain which is correct. Does anyone recall the history behind this restrive comment in the ASN.1?

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.

These fields are also mandatory in v3. I believe this was an error in v3.

I agree it should be changed, but this has to be agreed to for the v3 IG, and would have to be agreed upon immediately, as with the other ASN.1 changes that Paul Jones has been discussing.

Are there any objections to making the presentationIndicator and screeningIndicator fields OPTIONAL in v3 via the Implementors Guide?

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), .....

IMO, we should keep it simple, one indicator applies to all aliases. E.g., in example 2, if one verification fails, they all are considered to have failed. Is it really valuable to be able to independently indicate the status of multiple aliases?

The alternative would be to have a list of presentation and screening indicators. I think it's too late to add this to v3, and would be complicated to add to v4 since it would be a separate field. (It's bad enough that we have both an indicator field and an IE in some messages!)

Regards, Rich

Regards, Karl Klaghofer, Siemens AG

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

-- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC --------------------------------------------------------------------

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