📄 readme.txt
字号:
TB640_ISDN_STATE_FUNCTION(TB640IsdnProcessState10)
{
TB640_ISDN_STATE_ENTRY(TB640_ISDN_CALL_APP_STATE_10)
{
TB640_ISDN_STATE_WAIT;
}
TB640_ISDN_STATE_DECLARE_FIRST_EVENT (TB640_MSG_ID_ISDN_NOTIF_CALL_PROCEEDING_INDICATION)
{
PTB640_EVT_ISDN_NOTIF_CALL_PROCEEDING_INDICATION pEvent = in_pMsgPayload;
if (pEvent->hTrunkRes != pTrunkResInfo->hTrunkResource)
{
TB640_ISDN_LOG (TRACE_LEVEL_4, "Unknown trunk resource handle, trk %d\n",
in_pCallContext->un32TrunkIndex);
TB640_ISDN_INCREMENT_STATS (un32NbCallOpeningFailure, 1);
TB640_ISDN_CHANGE_STATE (TB640_ISDN_CALL_APP_STATE_6);
}
else
{
TB640_ISDN_STATE_WAIT;
}
}
TB640_ISDN_STATE_DECLARE_NEXT_EVENT (TB640_MSG_ID_ISDN_NOTIF_DISCONNECT_INDICATION)
{
TB640_ISDN_LOG (TRACE_LEVEL_4, "Received DISC_IND while waiting for ALERT or CONN_CFM, trk %d\n",
in_pCallContext->un32TrunkIndex);
in_pCallContext->fIsdnDisconnected = TBX_TRUE;
TB640_ISDN_CHANGE_STATE (TB640_ISDN_CALL_APP_STATE_8);
}
TB640_ISDN_STATE_DECLARE_NEXT_EVENT (TB640_MSG_ID_ISDN_NOTIF_ALERT_INDICATION)
{
...
}
TB640_ISDN_STATE_DECLARE_NEXT_EVENT (TB640_MSG_ID_ISDN_TIMEOUT)
{
in_pCallContext->fTimeoutOccured = TBX_TRUE;
in_pCallContext->fIsdnNeedToDisconnect = TBX_TRUE;
TB640_ISDN_CHANGE_STATE (TB640_ISDN_CALL_APP_STATE_6);
}
TB640_ISDN_STATE_RETURN
}
Each state function is designed to wait for certain asynchronous events
to do a specific action. Unknown notifications are simply ignored and makes
the state machine to leave the call in the same state. Within the example
shown above (function TB640IsdnProcessState10() in file states.c), there are
some partitionning under the form of macros:
TB640_ISDN_STATE_ENTRY(__NameOfTheState__) { ... }
This portion of the function will be called only once when the
call first reaches that state. Further notifications will not
execute this code again unless the state of the call is changed
(and then comes back to this state).
TB640_ISDN_STATE_DECLARE_FIRST_EVENT (__MessageID__) { ... }
TB640_ISDN_STATE_DECLARE_NEXT_EVENT (__MessageID__) { ... }
These portions of the function are actually called when the
notification/response received is the targeted MessageID.
Within the bracers, the function can do some actions (i.e. send
requests, set flags, update stats, instruct the state machine
to wait for other events, change the call to another state, etc).
These macros actually hides a 'switch-case' statement.
Other macros are used within the state function to act upon the state:
TB640_ISDN_CHANGE_STATE(__NameOfTheNextState__);
This macro instructs the current call to switch to another state
and to execute its entry code (TB640_ISDN_STATE_ENTRY).
TB640_ISDN_STATE_WAIT;
This macro instructs the current call to wait for another event
to continue processing. This call context will be returned to
the 'waiting' queue until another event occurs.
TB640_ISDN_SET_TIMEOUT(__TimeoutDuration__);
Instructs the state machine to restart the timeout counter with a
expiration time of __TimeoutDuration__ in second. Upon expiry of
the timer, an event TB640_MSG_ID_ISDN_TIMEOUT will be sent to the
state machine. A timeout value of -1 means a timer stop (no
timeout). Note that there is only one simulteneaous timer per
call context.
TB640_ISDN_DESTROY_CONTEXT;
Instructs the state machine handling function that the call is
now considered over and that it can destroy the call context (i.e.
return it to the free pool).
TB640_ISDN_STATE_RETURN;
This macros is used to return the instruction to the state machine
handling function. It can only be used once at the end of every
state function.
As mentioned before, the complete state machine to handle an ISDN call (and
do some other processing -> connect resources) is described completely in the
document isdnstates.pdf.
-------------------------------------------------------------------------------
- 4 - Configuration file
-------------------------------------------------------------------------------
The sample's configuration file is used to instruct the application about
the resources that need to be configured onto the different blades upon
startup OR about the 'expected' resources. As explained in earlier
sections, the application will query the resource already allocated upon
startup, will free resources not conforming with the configuration file and
then allocate new resources to match the requested setup.
It is possible to configure and control up to
TB640_ISDN_MAX_SUPPORTED_ADAPTERS (typically 2) blades using the same
application instance. This requires the configuration file to contain both
blades (also refered to as 'adapters') configurations.
The first section of the configuration file contains the general
parameters common to the application instance. Those parameters are included
in a section named '.PARAMS'. This section ends when the keyword '.END' is
found.
.PARAMS
LOG_FILENAME=log.txt
LOG_FILE_LEVEL=4
LOG_DISPLAY_LEVEL=4
APP_UNIQUE_ID=1157652480
MIN_REFRESH=100
CTBUS_CONNECTION=FALSE
.END
Parameters description for this section:
LOG_FILENAME: This is the log filename that is to be written by the
application.
LOG_FILE_LEVEL: This is the default log trace level that is going to be
used by the application upon startup to write to the
log file. This setting can be overriden from the
user-interface later on. Accepted values are from 0
(loud) to 5 (quiet).
LOG_DISPLAY_LEVEL: This is the default log trace level that is going to
be used by the application upon startup to write to
the display. This setting can be overriden from the
user-interface later on. Accepted values are from 0
(loud) to 5 (quiet).
APP_UNIQUE_ID: This parameters needs to indicate a 'unique' 32 bits
numbers (arbitrary) that will be used as a user-context
for resources allocation on the targeted blades. When
two application instances are controlling the same blade
(i.e. one controls trunks from 0-15 while another
controls trunks from 16-32), this number is used to
setup events filters so that an instance does not
receives events not generated by its resources (i.e
stacks allocated by the other application instance).
MIN_REFRESH: This parameter (in msec) is the minimum refresh rate of the
display screen. Even if the display is text, refreshing
the display too often may take CPU from the application
server depending of numerous factors such as the OS
(Windows vs linux vs solaris) or the display HW that is
used. Typical value is between 100-500 msec.
CTBUS_CONNECTION: This parameter instructs the application to simulate
a connection to the CtBus for every call that is
processed. This is used to have a consistent
performance value since a 'normal' call involves more
than just dealing with the actual protocol calls.
Once the call is established, the trunk resource
associated with the call is connected to something.
If set to TRUE, the trunk resource will be connected
to a CTBus resource. If set to FALSE, the trunk
resource will be connected in loopback on itself
(half-duplex connection).
The following sections contains the configuration of the blades. These
configuration options are included in a section named '.ADAPTER=<name of
the adapter>'. This section ends when the keyword '.END' is found.
.ADAPTER=TB000866
...
.END
Within those blade configuration sections, there can be from one to 64
trunk and stack configuration sections. Such a section always begin by
the keyword '.TRUNK' and ends when the keyword '.END' is found. Within
that section, three mandatory configuration files can be found. The first
one is to configure the physical trunks, followed by the protocol stack
configuration and then followed by parameters for runtime calls.
.TRUNK
TRUNK_CFG=<TrkNb>,<TrkType>,<Framing>,<LineEnc>,<LineLen>,<fLoopTime>,<IdlePattern>
STACK_CFG=<Variant>,<ProtocolSide>,<fOverlapMode>
CALL_CFG=<CallingNb>,<CalledNb>,<RedirectingNb>
.END
.TRUNK
TRUNK_CFG=0,E1,AUTO,HDB3,SHORT,FALSE,85
STACK_CFG=NET5,NETWORK,FALSE
CALL_CFG=5555,8888,1234
.END
Parameters description for the TRUNK_CFG keyword:
<TrkNb>: This is the actual trunk number that will be configured.
Typical values are from 0 to 63 for TB640 blades.
<TrkType>: This is the trunk type configuration parameters. Different
configuration options are available depending on this value.
Possible values are "E1", "T1" or "J1".
For 'E1':
<Framing>: This is the E1 trunk framing. Possible values are
"DFRAME", "MFRAME" or "AUTO". DFRAME is for double
frame (no CRC4). MFRAME is multi-frame with CRC4.
AUTO is the multi-frame with auto CRC selection.
Default value is AUTO.
<LineEnc>: This is the E1 line encoding. Possible values are
"HDB3" or "AMI". Default is HDB3.
<LineLen>: This is the E1 line termination length. Possible
values are "SHORT" or "LONG". SHORT is used for line
less than 200 feets otherwise LONG is used. Default
value is SHORT.
For 'T1' and 'J1':
<Framing>: This is the T1/J1 trunk framing. Possible values are
"SF", "ESF" or "SLC96". SF is super-frame (12 frames).
ESF is extended super-frame (24 frames). SLC96
(TR008) is subscriber loop carrier framing mode
(72 frames). Default value is ESF.
<LineEnc>: This is the T1/J1 line encoding. Possible values are
"B8ZS" or "AMI". Default is B8ZS.
<LineLen>: This is the T1/J1 line termination length. Possible
values are "SHORT" or "LONG". SHORT is used for line
less than 200 feets otherwise LONG is used.
Default value is SHORT.
<fLoopTime>: This is the trunk type looptime configuration. When set
to TRUE, it means that the transmit clock is derived from
the received clock. Use this only if the whole blade
clock is synchronized to that trunk otherwise slips may
occur. Default value is FALSE.
<IdlePattern>: This is the idle pattern code that will be used when
a trunk resource is not connection (must be specified in
decimal). Typical value for E1 is 85 (0x55). Typical
value for T1/J1 is 127 (0x7F).
Parameters description for the STACK_CFG keyword:
<Variant>: This is the ISDN stack variant that will be used. Possible
values are "4ESS", "AUS", "5ESS", "NET5", "DMS", "NI2" or
"HK". 4ESS is Lucent 4ESS. AUS is Australian TS-014 and
TS-038. 5ESS is Lucent 5ESS. NET5 is Euro ISDN ETSI NET5
(French, German, UK, China and Korea). DMS is Nortel
DMS-100. NI2 is ETSI national ISDN-2. HK is Euro ISDN ETSI
NET5 for Honk-kong.
<ProtocolSide>: This is the ISDN protocol side (user-side vs network-
side). Possible values are "USER" or "NETWORK". Typical
value depends on the system configuration.
<fOverlapMode>: This is the stack overlap mode configuration. When set
to TRUE, it means that overlap mode will be used for
incoming and outgoing calls. When set to false, 'en-bloc'
mode will be used. Default value depends on the system
configuration but 'en-bloc' (FALSE) is mostly used.
Parameters description for the CALL_CFG keyword:
<CallingNb>: These digits corresponds to the default 'calling number'
that will be used in every outgoing calls.
<CalledNb>: These digits corresponds to the default 'called number' that
will be used in every outgoing calls.
<RedirectingNb>: These digits corresponds to the default 'redirection
number' that will fill the 'redirecting IE' in every
outgoing calls.
+-----------------------------------------------------------------------------+
| End of document |
+-----------------------------------------------------------------------------+
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -