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
