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