H.225.0 v4 inconsistencies/errors found

[Rich Bowen]

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

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

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