redundant, conflicting multirate indications

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Fri Apr 16 08:26:11 EDT 1999


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 at ICN.Siemens.com
------------------------------------------------------------------


-----Original Message-----
From: Paul Long [mailto:Plong at SMITHMICRO.COM]
Sent: Friday, April 16, 1999 12:03 AM
To: ITU-SG16 at 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.



More information about the sg16-avd mailing list