Clarification of H.245 MTSE

Paul Long plong at SMITHMICRO.COM
Tue Sep 30 23:53:13 EDT 1997

Text item:

Corey (and Mike),

I think your proposed text for appendix IV is appropriate. I didn't hear any
problems with including the clarification in Sunriver. This issue, and others,
relating to how extentions are handled was (Q11-A-50) discussed at the Portland
Q11 meeing in June.

Chris Hansen, Intel

Dear Colleagues,

Below are some comments on the latest draft H.245, ordered by page number,
not importance:

- (Page 8) Should we add some clarification about extension to the
description of the Capability Exchange?  Here is some text that could be
added to the end of the first paragraph:
"When a capability is received which contains extensions not understood by
the terminal, the capability shall be accepted as if it did not contain the
What do people think?

- (Page 29) Since we are importing elements from H.235 that are required to
compile the syntax, should we not put the IMPORTS statement at the
beginning of the syntax? Or at least at the beginning of the Encryption
section?  This is not a big issue, but it is kind of buried in the syntax
and an implementor needs to know that the imported types are required to
build a correct implementation.

- (Page 39 and 92) Should there be "cause" codes in the
OpenLogicalChannelReject message for bad "encryptionSync",
"transportCapability" and "redundancyEncoding"?  It seems that there should
be more information about why the channel is being rejected.

- (Page 88, 3rd paragraph, 3rd sentence) "logical channel" should be
capitalized to "Logical channel" because it starts the sentence.

- (Page 91) In the text concerning "FlowControlToZero", it indicates that
the transmitter should not transmit on a logical channel until receiving a
subsequent "FlowControlToZero" message.  However, this message is only
contained in the OpenLogicalChannelAck.  Shouldn't this be a subsequent
"FlowControl" command?

- (Pages 96 and 43) In the text concerning ModeElement, it refers to an
element called "EncryptedMode"; however, in the ASN.1 syntax there is only
an element called "h235Mode".  I think the text needs to be changed to say

- (Page 113) RequestForFloor is described twice, the first one should be

- (Page 237) In Appendix IV, regarding the extension procedure, should we
add some text clarifying the capability issue?  Here is some proposed text
that could be added to the fourth paragraph:
"Specifically, when an H.245 Capability is extended, the extension shall
not change the meaning of the original capability in such a way that a
terminal which does not understand the extension would need to modify its
operation to use the capability without the extension."
What to people think?

Corey Gates
corey at
Tel: +1.408.567.7214
Fax: +1.408.988.7077

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.


To: ITU-SG16 at
Subject:      Re: New draft of H.245
From: Corey Gates <Corey_Gates/FVC/US at FVC.COM>
Sender: Mailing list for parties associated with ITU-T Study Group 16
              <ITU-SG16 at>
Reply-To: Mailing list for parties associated with ITU-T Study Group 16
              <ITU-SG16 at>
Date:         Mon, 22 Sep 1997 14:04:18 -0700
Message-ID:  <8825651A.006D6EC4.00 at>
Content-type: text/plain; charset=US-ASCII
Mime-Version: 1.0
X-Lotus-FromDomain: FVC
Received: by SMTP MTA v1.1 (385.6 5-6-1997))  id
          8825651A.00732324 ; Mon, 22 Sep 1997 13:57:36 -0700
Received: from ( []) by
          (8.8.6/8.8.5) with SMTP id NAA00228 for
          <ITU-SG16 at>; Mon, 22 Sep 1997 13:58:06 -0700 (PDT)

          1.8c) with spool id 138051 for ITU-SG16 at MAILBAG.INTEL.COM; Mon, 22
          Sep 1997 14:08:08 -0700
Received: from ( [])
     by (8.8.6/8.8.5) with ESMTP id OAA00431;
     Mon, 22 Sep 1997 14:08:11 -0700 (PDT)
Received: from ( []) by re (8.7.6/8.7.3) with ESMTP id OAA20252; Mon, 22 Sep 1997 14:07:20
 -0700 (PDT)
Return-Path: ITU-SG16 at

More information about the sg16-avd mailing list