Call Termination (Q104)

The information in this article applies to:

Since H.323 has historically not extremely clear about how to terminate a call under various conditions, I've combed the text and put together the following description. The conditions I have identified are

the control channel (H.245) is open,
the control channel is not open,
a protocol error has occurred on the control channel;
a protocol error has occurred on the call-signaling channel ("Q.931"), the control channel is open, and the EP decides to terminate the call; and
a protocol error has occurred on the call-signaling channel, the control channel is not open, and the EP decides to terminate the call.

Conditions 1 through 3 are further broken down into conditions a and b. Condition a is where the call-signaling channel is open; b, where it is not open (GK closed it).

1a. This is how H.323 says a call shall be terminated if the control and call-signaling channels are open and the endpoint wishes to follow the Procedure B as defined in H.323 section 8.5. Note that both sides are required to send endSessionComand and ReleaseComplete.

RAS Message	EP	Control or Call-signaling Message	Remote EP	RAS Message
	EP may close outgoing channels with CLCs before sending endSessionCommand.		Remote EP may not infer anything about having its incoming channels close.
		--> endSessionCommand
	EP waits for incoming endSessionCommand. In the mean time, it handles any CLCs, among other control messages, sent from the remote.		Upon receipt of endSessionCommand, remote EP may close its outgoing channels with CLCs before sending its endSessionCommand.
		<-- endSessionCommand
	EP closes control channel. H.245 session but not the call is now terminated.		Remote EP closes control channel. H.245 session but not the call is now terminated.
		<-- ReleaseComplete	Remote EP sends this immediately after sending endSessionCommand. It does not wait for incoming ReleaseComplete.
			Remote EP closes call-signaling channel. From the EP's perspective, the call is now terminated.
			If registered, remote EP disengages from call.	--> DRQ
				<-- DCF
	EP sends this upon receipt of endSessionCommand. If remote EP already closed socket, the EP may not be able to send it.	--> ReleaseComplete	Remote EP may or may not receive this depending on how quickly it closed the call-signaling channel.
	EP closes call-signaling channel. From the EP's perspective, the call is now terminated.
<-- DRQ	If EP is registered, it disengages from call.
--> DCF

1b. This is how a call shall be terminated if the control channel is open but the call-signaling channel is not open (GK closed it). Note that both sides are required to send endSessionComand.

RAS Message	EP	Control or Call-signaling Message	Remote EP	RAS Message
	EP may close outgoing channels with CLCs before sending endSessionCommand.		Remote EP may not infer anything about having its incoming channels close.
		--> endSessionCommand
	EP waits for incoming endSessionCommand. In the mean time, it handles any CLCs, among other control messages, sent from the remote.		Upon receipt of endSessionCommand, remote EP may close its outgoing channels with CLCs before sending its endSessionCommand.
		<-- endSessionCommand
	EP closes control channel. H.245 session and call are now terminated.		Remote EP closes control channel. H.245 session and call are now terminated.
<-- DRQ	EP disengages from call.		Remote EP disengages from call.	--> DRQ
--> DCF				<-- DCF

2a. The following is how a call shall be terminated if the control channel is not open (Fast Connect was used and no control channel was ever established) but the call-signaling channel is open OR if the endpoint wishes to follow Procedure A in Section 8.5 of H.323. Note that, in this case, only the initiating side is required to send ReleaseComplete. While not shown, if the control channel was opened, it is simply closed with transmitting any message. Since one endpoint may intend to follow Procedure A and the other may want to follow Procedure B, both endpoints shall be prepared to follow both procedures. (For example, one side might send an EndSession, as it intends to follow Procedure B, and the other side may send a Release Complete, as it wants to follow Procedure B.) If one side does lead with call termination, the other side should follow the selected procedure. However, the reason that H.323 does not speak to this explicitly is that in reality, users may just "hang up" at about the same time, so it's impossible to determine, in every case, which side initiated the call teardown procedures. Thus, endpoints must be flexible in this regard.

