Proposed Corrections to Phase B (for Implementors Guide)

[Dave Walker]

I would like to hear people's opinion on whether we should
modify the requirements of Call Signalling Procedures Phase B
(section 8.2 of H.323v2).  In particular, I want to remove the
requirements that Terminal Capability Set be the first message
sent on the H.245 Control Channel, and the requirements that
terminal capability exchange and Master-Slave determination
complete before anything else is permitted on the control
channel (this requirement may only be implied).  I think that
it was probably only due to oversight that these changes
weren't included in version 2 when other text was approved
which necessitated less stringent requirements.  So my proposal
is that these changes be captured in the Implementors Guide and
then rolled into H.323 version 3.

To show the proposed changes to the text in ASCII, I'll bracket
text to be inserted like this:  <ADD>new text to be inserted</ADD>
and text to be removed like this:  <DEL>existing text to be
removed</DEL>.

The first paragraph of 8.2 requires that an H.245 Control
Channel be established once the Phase A call signalling
exchange is completed.  This requirement should not always
apply, for example, where Fast Connect has been used.  So the
proposed change is:

  Once both sides have exchanged call set-up messages from
  Phase A, the endpoints shall<ADD>, if required,</ADD>
  establish the H.245 Control Channel. The procedures of
  Recommendation H.245 are used over the H.245 Control Channel
  for the capability exchange and to open the media channels.

Paragraph 3 requires that the first H.245 message sent shall be
the terminalCapabilitySet.  This is not always necessary or
desireable.  For example,

  - The Fast Connect procedure was used, and now I simply want
    to send a UserInputIndication through the available but as
    yet unused H.245 tunnel (TerminalCapabilitySet and Master-
    Slave Determination messages haven't been sent yet).
    At least partial support for UserInputIndication is mandatory,
    so I shouldn't have to go through full capability exchange and
    Master-Slave Determination just to send a keypress.
    Section 8.2 does not actually require that TCS procedures
    *complete* prior to the next H.245 message being sent (so a
    userInputIndication could be sent in another message
    immediately after sending the message containing the TCS).
    But section 8.1.7.2 states that where Fast Connect has been
    used, "When H.245 procedures are activated, all mandatory
    procedures of H.245 that normally occur upon initiation of an
    H.245 connection shall be completed prior to initiation of any
    additional H.245 procedures".  This implies (by the requirements
    of 8.2) TCS exchange and Master-Slave Determination.
    Regardless, at least two TCP messages are required to get the
    UserInputIndication sent.
  - In the white paper for H.323 Annex F, H.245 tunnelling support
    is mandatory (at least for transmission of UserInputInd, and
    possibly other reasons such as "conference-awareness"), yet a
    SUD may only send an empty TCS.  But reception of an empty TCS
    at the peer has the effect of resetting H.245 state, and
    probably closing media channels.
  - Both endpoints have a priori knowledge of each other's
    capabilities, obviating the need for successful completion of
    the terminal capability exchange procedure prior to performing
    other H.245 operations.

So the proposed change is:

  Endpoint system capabilities are exchanged by transmission of the
  H.245 terminalCapabilitySet message. This capability message <DEL>
  shall</DEL><ADD>should</ADD> be the first H.245 message sent.<ADD>
  If, prior to successful completion of terminal capability exchange,
  any other H.245 procedure fails, is rejected, is not understood, or
  not supported, and the reason for such an outcome is the incomplete
  nature of the capabilities exchange, then before retrying the
  procedure the terminal capability exchange should be performed as
  specified in Recommendation H.245.</ADD>

There are a couple of minor associated changes that I will list at the
bottom.

The fourth paragraph contains a requirement that Master-Slave
determination take place.  Master-Slave Determination is used for a
variety of purposes, such as to choose MC for a conference, for
determining a master for resolving conflicting requests such as may
arise in opening bi-directional channels, and for assigning sessionIds.
Endpoints exist which will use only well-known sessionIds, will never
issue a potentially conflicting request and which will not act as an MC.
Therefore the proposal is to change the text as follows:

  <ADD>Except as otherwise allowed by this clause, the</ADD><DEL>The
  </DEL>master-slave determination procedure of H.245 shall take place
  as described in 6.2.8.4. In cases where both endpoints in a call
  have MC capability, the master-slave determination is used for
  determining which MC will be the active MC for the conference. The
  active MC may then send the mcLocationIndication message. The
  procedure also provides master-slave determination for opening
  bidirectional channels for data.<ADD> An endpoint which will not
  act as an MC and which will not require a master entity on the
  call may choose not to initiate the master-slave determination
  procedure, however if that procedure is initiated by a peer
  endpoint, the procedure must be supported as described in
  Recommendation H.245.</ADD>

The proposed changes to capability exchange and master-slave
determination requirements also affect the final paragraph of
section 8.2, which should be changed as so:

  Following <DEL>this exchange of capabilities</DEL><ADD>successful
  completion of the requirements of Phase B</ADD>, the endpoints
  shall proceed directly to the desired operating mode, <DEL>i.e.
  </DEL><ADD>normally</ADD> Phase C.

In addition to redundantly requiring exchange of capabilities and
master-slave determination, Phase C of the H.323 Call Signalling
procedures currently implies that these procedures must be followed
by opening logical channels.  There exist circumstances where there
is no need to open logical channels at this time, so that the first
paragraph of section 8.3 should be clarified to read:

  <DEL>Following the exchange of capabilities and master-slave
  determination, the procedures of Recommendation H.245 shall then
  be used to open logical channels for the various information streams.
  </DEL><ADD>Following the opening of the H.245 Control Channel in
  Phase B, only the procedures of Recommendation H.245 shall be used
  to open logical channels for the various information streams.</ADD>
  The audio and video streams, which are transmitted in the logical
  channels set-up in H.245, are transported over dynamic TSAP
  Identifiers using an unreliable protocol (see Recommendation
  H.225.0). Data communications which is transmitted in the logical
  channels set-up in H.245, are transported using a reliable protocol
  (see Recommendation H.225.0).

Regards,

Dave Walker
Mitel Corporation
Ontario, CANADA