Bob,
But that's not what H.225.0 says. 7.2.2.1/H.225.0v2: Extension bit for octet #4 (bit 8) - Shall be set to '0' if the information transfer rate is set to 'multirate'; shall be set to '1' otherwise. So it indicates whether the octet-4 rate field is set to multirate, which in turn implies that octet 4.1 is present, according to Q.931. It does not directly indicate whether octet 4.1 is present, regardless of what Q.931 says. That's why, IMO, this normative text in 7.2.2.1 is needlessly redundant and error prone, as I found out at the interop.
Therefore, the only correct encodings are:
extension bit: 0, rate: multirate, octet 4.1 present
and
extension bit: 1, rate: not multirate, octet 4.1 not present
In particular, the encoding which I encountered at the interop,
extension bit: 1, rate: multirate, octet 4.1 present
is definitely not correct.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Friday, April 16, 1999 7:26 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: redundant, conflicting multirate indications
Paul,
There appears to be a misunderstanding as to the meaning of "extension bit." For all of the Q.931 coded elements, the extension bit set to zero indicates that the octet is extended. If set to one, the octet is not extended.
Section 7.2.2.2/H225.0v2 states that the extension bit of octet 4 is set to zero for when multi-rate is present. This only means that the multirate octet (4.1) is present. Or as an inverse, is the bit is set to one, then octet 4.1 may not be present. This does not mean, in itself, that multirate is not present.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Friday, April 16, 1999 12:03 AM To: ITU-SG16@mailbag.cps.intel.com Subject: redundant, conflicting multirate indications
Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant?
It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation.
Paul Long Smith Micro Software, Inc.