AW: H.225.0 v4 inconsistencies/errors found
rkbowen at CISCO.COM
Thu Jun 8 15:21:25 EDT 2000
The backward compatibility issue was debated last year on the mailing
lists and in Santiago (5/99). No implementor claimed to have a backward
compatibility problem, and it was agreed in Santiago that octet 3a would
be allowed, as shown in H.225.0 v3. However, now the text is
inconsistent with itself, in that it allows octet 3a but says that the
extension bit shall be set to 1, thus indicating that octet 3a is not
present. This is an error in v3 that needs to be corrected to indicate
that the value may be either 0 or 1 to indicate the presence of octet
Chris Wayman Purvis wrote:
> Likewise the fact remains that as in earlier versions the bit "shall not" be
> set, so earlier version devices on receiving a SETUP message with the bit set
> at best should be sending RELEASE COMPLETE and at worst have undefined
> In other words suddenly allowing this bit to be set knowingly violates the
> ITU's principle of backward compatibility, and is hence not acceptable if you
> wish the resulting protocol to be called H.323.
> I take issue with your "comprehension-required" points too. My (hazy)
> understanding is that if bit 8 or octet 3 is set to 0, this inserts an extra
> byte into the message (octet 3a) - so comprehension of this bit is clearly
> required if the rest of the message is to be parsed!
> Horvath Ernst wrote:
> > Paul,
> > having been through it a number of time does not solve a problem at all
> > unless we fix it.
> > Facts are:
> > 1) Octet 3a is an optional octet in calling party number IE. It may or may
> > not be present.
> > 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2),
> > specifies the use of the extension bit to indicate presence or absence of
> > optional octets.
> > 3) My interpretation of 126.96.36.199 of H.225.0 is that Q.931 clause 4.5.10
> > applies for the coding of calling party number, including the use of octet 3
> > bit 8 as extension bit.
> > 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly
> > set to '1'.
> > 5) Octet 3a, when present, poses a problem for v1 in any case, independent
> > of bit 8 of octet 3!
> > 6) Clearing the call if an optional information element is flawed is not
> > correct - it should be ignored. Clearing is only correct for erroneous
> > mandatory or 'comprehension-required' optional IEs. Calling party number is
> > not 'comprehension-required'.
> > Ernst Horvath
> > Siemens AG
> > > -----Ursprüngliche Nachricht-----
> > > Von: Paul Long [mailto:Plong at SMITHMICRO.COM]
> > > Gesendet am: Donnerstag, 08. Juni 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
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire. RG42 6LY ENGLAND
> Phone: +44 1344 899 007
> Fax: +44 1344 899 001
> 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
More information about the sg16-avd