Back to System Manual Page

Q.931 module

Contents:

• Module splitting of Q.931
• Socket module
• DLPI module
• Receive module
• Call clearing module
• Call information module
• Miscellaneous module

Module splitting of Q.931

Messages that come from the network layer can be split into four groups. We have: call setup, call information, call clearing and miscellaneous. These groups form a basis for the splitting of Q.931 into modules. Besides of these four modules we need a couple more to make it complete. We need one module for communication between Q.931 and the user application, and one module that takes care of the communication between Q.931 and Q.921. The former is called the socket module and the latter the DLPI module. The names come from the way interfaces upwards and downwards are implemented. Here is the whole picture.


Picture:Q.931 modules.

Socket module

The socket module takes care of communication between Q.931 and the user application. Q.931 serves as a socket server that listens for incoming calls and the application serves as a client requesting services. The functions this module handles are as follows. First we must initialize the socket structure with the right kind of information. This includes hostnames, socket numbers, addresses and so on. After that, the socket must be created. It must then be bound to a certain service port. Thereafter it has to be prepared for incoming calls. After that we can wait for connections. Once a connection has been established, can we read data out of the socket. The socket module invokes the right module depending on what the user wants. This is how the module looks like. Basic funktions are also shown.


Picture:Q.931 socket module.

DLPI module

Call module

The call module is the one that invokes a call. Each module can be in different states depending on which part of the call is processed. At the beginning we usually start from the null state. In case of a call setup the following thing to do, is to send a primitive down to the data-link layer containing a SETUP. All data is sent with the DL_DATA.request primitives. After that we are in the call initiated state. When the network receives our SETUP, it sends us a CALL PROCEEDING message, and we can move to outgoing call proceeding state. When the phone rings at the other end, we receive an ALERT message. The next state to go to, is the call delivered state, which indicates that our call has reached the called party. After receiving a CONNECT message, the active state follows. In this state user information is being transferred. In case of errors and if we cannot get any answers, the call clearing module is called. The following picture shows the operation of the call module.


Picture:Q.931 call module.

This module sends and receives the following messages:

• SETUP
• CALL PROCEEDING
• ALERT
• CONNECT

And it can be in one of the following states:

• Null state
• Call initiated state
• Outgoing call proceeding state
• Call delivered state
• Active state

Receive module

The receive module is the one that takes care of an incoming call. The module also begins from from null state and is waiting for an incoming SETUP message. Once received, it moves to call present state. This state can notice that the B-channel requested in the setup message is not available. If this is the case is sends a RELEASE COMPLETE message and enters null state. Otherwise it sends CALL PROCEEDING to the network indicating the call has been accepted. The next state is the incoming call proceeding state. ALERT is sent to the network, and state transition to call received state occurs. Once the user picks up the handset or makes other possible actions, a CONNECT message is sent. Connect request is the next state. This state starts timer T313. Once CONNECT ACKNOWLEDGE has been received from the network, timer T313 is stopped and the module is in active state. The following picture shows the operation of the receive module.


Picture:Q.931 receive module.

This module sends and receives the following messages:

• SETUP
• CALL PROCEEDING
• ALERT
• CONNECT
• CONNECT ACKNOWLEDGE

And can be in one of the following states:

• Null state
• Call present state
• Incoming call proceeding state
• Call received state
• Connect request state
• Active state

Call clearing module

The call clearing module takes care of terminating the call. This can be done in three different ways. The two most common are when either the user or the network requests a termination. The third option is a faultsituation which leads to disconnection. When the user needs to disconnect, a DISCONNECT message is sent to the network. Disconnect request state is entered and timer T305 is started. The user disconnects the B-channel and waits for RELEASE message from the network. Note that disconnecting the B-channel doesn´t mean that it is ready for furher use. It needs also to be released in order to be available. If the user receives a RELEASE from the network it stops timer T305, releases the B-channel and sends RELEASE COMPLETE to the network. Thereafter it enters null state. If timer T305 expires, which means that the network has troubes in sending a REALEASE, timer T308 is started and a RELEASE message is sent to the network. Release request state is entered. If T308 expires once again, the B-channel is placed in maintainance condition and the call reference value is released, after which null state is entered. If RELEASE is received the procedure is the same as described above.
If a DISCONNECT is received from the network, the user shall disconnect the B-channel, start timer T308 and send a RELEASE message and thereafter enter the release request state. If the network sends a RELEASE COMPLETE message, timer T308 shall be stopped and both the B-channel and call reference number shall be released. Null state is entered. If timer T308 expires, the user shall send a RELEASE message to the network, restart T308 and enter release request state. If T308 expires once again, the B-channel shall be placed in maintainance condition and the call reference value shall be released. If RELEASE COMPLETE is received, T308 is stopped, B-channel and call reference value are released and null state is entered.
Here is the picture.


Picture:Call clearing module.

This module sends and receives the folloving messages:

• DISCONNECT
• RELEASE
• RELEASE COMPLETE

And this module is in one of the following states:

• Disconnect request state
• Release request state

Call information module

The call information module takes care of call suspention and resuming. A user can requets call suspention by sending a SUSPEND request to the network. In that case, suspend request state shall be entered and timer T319 started. If SUSPEND ACKNOWLEDGE is received, T319 is stopped and B-channel is released. The network can also respond with a SUSPEND REJECT message. If that is the case, active state is entered. If timer T319 expires, active state is also entered.
When the call needs to be refreshed, the user sends a RESUME message to the network. Resume request state is entered and timer T318 is started. If RESUME ACKNOWLEDGE is received, T318 is stopped and active state is entered. The resume request can also be rejected, and null state is entered. If timer T318 expires, call clearing is invoked. The following picture shows the procedures.



Picture:Call information module.
This module sends and receives the following messages:

• SUSPEND
• SUSPEND ACKNOWLEDGE
• SUSPEND REJECT
• RESUME
• RESUME ACKNOWLEDGE
• RESUME REJECT

And this module is in one of the following states:

• Suspend request state
• Resume request state

Miscellaneous module

The miscellaneous module handles requests for status messages. A STATUS message is sent as a response to a STATUS ENQUIRY message or at any time during a call to report error conditions. It is mandatory to send response to a status enquiry message.


Picture:Miscellaneous module.