Version
Chapter 10
Demonstration Program
10.1 Introduction
10.2 Running the Program
10.2.1 Running Back-to-Back With isdndemo
10.3 Structure and Coding Features
10.3.1 Data Structures
10.3.2 Program Structure
10.3.3 Call Transfer
10.1 Introduction
The demonstration program,
isdnxfer
, illustrates the steps involved in performing a call transfer operation, under Q.SIG and ETS 300 (ETS 300). The program is a single-threaded layer 3 application. It automatically accepts inbound calls and then performs a transfer operation of the inbound call to another number. Because the transfer operation is protocol dependent, depending on the protocol being run, different application state tables are used to manage the application. For ETS 300, once the transfer is complete, both the inbound and outbound sides of the call are cleared by the network. For Q.SIG, the application continues to monitor both sides of the call for a disconnect. When a disconnect is detected, both the inbound and outbound sides are cleared.
10.2 Running the Program
This program uses the following command-line arguments:
Option
Description
Default
-a
nai
NAI to be used.
0
-b
board_#
Board number.
0
-d
dialstring
Dial string for outbound operation.
1234567
-p
protocol
Protocol to use:
11
= ETS 300
16
= Q.SIG
16
(Q.SIG)
-v
Verbose (show ACU messages).
Non-verbose.
10.2.1 Running Back-to-Back With isdndemo
For back-to-back running, the Q.SIG variation of this program can be run with
isdndemo
. For example, running
isdndemo
with the following options will work with the
isdnxfer
program.
isdndemo -n -p16 -o1
The ETS 300 version of
isdnxfer
can only be run when connected to a network.
10.3 Structure and Coding Features
The following sections describe the internal workings of
isdnxfer
.
10.3.1 Data Structures
Each B channel has a data structure associated with it. This data structure is called
lineinfo
and is defined in the header file
isdnxfer.h
. The purpose of this structure is to maintain state information about each B channel and to provide a mechanism to link the inbound and outbound B channels in a transfer operation. A global array of these structures is defined in
isdnxfer.c
. The NMS logical timeslot number of the B channel is used to specify the index into this array for a particular B channel.
10.3.2 Program Structure
The main section of the program consists of an initialization section and an infinite event processing loop. In the initialization section, the
lineinfo
structures for all of the B channels are initialized, the command-line arguments are parsed, and the Natural Access services are started. The services started are the ADI service, the ISDN service, and the Switching service. (The switching service is only necessary for the Q.SIG transfer operation.) Once the services are started, the ISDN stack is started and the program enters an infinite event processing loop.
The processing loop waits for a Natural Access event. When it receives an event, it calls the
ProcessEvent
function For ISDN events, the
DecodeISDNMessage
function is called. Within this function, one of the following application processing routines is then called:
If the protocol is Q.SIG, then the
QSIGApplicationProcessing
application routine is called.
If the protocol is ETS 300, then the
ETS300ApplicationProcessing
application routine is called.
10.3.3 Call Transfer
The call transfer operation is protocol dependent: the call setup, transfer process, and call tear down process are controlled by different application routines depending upon whether the protocol is Q.SIG or ETS 300. The following sections describe the transfer process along with the event flow, for Q.SIG and for ETS 300.
Q.SIG
The event processing is handled by the
QSIGApplicationProcessing
function.
Inbound call arrives (
ACU_CONN_IN
).
Answer call on B channel (
ACU_CONN_RS
).
Inbound call is connected (
ACU_CONN_CO
).
Find a free timeslot for an outbound call (use the
linestate
structure for this).
Place an outbound call (
ACU_CONN_RQ
).
Connect inbound and outbound B channels.
Outbound call is connected (
ACU_CONN_CO
).
Send facility message to the inbound side specifying a transfer-by-join operation.
If message is wrong -
ACU_FACILITY_IN
.
Send facility message to the outbound side specifying a transfer-by-join operation.
If message is wrong -
ACU_FACILITY_IN
.
Detect disconnect on either the inbound or outbound side.
When a disconnect is detected (
ACU_CLEAR_IN
), respond to the disconnect (
ACU_CLEAR_RS
).
Send a disconnect to the other end (
ACU_CLEAR_RQ
).
Receive a confirmation of disconnect from both the inbound and the outbound sides (
ACU_CLEAR_CO
).
Disconnect the B channels.
ETS 300
The event processing is handled by the
ETS300ApplicationProcessing
function.
Inbound call arrives (
ACU_CONN_IN
).
Answer call on B channel (
ACU_CONN_RS
).
Inbound call is connected (
ACU_CONN_CO
).
Issue a facility message to place the call on hold.
Receive a confirmation (probably with an
ACU_FACILITY_IN
).
Place an outbound call on the same B channel (
ACU_CONN_RQ
).
Outbound call is connected (
ACU_CONN_CO
).
Send facility message to the inbound side specifying a transfer operation.
Send transfer request on outbound call. Choose outbound since this is the active call.
Receive a confirmation (
ACU_FACILITY_IN
).
Wait for disconnect on the inbound and outbound sides.
When a disconnect is detected (
ACU_CLEAR_IN
), respond to the disconnect (
ACU_CLEAR_RS
).
Receive a confirmation of disconnect (
ACU_CLEAR_CO
).
Version
Want to send us feedback on our documentation? Email:
Tech_Pubs@nmss.com
Copyright © 2001, Natural MicroSystems, Inc. All rights reserved.
Version
Version