RAS Message	EP	Control or Call-signaling Message	Remote EP	RAS Message
		--> ReleaseComplete	Upon receipt of ReleaseComplete, remote EP closes call-signaling channel. From remote EP perspective, the call is now terminated.
	EP closes call-signaling channel. From EP perspective, the call is now terminated.		If remote EP is registered, it disengages from call.	--> DRQ
<-- DRQ	If EP is registered, it disengages from call.			<-- DCF
--> DCF

2b. If the control channel is not open (Fast Connect was used and no control channel was ever established) and the call-signaling channel is also not open (GK closed it) the (registered) EP simply terminates the call by notifying the GK that it has disengaged from the call.

For this to work, both EPs must be registered with the same GK, and the GK must be able to propagate the call termination to the remote EP, e.g., disengaging the call with a DRQ/DCF exchange or, if the remote's control and/or call-signaling channels are open, using the other methods described here.

This is how it would work if both EPs were registered with the same GK but neither EP had H.245 or call-signaling channels. The GK would know that there was no signaling between the EPs. Therefore, when it receives a DRQ from one EP, it knows that it must terminate the call on the other side by sending DRQ to the other EP. This ought to work, but I frankly doubt whether the call would even proceed this far because most EPs would assume the call was terminated when the GK closed the call-signaling channel. They shouldn't, but this is obscure enough that I'm sure few EP vendors have taken it into account.

RAS Message	EP	Remote EP	RAS Message
<-- DRQ	EP disengages from call.
--> DCF		GK disengages remote EP from call.	<-- DRQ

			--> DCF

3a. The following is how an EP shall terminate a call upon detecting a protocol failure on the control channel, e.g., the sockets layer returns an error for the control-channel socket, if the call-signaling channel is open. The Phase E procedure shall be followed; however, since the control channel is no longer functional, I have removed all use of that channel. Note that both sides send ReleaseComplete.

RAS Message	EP	Control or Call-signaling Message	Remote EP	RAS Message
		--> ReleaseComplete
	EP closes call-signaling channel. From EP perspective, the call is now terminated.
<-- DRQ	If EP is registered, it disengages from call.
--> DCF
	EP may or may not receive this depending on how quickly it closed the call-signaling channel.	<-- ReleaseComplete	Remote EP sends this upon receipt of ReleaseComplete. If EP already closed socket, the remote EP may not be able to send it.
			Remote EP closes call-signaling channel. From remote EP perspective, the call is now terminated.
			If remote EP is registered, it disengages from call.	--> DRQ
				<-- DCF

3b. If an EP detects a protocol failure on the control channel, e.g., the sockets layer returns an error for the control-channel socket, and the call-signaling channel is not open (GK closed it) the (registered) EP simply terminates the call by notifying the GK that it has disengaged from the call. I assume that the GK has some way of propagating the call termination to the remote EP, e.g., disengaging the call with a DRQ/DCF exchange or, if the remote's control and/or call-signaling channels are open, using the other methods described here.

RAS Message	EP	Remote EP	RAS Message
<-- DRQ	EP disengages from call.
--> DCF		GK disengages remote EP from call.	<-- DRQ
			--> DCF

4. If an EP detects a protocol failure on the call-signaling channel, e.g., the sockets layer returns an error for the call-signaling-channel socket, it may either terminate the call or attempt to re-establish the call-signaling channel. The following is how an EP shall terminate a call upon detecting a protocol failure on the call-signaling channel if the control channel is open. The Phase E procedure shall be followed; however, since the call-signaling channel is no longer functional, I have removed all use of that channel. Note that both sides send endSessionCommand.

RAS Message	EP	Control or Call-signaling Message	Remote EP	RAS Message
	EP may close outgoing channels with CLCs before sending endSessionCommand.		Remote EP may not infer anything about having its incoming channels close.
		--> endSessionCommand
	EP waits for incoming endSessionCommand. In the mean time, it handles any CLCs, among other control messages, sent from the remote.		Upon receipt of endSessionCommand, remote EP may close its outgoing channels with CLCs before sending its endSessionCommand.
		<-- endSessionCommand
	EP closes control channel. H.245 session and call are now terminated.		Remote EP closes control channel. H.245 session and call are now terminated.
