1.3. Description of Entities
This section describes the desired scenarios of procedures performed by entities required by H.323. "Desired" means that they are performed under prosperous circumstances (the remote terminal responds positively to all requests, no timeouts or protocol errors occur, etc.). Diagrams (based on those in [1]) are drawn to illustrate the scenarios. The diagrams use the notation presented in Figure 1-4.
Every signalling entity is described with a great emphasis on its interface (communication with the user). All possible primitives are enumerated and the user responsibility is described. Additionally, the parameters of the primitives are thoroughly analyzed.
The entities are introduced in the order they are used in audio-only H.323 terminal. The signalling entities that are not present in H.323 terminal (MTSE, RMESE) and the entities that may be used just for rejecting an every request (MLSE, B-LCSE) are not introduced here.
1.3.1. Capability Exchange Signalling Entity
This procedure is used to exchange terminal's capabilities, especially the protocol version and supported codecs.
To understand the essence of this entity the way of storing terminal capabilities must be introduced. There are three types of capabilities: transmit, receive and "transmit and receive" capabilities. Transmit and receive capabilities are separated - they do not interfere. If the "transmit and receive" capabilities are present, that means that the terminal has some dependencies between transmit and receive logical channels. For instance, it can either transmit or receive video streams but never do both at the same time.
Transmit or receive capabilities may be absent in primitive parameters (and consequently in message parameters). Omitting the receive parameters implies that the terminal cannot receive any multimedia signals. If the transmit capabilities are omitted, the terminal may still be a transmitter but does not offer any preferred modes (e.g., for the MRSE purposes, described later).
The data structures described below are identical for transmit, receive and "transmit and receive" capabilities. In this case it is supposed that these are receive capabilities.
All the audio/video/data/encryption capabilities are enumerated in a table called a capability table. Every item in this table has two fields - a capability number and a capability name: ( NUMBER, CAPABILITY ). This table may be treated as a space of basic capabilities. For example, {(1, G.711), (2, G.722), (3, H.261)} would be a valid capability table. A subset of this space called an alternative capability set. Its meaning is that every capability from the subset may be used alternatively (exactly one from the set may be used at any given time). For instance, for the previously defined capability table the following alternative capability set may be defined among others: {1, 2, 3} (any of the codecs from the capability table can be used) and {1, 2} (just G.711 and G.722 can be used). A family of alterative capability sets is called a simultaneous capability table. Let T={{1,3}, {2,3}}. This simultaneous capability table (T) consists of two sets A={1, 3} and B={2, 3}. It describes what codec combinations can be used. To find out the combinations, the Cartesian product of the sets in T must be calculated. In this case AxB={{1,2}, {1,3}, {3,2}, {3,3}}. A set of simultaneous capability tables is called simultaneous descriptors. And this is the parameter describing capabilities of the terminal.
Notice that the CESE procedures must precede all other procedures in the control channel.
Figure 1-5 shows an exchange of messages and primitives for the CESE procedure. They are started when the local user passes the TRANSFER.request primitive to the local entity. This request includes four parameters: identifier of the used H.245 protocol used (ID), a multiplex capability table (MC) (not used in H.323 terminals), a capability table (CT) and capability descriptors (CD). They may contain transmit and receive capabilities for any media types. Once the primitive is passed to the local entity, the TerminalCapabilitySet message is sent to the remote entity. This message contains all parameters passed in the TRANSFER.request primitive. The remote entity receives the message and passes the TRANSFER.indication primitive to the remote user. The primitive contains all the parameters acquired from the message. The remote user responds using the TRANSFER.response primitive. Next, the remote entity sends the TerminalCapabilitySetAck message to the local entity. When the local entity gets this message, the TRANSFER.confirm primitive is passed to the local user.
Instances: There are two pairs of instances for every call. During a normal session (two terminals are involved) a terminal has only one instance of incoming CESE and one instance of outgoing CESE.
Other primitives: REJECT.request(CAUSE) primitive can be the answer of the remote user to the TRANSFER.indication primitive. CAUSE must be filled with the cause of rejection. The local user gets the REJECT.indication(CAUSE) primitive instead of the TRANSFER.confirm one.
Responsibility of the user: The local user must properly fill the parameters and then pass them to the entity. The remote user should store the received capabilities.
1.3.2. Master Slave Determination Signalling Entity
This procedure is used to designate one terminal as master, and the other as slave. The assignment is used by some other entities (e.g., LCSE, B-LCSE).
First, as illustrated in Figure 1-6 the local user passes the DETERMINE.request primitive to the local entity (no parameters). Then the entity sends the MasterSlaveDetermination message to the remote entity. This message contains two important parameters: the terminal type (TT) and the status determination number (SDNUM). TT is a number assigned to every terminal. This value is specified in the recommendations that refer to ITU-T Rec. H.245. Generally speaking, if an entity supports more features, the TT number is greater (e.g., a terminal with no MC has the TT number equal 60, a gatekeeper with no MP has TT number equal 120, while an MCU with data, audio and video has TT number equal 190). SDNUM is a 24-bit unsigned integer random number generated by the local entity. The remote entity receives the message and runs the determine_status function. The function first compares TT from the message with the local TT. The terminal with the bigger TT is picked as the master terminal. If both TT's are equal, two SDNUMs (received and local) are compared. The determine_startus function returns one of the following values: "master", "slave", and occasionally "undetermined" (when an unusual coincidence happens). The returned value is passed to the remote user in the DETERMINE.indication primitive and stored in the entity's local variable state. This primitive informs the user about the results of the master slave determination. Then, the MasterSlaveDeterminationAck message with the inverted state variable as its parameter is sent to the local terminal. A local variable state at the local entity is set, and the DETERMINE.confirm primitive is passed to the local user. Then the MasterSlaveDeterminationAck message is sent to the remote entity with the state value inverted again. The peer receives the message, and if the state local variable equals the message parameter state, the primitive DETERMINE.confirm is passed to the remote user. Now the user is informed that both the local and the peer side have resolved the issue successfully.
Instances: There is just one instance of this entity in every terminal. This instance shares outgoing and incoming features (calls and can be called).
Other primitives: the REJECT.indication primitive may be passed by the entity to the user if it acquired the MasterSlaveDeterminatonRelease message or the MasterSlaveDeterminatonReject message. These are caused by the simultaneous initiation of MSDSE procedures. The users can also get the ERROR.indication caused by undetermined result of the determine_startus function or by the timer expiry.
Responsibility of the user: The local user as well as the remote user must store the current status somewhere (master, slave, undetermined).
1.3.3. Uni-directional Logical Channel Signalling Entity
This procedure is used for opening and closing uni-directional (the commonest) logical channels.
Figure 1-7 illustrates how a logical channel is opened and closed. First, the local user passes the ESTABLISH.request(FP) primitive to the local entity. The primitive contains forward parameters (FP). FP is a very complex set of logical channel parameters. It contains the number of the channel to be opened, assigned arbitrarily by the transmitter. It contains a UDP port number for the media-carrying RTP logical channel that is being opened and a UDP port number for the reverse RTCP. Finally, FP contains the data type (e.g., audio), a codec used and, in case of some codecs, some additional parameters. These parameters correspond directly to parameters of the OpenLogicalChannel message, which is sent to the peer. The remote entity gets the message and passes the ESTABLISH.indication primitive based on the parameters from the message to the remote user. Then it the remote entity waits for an answer. If the remote user agrees to open such a logical channel, it passes the ESTABLISH.response primitive to the entity and that makes the entity send the OpenLogicalChannelAck message to the local entity. After receiving this message, the local entity passes the ESTABLISH.confirm primitive to the local user. The logical channel is now in ESTABLISHED state, and the transmission may begin.
To close the logical channel, the local user passes the RELEASE.request primitive to the local entity (no parameters). The transmission of data must be terminated before passing this primitive. The CloseLogicalChannel message is sent to the peer. The remote entity gets the message and immediately responses with the CloseLogicalChannelAck message, sending the RELEASE.indication primitive to the remote user at the same time. The local entity passes the RELEASE.confirm primitive to the local user. The logical channel is now closed.
Instances: There is the pair of instances for every opening channel procedure. The local entity uses the outgoing algorithms, and the remote entity - incoming algorithms. The number of instances varies from 0 to N (N is a number of logical channels). New instances are created with the ESTABLISH.request and should be killed after the associated logical channel is closed.
Other primitives: the RELEASE.request(CAUSE) primitive may be passed by the remote user to tell that it does not agree to open the logical channel. The CAUSE parameter must be set. The local user then receives the RELEASE.indication primitive. Another primitive is the ERROR.indication(ERRCODE) primitive meaning that the timer expiry or a protocol error has occurred.
Responsibility of the user: In case of this entity the local user must be aware of many factors; also it must perform some actions before starting the LCSE procedure. First, the user must select a proper codec. Second, the user must check in the capability table (received from the remote peer as a result of the CESE procedure) whether the remote terminal supports the chosen codec. Third, the user must check if this codec can work simultaneously with the already opened logical channels (looking up the simultaneous capability tables). Next, the user must check whether bandwidth (allocated by a gatekeeper and received from RAS) is not exceeding due to using the new logical channel. Then a UDP socket (if opening a video or audio channel) for further media exchange (RTP) and a UDP socket (for the RTCP protocol) must be opened. RTCP is not present in all types of logical channels; sometimes this parameter may be suppressed. Next, proper forward parameters (FP) must be formed. For some sets of codecs, special parameters must be added (e.g., a dynamic payload type for RTP purposes or a silence suppression flag).
Once the ESTABLISH.indication primitive is received by the remote user it checks whether it can open an additional logical channel with the given parameters. If positive, it opens two UPD sockets: RTP and RTCP one. Next, the remote user must be ready to receive the media stream (must activate a media engine new threads or processes). Then the OpenLogicalChannelAcknowledge message may be sent to the local entity.
1.3.4. Close Logical Channel Signalling Entity
The following procedure is used to request the closing of logical channels by the receiver. Normally, the transmitter opens and closes its logical channels. But sometimes the receiver cannot process a media stream or no longer wants to receive it. In these cases the CLCSE procedure must be performed.
Figure 1-8 shows the CLCSE procedure. In this case the local entity is a receiver, the remote entity is a transmitter. First, as illustrated in the figure, the local user passes the CLOSE.request primitive to the local entity. Then, the entity sends the CloseLogicalChannel message to the peer (the message includes the number of the logical channel). The message is received by the peer (the remote entity) and the remote entity passes the CLOSE.indication primitive to the remote user. If the remote user agrees to the suggestion in the primitive, it passes the CLOSE.response primitive to the remote entity. The remote user is now obliged to start closing this logical channel (passing the RELEASE.request primitive of the LCSE procedure to the proper LCSE entity). Then the remote (incoming) entity sends the CloseLogicalChannelAck message to the peer. The local entity gets the message and passes the CLOSE.confirm primitive to the local user.
Instances: The Recommendation specifies that there is exactly one outgoing instance for every receiving logical channel and one incoming instance for every transmitting logical channel. Consequently, the number of the instances is equal to the number of all the opened logical channels. They are created once LCSE procedures are started, and destroyed once the associated logical channel is closed.
Other primitives: the REJECT.request(CAUSE) primitive may be passed by the remote user to the remote entity if it does not agree to close the logical channel. CAUSE parameter must be set. The local terminal receives the REJECT.indication(SOURCE, CAUSE) primitive in this case (the value of SOURCE is "USER"). The REJECT.indication primitive is passed to the local user after the timer expiry inside the local entity (SOURCE has the value "PROTOCOL" in this case).
Responsibility of the user: The local user has no special responsibilities. The remote user must start the closing part of the LCSE procedure after successful completion of the CLCSE procedure.
1.3.5. Mode Request Signalling Entity
These functions are used to initialize the opening of logical channel by the receiver. The receiver does not open the logical channel. It just sends a polite request to the transmitter to open a desired logical channel. Two entities are present in the time of running the procedures: incoming and outgoing (starts them). After a successful finishing of these procedures, the incoming peer must start the opening logical channel procedures. Notice that if there were no transmitting capabilities sent by the remote terminal while CESE procedures it means that the RMSE procedures must not be used.
First, as shows Figure 1-9, the TRANSFER.request primitive is passed to the local entity. The primitive carries the parameter called mode element (MODE-EL). This parameter contains the enumerated modes from the most preferred to the least preferred mode. The modes must conform to the capability table (received while CESE procedures). Then the entity sends RequestMode to the remote terminal. This makes the remote entity pass the TRANSFER.indication primitive to the remote user. If the remote user responses positively, it passes the TRANSFER.response primitive containing information whether the most proffered mode was chosen. Then, the remote entity sends preferred to the local entity. The local entity acquires the message and passes the TRANSFER.confirm primitive to the user.
Instances: There is the pair of instances for every call. The local entity uses the outgoing algorithms, and the remote entity - incoming algorithms. During an ordinary, two terminal session there is one instance of outgoing and one instance of incoming CESE.
Other primitives: the REJECT.request(CAUSE) primitive may be passed by the remote user to the remote entity if it does not agrees to open new logical channel. CAUSE parameter must be filled. The local terminal receives the REJECT.indication(SOURCE, CAUSE) primitive in this case (the value of SOURCE is "USER"). The REJECT.indication primitive is passed to the local user after the timer expiry error inside the local entity (SOURCE has the value "PROTOCOL" in this case).
Responsibility of the user: The local user must refer to the items in the capability table (CT) and in the capability descriptors (CD) set before starting these procedures. The remote user must store the chosen mode after its positive response to the entity. It must start LCSE procedures immediately after completion of the MRSE procedures using the stored mode.
1.3.6. Round Trip Delay Signalling Entity
Round Trip Delay is used to check the delay in the control channel. The delay is measured by the local entity as the time between sending a message and receiving the response for this message.
The procedures (refer Figure 1-10) are started by the TRANSFER.request primitive passed to the local entity. Then, the RoundTripDelay message is sent to the remote terminal and the timer is started. After getting this message, the remote entity answers immediately with the RoundTripDelayAck message. This message, when acquired by the local entity, stops the timer and makes the entity pass the TRANSFER.confirm primitive with the properly calculated delay as a parameter (DELAY).
Instances: Only one instance of RTDSE must be present all the time. It shares the incoming and outgoing capabilities.
Other primitives: EXPIRY.indication is passed to the local user when no response from the remote terminal was acquired in the given time.
Responsibility of the user: The local user should store the DELAY value after the positive completion of the procedures. The remote user is not informed about incoming RTDSE procedures.