Mr. Long,

the information in 7.2.2.1/H.225.0 conflicts with Q.931 and in my opinion should be changed to align with Q.931. In Q.931 the extension bit of octet 4 indicates the presence of octets 4a/4b, _not_ of octet 4.1. The presence of octet 4.1 depends only on the rate field of octet 4.

I propose to fix this obvious mistake in V3 of H.225.0 and also put something into the implementors guide for V2.

Ernst Horvath Siemens AG Email: ernst.horvath@siemens.at

-----Ursprüngliche Nachricht----- Von: Plong [SMTP:Plong@SMITHMICRO.COM] Gesendet am: Freitag, 16. April 1999 06:03 An: ITU-SG16 Cc: Plong Betreff: 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. << Datei: redundant, conflicting multirate indications.TXT >>