Chapter 2. H.245 in H.323.
This paragraph describes all the H.245 features, which are mandatory in an H.323-compatible terminal. First, H.245 control channel is established immediately after successful procedures of H.225.0 Call Signalling. The essential information is exchanged during these procedures (e.g. the TCP port for the control channel). Second, every H.323 terminal must be able to parse all the H.245 messages (even if it does not support them). It is important to understand and response properly for such messages, more adequate than just Function Not Understood indication. Finally, the control channel (with an identifier 0 assigned to it) must be permanently open and usable until the entire session is finished.
As mentioned earlier, an H.323 terminal uses just a subset of all H.245 protocol features. ITU-T Rec. H.323 gives lists of signalling entities, which are present in terminals as well as messages, which must be understood by such endpoints. In this set of signalling entities there are entities, which have some messages forbidden or optional (i.e. endpoint does not have to support them). The required entities are: MSDSE, CESE, LCSE (some messages are optional), B-LCSE, CLCSE (some messages are optional), RMSE (some messages are optional), RTDSE (some messages are optional) and MLSE (almost all messages are optional). For details, refer [2], p. 19, p. 82 .
Bi-directional LCSE (B-LCSE) is not used in speech-only terminals to establish logical channels (because bi-directional channels are not present in such terminals). This entity uses the same set of messages as LCSE (with additional parameters). If a speech-only terminal acquires a request to open a new bi-directional channel, it should refuse.
Maintanance Loop Signalling Entity (MLSE) is required for every H.323 terminal but most messages and their parameters are optional or forbidden. System loops and logical channel loops are forbidden. Just media loops only are permitted though optional (consequently video or audio streams may be looped and than come back to the transmitter). The mandatory messages are: MaintenanceLoopOffCommand (turning off all the loops) at the receiving side and MaintenanceLoopReject at the transmitting side.
Every terminal must support the set of commands and indications (not assigned to any signalling entity). The commands that must be implemented at the transmitting and receiving sides are: SendTerminalCapabilitySet, used to make the peer start CESE procedures, and EndSession used to end the session between two terminals. There are several other commands that must be implemented at one of the sides are not described here (refer [2] p. 86). The mandatory indications are FunctionNotUnderstood and FunctionNotSupported and UserInput command. UserInput is a command that allows sending to the peer some characters as if they were typed on a keypad. The minimal set of character is 0-9, * and #.
A logical channel, opened using LCSE procedures, has an audio/video/data codec assigned to it. Every corresponding RTP stream has a payload type assigned to it (according to [6] and [7]). There must be a correlation between this payload type and the H.245 codec type.
Every H.245 protocol revision has a version number. [1] describes the version number 2 of the protocol. This protocol must be compatible with all preceding versions (in this case with version number 1).
Figure 2-1 shows the beginning of the H.245 session. The first messages sent into control channel are CESE messages. These give the remote terminal information about the local terminal capabilities. The H.245 protocol version is transmitted, and then all supported audio/video/ data capabilities are sent (in capability tables and capability descriptors). At the every moment in the particular session, terminals may sent the command Send Terminal Capability Set which makes remote terminal start CESE procedures and send all the interesting parameters. The figure shows that outgoing CESE procedures are run once per session. Incoming procedures (initiated by the remote terminal) are run also just once. Normally, there is no need to perform these procedures several times (the terminals have constant capabilities). But if the capabilities change in time (for example the user turns the video capabilities off to make up) the CESE procedures may be performed also in the other terminal states. So the terminal must be ready for such a situation.
Next procedures are MSDSE ones. It is a must to assign one terminal as a master terminal and the other as a slave terminal before the opening of logical channel if performed. Some conflicts may be met while establishing a logical channel. In such cases the master terminals gains some profits (the slave terminal must give up). The MSDSE procedures, if successful, should be performed just once, after the CESE procedures. Nevertheless, MSDSE entity is active all the time during the session. Every terminal must be able to work in master as well as slave modes.
In the moment the MSDSE results are known for both of the terminals (the DETERMINE.confirm primitive is received by the users) LCSE procedures may be started. The number of logical channels depends on the particular situation and is not defined by the Recommendation. Perhaps, it may be needed to start RMSE to open all desired logical channels. In the considered situation (illustrated in Figure 2-2 two logical channels are opened (supposedly they are audio channels): first is opened by the local terminal and the other by the remote terminal. No additional functions are needed in this case.
Once the transmitting logical channel is opened (it is in the ESTABLISHED state) the transmission may be started. In the figured case no additional primitives are sent, but the H.245 subsystem is still alive, and the regular procedures may be performed (e.g. CESE, RTDSE, LCSE, CLCSE, ..). The Recommendation requires from the terminal to handle all the messages in all states.
Occasionally, an H.323 terminal can use additional mechanisms to modify logical channels. This example illustrates the situation where a terminal decides to change the logical parameters, which are not adequate for the terminal. As shown in Figure 2-3 receiving logical channel is opened on the remote terminal's own initiative. The local terminal begins receiving the audio signal but it finds out that in cannot process the signal properly (e.g. too complex decoding rules for the local CPU). Consequently, the local terminal starts CLCSE procedures to request the closing the problematic logical channel. The remote terminal agrees to this request (CLOSE.confirm) and then starts releasing procedures (RELEASE.indication). Then, when the logical channel is eventually released, the local terminal decides to open a new logical channel (with all the parameters carefully selected) and start MRSE procedures (sending TRANSFER.request(ME) to the outgoing MRSE). The remote terminal agrees again with the local terminal's suggestion and starts LCSE procedures. This is the way to "change" logical channel's parameters.
If the terminal is going to terminate the connection is should stop all the media streams, and close all the transmitting logical channels. Then it sends EndSession messages to the terminal (represented here by END_SESSION primitive). In this moment the connection is closed, and control channel exists no longer. The Recommendation does not require from the terminal to close all the logical channels before sending EndSession, but just suggests it. Consequently, the "ugly" closing of connection procedure would include just sending of EndSession message.
