Recall: redundant, conflicting multirate indications

[Callaghan, Robert]

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 at siemens.at


-----Ursprüngliche Nachricht-----
Von: Plong [SMTP:Plong at 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 >>