Another H323/H225 defect

[Callaghan, Robert]

Paul,

I brought a contribution to Belin for the correction of this problem.  It
was rejected as breaking many current implementations.

We will have to live with this errror.

Bob

------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756    Fax: +1.561.923.1403
Email:  Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------

-----Original Message-----
From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
Sent: Saturday, June 10, 2000 7:02 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Another H323/H225 defect


Folks,

Since we're raising issues with coding Q.931 IEs, I thought that it would be
appropriate to post this message I received some time back.  (I removed the
person's name and such, in case they preferred not to share this with the
world.)

Is this a change that we should consider?

Paul

----- Original Message (modified) -----

During recent H323 interoperability testing in Portland the problem detailed
below was identified. I could not find an existing Implementors Guide or
draft recommendation that covers this issue. Could you take a look at this
and let me know if there is an existing decision (or update) on this item.

Affected recommendation:
H225

Summary:
Q931 and H225 descriptions of Bearer Capability IE octet 4 are not
consistent

Description:
In Q931 Section 4.5.5 Bearer Capability IE octet 4 always has the extension
bit set. The existence of octet 4.1 is determined based on the contents of
octet 4. This is shown in Figure 4-11/Q.931 and elaborated on by Note 1
below the table. In H225 Section 7.2.2.1 Bearer Capability IE octet 4
extension bit "Shall be set to '0' if the information transfer rate is set
to multirate". However the same section says that the information element is
encoded according to Figure 4-11/Q.931.

Suggested resolution:
Document (in H225) this bit as working as documented in Q931. Add a note
that implementations should not rely upon this bit and should not use it as
an indication that octet 4.1 exists (instead should check for multirate
setting). This solution will have a low level of impact on existing systems
and retains interoperability with Q931 ISDN equipment.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000612/a4ac0ced/attachment-0004.html>