RRQ Registration in H.323 V2

Rob B robb112 at HOTMAIL.COM
Fri Apr 16 14:04:28 EDT 1999


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 at ICN.SIEMENS.COM]
        Sent:   Friday, April 16, 1999 7:26 AM
        To:     ITU-SG16 at 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 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