Another H323/H225 defect

Paul E. Jones paulej at PACKETIZER.COM
Sat Jun 10 19:02:06 EDT 2000


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/20000610/ccd32c32/attachment-0003.html>


More information about the sg16-avd mailing list