1.2. Basic Concepts
1.2.1. Control Channel
After the termination of call signalling procedures, all information exchanged between two terminals is sent in so-called logical channels. Logical channel is defined in quite an abstract way in the [2] as "Channel used to carry the information streams between two H.323 endpoints. (...) There is no relationship between a logical channel and a physical channel." It is because ITU-T Rec. H.323 determines neither transmission nor network protocol for data exchange. In TCP/IP networks logical channel is a UDP-UDP relationship or a TCP session. Generally, audio and video streams use unreliable protocols (UDP), and data and control streams use reliable protocols (TCP). The control channel is a reliable logical channel used to exchange H.245 control information. There is exactly one control channel between two endpoints. The control channel is bi-directional and is established as the first logical channel in a given session. A regular protocol for opening logical channels does not apply in the case of the control channel. The TCP ports that are used by the control channel are assigned dynamically by both terminals (they are not well-known ports). The called terminal sends a message to the calling one. The message contains, as one of its parameters, the number of a TCP port assigned by the called terminal to the control channel. This number is then used to create a TCP connection by the calling terminal. The details of establishing the channel are described in [5] and [2] and are beyond the scope of this work. All other logical channels in a given session are controlled (opened and closed) using the control channel.
The simple introduction to H.323-related protocols can be found in [8].
1.2.2. Messages and Procedures
Information is transmitted in the control channel in chunks called messages. All the messages are defined in an ASN.1 form (refer [3], [4] for details). According to ASN.1, messages are defined by the root of the H.245 logical tree called "Multimedia System Control Message". Every message is defined by a specific node in this tree. The subnodes of a message's node are called message's parameters in this work. Some messages may have many complex parameters. If a message is about to be transmitted, it must be transformed from its logical tree into a bit-stream representation (In the H.323 terminal shown in Figure 1-1 this task is accomplished by the C3 module.
There are four types of messages: requests, responses, commands and indications. A command is a message that makes the other terminal do something; it does not require any response from the other end. An Indication is a message that just informs the other end about the current state of the terminal. It does not require any response or action. A Request is a command that requires a response. A response is just an answer to a request. There are about fifty messages defined in ITU-T Rec. H.245 (refer [1] for details).
Most H.245 messages can be assigned to a procedure. For instance, messages called OpenLogicalChannel, OpenLogicalChannelReject, OpenLogicalChannelAcknowledge, CloseLogicalChannel form the set of messages used by the procedure for opening and closing logical channel messages. They are described more thoroughly in Section 1.2.3 and Section 1.3.
The other messages do not belong to any procedure. They may be used separately. The examples include the FunctionNotUnderstood indication (sent if message was not understood), and FunctionNotSupported indication in case of an unsupported message . Another message of this type is SendTerminalCapabilitySet command. Once it is received, the terminal must start capability exchange procedures (share its capabilities with the remote terminal). A session between two terminals is closed as a result of the EndSession command. No other messages can be sent after this command; the control channel is closed. There are many more similar commands and indications defined in [1]. The messages that are mandatory in the H.323 terminal are described in Chapter 2.
1.2.3. H.245 Signalling Entities
The request/response messages cannot be used randomly in H.245 protocol. The special sequence of those messages is defined. The algorithms how these messages are used are grouped in special procedures. These procedures are usually quite complex and must take care of timers, protocol errors, non-standard responses, a lack of responses, etc. They cover variety of situations. The H.245 procedures have one more important capability: multiple procedures can work simultaneously. For example, there can be proceeded two or more opening channels negotiations in the same time without interfering each other. To allow that, several "signalling entities" are present in every terminal, which uses the control channel as specified in ITU-T Rec. H.245. A signalling entity defines algorithms of most of the control channel procedures.
Figure 1-2 illustrates the H.245 entity system. SE is a signalling entity. User is a module that an entity communicates with. Every entity has a single user assigned to it. And every user has one entity under its control. In the case described here, multiple entities may not be assigned to one user (to allow that entity identifiers must be introduced; but this is an implementation problem).
Every entity and its user have their equivalent at the other side (remote terminal). It is the same type entity. An entity initiating a procedure will be called the local entity. The user of the local entity will be called the local user. The peers will be called the remote entity and the remote user, respectively. The local entity and local user are shown in figures on the left hand side. The ITU-T Rec. H.245 describes algorithms, data structures, messages and interface for any signalling entity. This behaviour of every entity is called a procedure is this work.
Signalling entity is a description of algorithms and variables (like a class in object-oriented programming). Consequently, to make it work, instances of signalling entities are needed. An instance is a separate object, which can be created and destroyed (like an object in OOP). Some signalling entities may have multiple instances; some of them have exactly one. The number of instances and the moments of their creation (and destruction) are explained in Section 1.3.
The terms "signalling entity" and "instance of signalling entity" are used interchangeably below (while it causes no ambiguity).
Any signalling entity must communicate with its peer using messages and with its user using so-called primitives. The user dispatches commissions to its entity in the form of primitives and this makes the entity start required actions (send, receive and analyze messages). The entity answers the user in the form of primitives, too. ITU-T Rec. H.245 does not define the form of primitives, just their meaning. The primitives contain parameters. These parameters correspond directly to message parameters. For example, while opening a new logical channel, the primitive ESTABLISH.request must be passed by the user to the entity responsible for opening logical channels. This primitive contains a parameter (FORWARD_PARAM) that describes properties of the desired logical channel (especially encoding algorithms). Then a corresponding message (OpenLogicalChannel) is prepared by the entity. The message includes a parameter that conveys exactly the same information as FORWARD_PARAM. Then the message is encoded and sent to the peer.
Figure 1-3 shows how signalling entities and their users communicate. RTDSE and LCSE are names of certain entities, they are described later. Primitives are exchanged between entities and users. This communication may be also treated as a direct communication between the users (the local user with the remote user), like in the case of the other stack layers. Messages are sent from an entity to its peer over the control channel.
All the entities share one control channel but messages are always delivered to the proper entity.
There are four types of primitives: a request, a response, an indication and a confirmation (abbreviated in the [1] as confirm). They are named using the following rule: "Primitive Task"."Primitive Type", e.g., ESTABLISH.request, ESTABLISH.response, TRANSFER.confirm, etc. A request primitive is passed to a signalling entity to initiate a procedure (e.g., ESTABLISH.request starts an opening logical channel procedure); an indication primitive is passed from the remote entity to the remote user after receiving the first message of the procedure from the local entity. It indicates to the remote user that the procedure was initiated. Usually, once an indication primitive is passed to the remote user, the remote entity starts waiting for the reply from the user (e.g., ESTABLISH.indication primitive asks the remote user whether or not to open a logical channel). If the remote user agrees, it passes a response primitive to the remote entity (e.g., ESTABLISH.response). Confirm primitives are generally passed from the local entity to the local user. They signal that the given procedure has finished successfully (the only exception to this rule is described in Section 1.3.2).
There are two types of signalling entities: outgoing and incoming. An outgoing entity is located at the calling side (the side that starts a procedure). An incoming entity is located at the called side. In this work a calling entity is named also a local entity, a called entity is named a remote entity. For instance, if the local terminal is going to open a logical channel, the local user responsible for opening the channel, passes the ESTABLISH.request primitive to the outgoing logical channel signalling entity. Next, the message OpenLogicalChannel is sent over the control channel to the incoming signalling entity. The outgoing and incoming entities of a procedure operate differently and are described in details in [1].
Some of the signalling entities work as both: outgoing and incoming. In that case the calling and the called side operate the same way.
What is inside a signalling entity? Signalling entities are described as state machines. Receiving a primitive, a message or a timer expiry can change the state of a signalling entity. A state change involves performing some activities. The most common state of almost all the entities is the IDLE state (the state of inactivity). Protocol errors and unsupported functions are handled from outside the entities. Messages not understood are ignored. No user is informed about such a message, and no entity changes its state. If an entity receives a message not appropriate to its state, it must be handled appropriately (e.g., receiving a response message without any previous request message does not change the state of the entity). An entity must be ready for such situations. They cannot make the entity work in an unpredictable way. Most entities are equipped with timers. All timeout errors are passed to the user by the entity in a form of a primitive. After sending a message to the peer, a timer is set. Thus, the entity is prepared for lack of a response; it will be reactivated after some time (usually 5 seconds). Additionally, entities are responsible for supporting counters. If certain activities fail a number of times, they are abandoned. This feature saves an entity from infinite loops.
The following entities have been defined in ITU-T Rec. H.245: Master Slave Determination Signalling Entity (MSDSE), Capabilities Exchange Signalling Entity (CESE), Uni-directional Logical Channel Signalling Entity (LCSE), Bi-directional Logical Channel Signalling Entity (B-LCSE), Close Logical Channel Signalling Entity (CLCSE), H.223 Multiplex Table Signalling Entity (MTSE), Request Multiplex Table Signalling Entity (RMESE), Mode Request Signalling Entity (MRSE), Round Trip Delay Signalling Entity (RTDSE), Maintenance Loop Signalling Entity (MLSE).