<-- DRQ	EP disengages from call.		Remote EP disengages from call.	--> DRQ
--> DCF				<-- DCF

5. It also follows that if an EP detects a protocol failure on the call-signaling channel but the control channel is not open (Fast Connect was used and no control channel was ever established), it may either

A. deem the call terminated (no further communication between the EPs is possible) and perform the following:

RAS Message	EP	Remote EP	RAS Message
<-- DRQ	If EP registered, it disengages from call.
--> DCF		If remote EP registered, it disengages from call.	--> DRQ
			<-- DCF

or,

B. attempt to re-establish the call-signaling channel and continue the call.

Here are the relevant passages from H.323:

Section 3.19/H.323v3: "H.245 session: The part of the call that begins with the establishment of an H.245 Control Channel, and ends with the receipt of the H.245 EndSessionCommand or termination due to failure. Not to be confused with a call, which is delineated by the H.225.0 Setup and Release Complete messages."

Section 7.3.1/H.323v3: "For the Gatekeeper Routed method, the Gatekeeper may choose to close the Call Signalling Channel after the call setup is completed [...]. Only the Gatekeeper shall close the Call Signalling Channel [...]. If the Gatekeeper closes the Call Signalling Channel then the present state of the call shall be retained by the entities involved."

Section 8.1.7.3/H.323v3: "Terminating a call - If a call connected using the Fast Connect procedure continues to completion without initiation of H.245 procedures, then the call may be terminated by either endpoint sending a Q.931 Release Complete message. If H.245 procedures are initiated during the call, then the call is terminated as described in 8.5. If a separate H.245 connection has not been established and the Q.931 Call Signalling Channel is terminated, the call shall also be terminated."

Section 8.5/H.323v3: "Either endpoint may terminate a call by the following procedure: [...]
4) It shall transmit the H.245 endSessionCommand message in the H.245 Control Channel, indicating to the far end that it wishes to disconnect the call and then discontinue H.245 message transmission.
5) It shall then wait to receive the endSessionCommand message from the other endpoint and then shall close the H.245 Control Channel.
6) If the Call Signalling Channel is open, a Release Complete message shall be sent and the channel closed.
[...]
An endpoint receiving endSessionCommand without first having transmitted it shall carry out steps 1) to 7) above, except that in step 5), it shall not wait for the endSessionCommand from the first endpoint."

Section 8.5.2/H.323v3: "In networks that contain a Gatekeeper, the Gatekeeper needs to know about the release of bandwidth. After performing steps 1) to 6) above, each endpoint shall transmit an H.225.0 Disengage Request (DRQ) message (3) to its Gatekeeper. The Gatekeeper shall respond with a Disengage Confirm (DCF) message (4)."

Section 8.6/H.323v3: "Protocol failure handling - The underlying reliable protocol of the H.245 Control Channel uses appropriate effort to deliver or receive data on the channel before reporting a protocol failure. Therefore, if a protocol failure is reported on the channel, the H.245 Control Channel, and all associated logical channels shall be closed. This shall be done following the procedures of Phase E, as if the other endpoint had issued the H.245 endSessionCommand. This includes transmission of the DRQ message to the Gatekeeper and termination of the Call Signalling Channel."

Section 8.6/H.323v3: "The Call Signalling Channel also uses an underlying reliable protocol. Depending on the routing of the Call Signalling Channel, either the Gatekeeper or an endpoint may detect the protocol failure. If the Gatekeeper detects the failure, it shall attempt to re-establish the Call Control Channel. This implies that the endpoint shall always have the ability to establish a channel on its Call Signalling Channel Transport Address. Failure of the Call Signalling channel shall not change the Q.931 call state. After re-establishment of the Call Signalling Channel, the Gatekeeper may send a Status message to request the call state of the endpoint to assure that they are in synchronization. If the endpoint detects the failure, the endpoint may choose to terminate the call as described in Phase E, or it may attempt to re-establish the Call Signalling Channel as described above."