AW: H.225.0 v4 inconsistencies/errors found

[Klaghofer Karl ICN SIB NL D1]

Paul,

With not correcting the extension bit, a v1,v2 receiver of a current v3 or
v4 Calling party number IE (that includes octet 3a) would interpret the
octet 3a being the first number digit. I do not consider this backwards
compatible !

With correcting the extension bit as proposed below, the backwards
compatibility problem would be solved.
A v1,v2 receiver always expects octet 3 bit 8 set to 1. So far we agree. See
two cases below:
a) If a v3,v4 sender does not include octet 3a the extension bit would be
set to 1 and the v1,v2 receiver is happy and can interpret the IE.
b) If the v3, v4 sender does include the octet 3a, the extension bit shall
be set to 0. The v1, v2 receiver is required to act according to the so
called "non-mandatory information element contents error procedures of
Q.931", which is to ignore the IE but process the rest of the message -
which is exactly what we want since the v1, v2 receiver would e.g. not honor
a presentation restriction flag anyway.
Paul, to release the call due to a non mandatory information element content
error - as you mention -  is wrong behavier.

Please no further field or element  - we have already enough of them !

Regards,
Karl

> -----Ursprüngliche Nachricht-----
> Von:  Paul Long [SMTP:Plong at SMITHMICRO.COM]
> Gesendet am:  Thursday, June 08, 2000 05:03
> An:   ITU-SG16 at mailbag.cps.intel.com
> Betreff:      Re: H.225.0 v4 inconsistencies/errors found
>
> Karl,
>
> 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
> To: ITU-SG16 at MAILBAG.INTEL.COM
> 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
> 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.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

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