CASr1 scripting

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(→ACTION_SET_ANI)
m
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  
−
This page explains how CASr1 script are implemented, so the reader can read, modify or create CASR1 scripts to adapt to different variants, or implement new variants.
+
This page explains how CASr1 script are implemented. You can read, modify, or create CASR1 scripts to adapt to different variants, or implement new variants.
  
 
== Summary ==
 
== Summary ==
Line 29: Line 29:
 
For more information about CASR2 scripts, please refer to the following page: [[Web_Portal_Tutorial_Guide_v2.6#CASR2]]
 
For more information about CASR2 scripts, please refer to the following page: [[Web_Portal_Tutorial_Guide_v2.6#CASR2]]
  
−
== Set the script type to CASR1 ==
+
=== Set the script type to CASR1 ===
 
A CAS script be identified as a CASR1 script when the following variable is set:
 
A CAS script be identified as a CASR1 script when the following variable is set:
 
<pre>
 
<pre>
Line 37: Line 37:
 
If this variable is missing, the script will be interpreted as "CASR2".
 
If this variable is missing, the script will be interpreted as "CASR2".
  
 +
=== Provided scripts ===
 +
Toolpack already supports multiple CAS variants through scripts that are installed in any new Toolpack installation:
 +
<ul>
 +
  <li>
 +
    CASR1 variants:
 +
    <ul>
 +
      [[CAS#Supported_CAS_R1_variants|Supported CASR1 variants]]
 +
    </ul>
 +
  </li>
 +
  <li>
 +
    CASR2 variants:
 +
    <ul>
 +
      [[CAS#Supported_CAS_R2_variants|Supported CASR2 variants]]
 +
    </ul>
 +
  </li>
 +
</ul>
  
 
== Overview ==
 
== Overview ==
Line 153: Line 169:
 
<pre>
 
<pre>
 
TONE_VP_GROUP = 1
 
TONE_VP_GROUP = 1
 +
</pre>
 +
 +
 +
=== TX_DIAL_TONE ===
 +
Defines if (and which) dial tone must be played on a backward (incoming) call.
 +
Empty string (or missing variable) results in no dial tone being played.
 +
 +
Default: No dial tone
 +
 +
<pre>
 +
TX_DIAL_TONE = "(350,440)" -- This is default US dial tone
 +
</pre>
 +
 +
=== USE_FORCED_RELEASE ===
 +
Defines if "forced release" option must be used to terminate non-answered backward (incoming) calls.
 +
 +
In most CASR1 variants, the CAS bits for a backward (incoming) calls remain "on-hook" until the call is answered (except for short "wink" periods).
 +
Because of that, it's not possible to indicate remote equipment that we want to terminate this incoming call, since bits are already "on hook".
 +
 +
The solution to that is to quickly set the CAS bits to "off-hook" then "on-hook", to indicate to remote side that we want to terminate the call.
 +
 +
This option should be used with care, because it may cause remote equipment to think the call has been answered for about 200ms. This could cause billing or statistics (ASR) calculation problems on the remote equipment if it does not expect that.
 +
 +
Default: 0 (Don't use forced release)
 +
 +
<pre>
 +
TX_DIAL_TONE = "(350,440)" -- This is default US dial tone
 
</pre>
 
</pre>
  
Line 542: Line 585:
 
Date/time, trunk number and timeslot number are automatically printed with this trace.
 
Date/time, trunk number and timeslot number are automatically printed with this trace.
  
−
These traces will be seen in the Toolpack "tblogtrace" application (and it's corresponding log file on the server's hard drive).
+
These traces will be seen in the Toolpack [[Toolpack_Application:tblogtrace|tblogtrace]] application (and it's corresponding log file on the server's hard drive).
  
 
Parameters:
 
Parameters:
Line 710: Line 753:
 
</ol>
 
</ol>
  
−
More than one of the methods above can be used (but at least one must be used).
+
More than one of the methods above can be used.
 +
If none of these options are used, the script will consider that ANI is not used (won't be received, must not be sent).
  
 
Once ANI has been considered complete by one of the 3 methods above, then [[#EVENT_ANI_RECEIVED|EVENT_ANI_RECEIVED]] is reported to the script.
 
Once ANI has been considered complete by one of the 3 methods above, then [[#EVENT_ANI_RECEIVED|EVENT_ANI_RECEIVED]] is reported to the script.
Line 737: Line 781:
  
 
This function is not normally used. But it can be useful in some cases:
 
This function is not normally used. But it can be useful in some cases:
−
* Script wants to provide a ANI on a network where no ANI is sent by the remote side.
+
<ul>
−
* Script wants to override the ANI detected with [[#ACTION_WAIT_ANI|ACTION_WAIT_ANI]] by another one
+
  <li>
−
* Script wants to collect tones one by one ([[#EVENT_TONE_RECEIVED|EVENT_TONE_RECEIVED]], and built the ANI from these tones.
+
    For incoming (backward) calls:
 +
    <ul>
 +
      <li>Script wants to provide a ANI on a network where no ANI is sent by the remote equipment.</li>
 +
      <li>Script wants to override the ANI detected ([[#ACTION_WAIT_ANI|ACTION_WAIT_ANI]]) by another one chosen by the script.</li>
 +
      <li>Script wants to collect tones one by one ([[#EVENT_TONE_RECEIVED|EVENT_TONE_RECEIVED]], and built the ANI from these tones.</li>
 +
    </ul>
 +
  </li>
 +
  <li>
 +
    For outgoing (forward) calls:
 +
    <ul>
 +
      <li>Script wants to override the ANI (calling number) provided by Toolpack when this outgoing call was initialized.</li>
 +
    </ul>
 +
  </li>
 +
</ul>
  
 
This function must be called before the ANI is used in the signalling process, which means:
 
This function must be called before the ANI is used in the signalling process, which means:
Line 756: Line 813:
 
Same as [[#ACTION_SET_ANI|ACTION_SET_ANI]], but for DNIS (called number).
 
Same as [[#ACTION_SET_ANI|ACTION_SET_ANI]], but for DNIS (called number).
  
−
<pre>
+
=== ACTION_REPORT_SEIZURE ===
−
ACTION_REPORT_SEIZURE
+
Tell the application that seizure (off-hook) has been detected on a timeslot.
−
</pre>
+
−
No parameter.
+
  
−
Tell the application that seizure (off-hook) has
+
No parameter.
−
been deteced on a timeslot.
+
−
<pre>
+
−
ACTION_REPORT_VALIDATE_CALL
+
−
</pre>
+
−
No parameter.
+
  
−
Tell the application that ANI and/or DNIS have
+
=== ACTION_REPORT_VALIDATE_CALL ===
−
been successfully received, and we now have the
+
Tell the application that ANI and/or DNIS have been successfully received, and we now have the information required to process this incoming call.
−
information required to process this incoming call.
+
−
<pre>
+
−
ACTION_REPORT_ACCEPTED
+
−
</pre>
+
−
No parameter.
+
  
−
Tell the application that a "forward" call has
+
No parameter.
−
been accepted by remote equipment, often by
+
−
detecting a "Wink".
+
−
<pre>
+
−
ACTION_REPORT_ALERTED
+
−
</pre>
+
−
No parameter.
+
  
−
Tell the application that a "forward" call has
+
=== ACTION_REPORT_ACCEPTED ===
−
been alerted by remote equipment.
+
Tell the application that a "forward" call has been accepted by remote equipment, often by detecting a "Wink".
−
On most variants, there is no specific indication
+
−
from remote side, and this action must be taken
+
−
upon EVENT_DNIS_SENT.
+
−
On other variants, a "Wink" may be awaited before
+
−
calling this action.
+
−
<pre>
+
−
ACTION_REPORT_ANSWERED
+
−
</pre>
+
−
No parameter.
+
  
−
Tell the application that a "forward" call has
+
No parameter.
−
been answered by remote equipment, generally
+
−
because "off-hook" CAS bits have been received.
+
−
<pre>
+
−
ACTION_REPORT_BLOCKED
+
−
</pre>
+
−
No parameter.
+
  
−
Tells the application that the script considers
+
=== ACTION_REPORT_ALERTED ===
−
the timeslot as "remotely blocked". This is the
+
Tell the application that a "forward" call has been alerted by remote equipment.
−
case when remote side goes "off hook" and remains
+
−
in that state for some duration after we've
+
−
returned to "on hook" on our side.
+
−
<pre>
+
−
ACTION_REPORT_UNBLOCKED
+
−
</pre>
+
−
No parameter.
+
  
−
Tells the application that the timeslot is no
+
On most variants, there is no specific indication from remote side, and this action must be taken upon [[#EVENT_DNIS_SENT|EVENT_DNIS_SENT]].
−
more "remotely blocked", because remote
+
−
equipment went "on hook" after we reported
+
−
ACTION_REPORT_BLOCKED.
+
−
<pre>
+
−
ACTION_START_TIMER
+
−
</pre>
+
−
Parameter:
+
  
−
- Timer duration in milliseconds.
+
On other variants, a "Wink" may be awaited before calling this action (variants where there is a second "Wink" after digits are successfully received by remote equipment).
−
Starts a timer. EVENT_TIMEOUT will be
+
−
posted if the timer expires before
+
−
ACTION_CANCEL_TIMER is called.
+
−
<pre>
+
−
ACTION_CANCEL_TIMER
+
−
</pre>
+
−
No parameter.
+
−
Cancels a timer previously started with
+
−
ACTION_START_TIMER.
+
−
+
−
Digit format:
+
  
−
The digit format (for sending tone or ANI/DNIS prefix/suffix)
+
No parameter.
−
is represented by a string that contains up to 3 of the
+
=== ACTION_REPORT_ANSWERED ===
−
following characters: 0123456789ABCD*#
+
Tell the application that a "forward" call has been answered by remote equipment, generally because "off-hook" CAS bits have been received.
 +
 
 +
No parameter.
 +
 
 +
=== ACTION_REPORT_BLOCKED ===
 +
Tells the application that the script considers the timeslot as "remotely blocked".
 +
 
 +
This is generally the case when remote side goes "off hook" and does not send digits for a long time, without going back "on hook".
 +
 
 +
Reporting a timeslot as "remotely blocked" will inform Toolpack that this timeslot cannot be used to make outgoing calls. Toolpack can thus route outgoing calls accordingly.
 +
 
 +
No parameter.
 +
 
 +
=== ACTION_REPORT_UNBLOCKED ===
 +
Tells the application that the timeslot is no more "remotely blocked", because remote equipment went "on hook" after it was reported "remotely blocked.
 +
(in other words, this cancels [[#ACTION_REPORT_BLOCKED|ACTION_REPORT_BLOCKED]])
 +
 
 +
No parameter.
 +
 
 +
=== ACTION_START_TIMER ===
 +
Starts a timer.
 +
 
 +
[[#EVENT_TIMEOUT|EVENT_TIMEOUT]] will be posted if the timer expires before [[#ACTION_CANCEL_TIMER|ACTION_CANCEL_TIMER]] is called.
 +
 
 +
Starting a timer when another timer was already started will cancel previous timer and replace it with new timer.
 +
 
 +
Parameter:
 +
<ol>
 +
  <li>
 +
    Timer duration in milliseconds.
 +
  </li>
 +
</ol>
 +
 
 +
=== ACTION_CANCEL_TIMER ===
 +
Cancels a timer previously started with [[#ACTION_START_TIMER|ACTION_START_TIMER]].
 +
 
 +
No parameter.
  
 
== Debugging the script ==
 
== Debugging the script ==
 +
=== Validating LUA language syntax ===
 +
The LUA language syntax is automatically validated when saving the script from the Web Portal.
 +
 +
The Web Portal will refuse to save a script that has a LUA language syntax error.
 +
 +
=== Using log traces ===
 +
The CAS stack provides the [[#stack_log_trace|StackLogTrace]] function that allows the script to print traces through execution.
 +
 +
Traces can be of different levels (more or less verbose). It is recommended to leave traces at various levels through the script so it can be easily debugged "in the field" by simply changing the trace level of the CAS stack while testing a call.
 +
 +
It's also a good practice that the script prints "error" traces to report any error in the log. But be careful not to write error traces in the log for "normal" situations, like calls that fail due to answer timeout for example, as we don't want the logs to be filled out with error traces that correspond to a situation that's actually "normal" on a network.
 +
 +
==== Viewing traces ====
 +
All traces printed by the CAS script will be received by the Toolpack [[Toolpack_Application:tblogtrace|tblogtrace]] application, and written to disk on the host server in the corresponding log file.

Latest revision as of 11:54, 20 December 2017

This page explains how CASr1 script are implemented. You can read, modify, or create CASR1 scripts to adapt to different variants, or implement new variants.

Contents

Summary

Toolpack uses the LUA programming language to implement CAS scripts. The CAS scripts are interpreted by the TMG unit in order to handle calls.

A portion of the CAS state machine is implemented outside the script, in the CAS stack that runs on the TMG unit, although the script still offers a great level of flexibility to implement various CAS variants.

CASR1 vs CASR2 scripts

CASR1 variants and CASR2 variants both use LUA scripts stored in the same place in the Toolpack configuration Web Portal.

However, CASR1 and CASR2 scripts are quite different. They use different constants and function, and will have different "callback" functions called by the CAS stack on the TMG. The general architecture (state machine) of the scripts is also different.

In a few words:

CASR1 scripts need to:

  • Handle incoming CAS bits changes
  • Decide when to change sent CAS bits
  • Decide when to detect/send ANI/DNIS tones
  • Implement a state machine that follows the different call states, and report these states to the CAS stack

CASR2 scripts need to:

  • Define forward and backward digits to use
  • Map digits to various meanings
  • Handle received digits and how to handle then

The current page explains CASR1 scripts. For more information about CASR2 scripts, please refer to the following page: Web_Portal_Tutorial_Guide_v2.6#CASR2

Set the script type to CASR1

A CAS script be identified as a CASR1 script when the following variable is set: 

SCRIPT_TYPE="CASR1"

If this variable is missing, the script will be interpreted as "CASR2".

Provided scripts

Toolpack already supports multiple CAS variants through scripts that are installed in any new Toolpack installation:

Overview

Per-timeslot context

The CASR1 scripts works on a "per timeslot" basis. It's informed of each timeslot that is under it's control through callback function HandleNewTimeslot.

A context is provided with each timeslot, so the script can store "per-timeslot" variables in order to implement the state machine.

Per-timeslot events

Once a timeslot has been created in the script, the CAS stack will inform the script of any event on that timeslot (CAS bits changes and others). To each received event, the script will take one ore more action.

Per-timeslot actions

The CAS script can perform various actions on a timeslot, while it handles timeslot events.

For example, it can

  • change CAS bits (or send "wink")
  • report call state to the CAS stack (seizure, call alerting, call answered, call terminating, timeslot remotely blocked, etc.).
  • ask for ANI/DNIS detection
  • ask for transmission of ANI/DNIS
  • Start a timer
  • And more...

Per-timeslot state machine

It's up to the script implementation to define it's own states for handling the calls. The script is thus very flexible in the way it implements the CASR1 variant call flow.

The current document does not describe how CASR1 call flows are implemented (what are CAS bits, when and why to they "change", how calling/called numbers are exchanged, what is the call flow etc.) The reader shall find that information in the specifications for CASR1 variants.

The current document provides general information on available timeslot events and actions that allow to actually implement CASR1 variants.



Script entry points

There are 2 functions that the script must provide, and that will be called by the stack when appropriate:

(see documentation blow for detailed information)

Configurable global script constants

The script can define some constants required by the stack (though default values are provided if the script does not define these constants).

SCRIPT_TYPE

Defines the type of this sript. This constant is mandatory for CASR1 scripts. 

SCRIPT_TYPE 				= "CASR1"

ABCD_PATTERN_MATCH_MASK

Mask to apply to CAS bits detected from remote equipment (for bits 0xABCD). A bit which mask is set to 0 will be ignored and always reported as zero (0) to this script. This is useful in some cases when unused bits have undefined (and even sometimes toggeling!) values.

Default: 0x1111 

ABCD_PATTERN_MATCH_MASK 	= 0x1111

TONE_USE_DTMF

Indicates the type of tones must be used to send/receive AND/DNIS. Value of 1 stands for DTMF. Value of 0 defaults to MFR1.

Default: 1 (use DTMF) 

TONE_USE_DTMF			 	= 1

TONE_ON_TIME

Defines the "on time" (in ms) of tones used when sending ANI/DNIS.

Default: 60ms 

TONE_ON_TIME				= 60

TONE_OFF_TIME

Defines the "off time" (inter-digit delay)(in ms) of tones used when sending ANI/DNIS.

Default: 40ms 

TONE_OFF_TIME				= 50

TONE_LEVEL

Defines the audio power level (in DB) of tones used when sending ANI/DNIS, or dial tone.

Default: -10db 

TONE_LEVEL				= -10

TONE_VP_GROUP

Defines the type of tone detector/generator that will be used for CASR1 calls:

  • Group 0: Use DSP resources (for TMG that have DSP resources)
  • Group 1: Use VOIP resources (for TMG that have VOIP resources)

It may be required to change this value if using CASR1 scripts on TMG units that don't have either DSP or VOIP resources.

Default: 1 (VOIP resources) 

TONE_VP_GROUP				= 1


TX_DIAL_TONE

Defines if (and which) dial tone must be played on a backward (incoming) call. Empty string (or missing variable) results in no dial tone being played.

Default: No dial tone 

TX_DIAL_TONE			= "(350,440)"	-- This is default US dial tone

USE_FORCED_RELEASE

Defines if "forced release" option must be used to terminate non-answered backward (incoming) calls.

In most CASR1 variants, the CAS bits for a backward (incoming) calls remain "on-hook" until the call is answered (except for short "wink" periods). Because of that, it's not possible to indicate remote equipment that we want to terminate this incoming call, since bits are already "on hook".

The solution to that is to quickly set the CAS bits to "off-hook" then "on-hook", to indicate to remote side that we want to terminate the call.

This option should be used with care, because it may cause remote equipment to think the call has been answered for about 200ms. This could cause billing or statistics (ASR) calculation problems on the remote equipment if it does not expect that.

Default: 0 (Don't use forced release) 

TX_DIAL_TONE			= "(350,440)"	-- This is default US dial tone

Tones mapping to ASCII characters

DTMF mapping

DTMF tones are represented, in the script, as ASCII characters. (these are used to define ANI/DNIS prefix/suffix, or to explicitly provide the ANI/DNIS for a call).

Please refer to the following table to know which ASCII character is used to represent each existing DTMF tone: 

	
		'0'	->	DTMF Digit 0: 				941Hz + 1336Hz
		'1'	->	DTMF Digit 1: 				697Hz + 1209Hz
		'2'	->	DTMF Digit 2: 				697Hz + 1336Hz
		'3'	->	DTMF Digit 3: 				697Hz + 1477Hz
		'4'	->	DTMF Digit 4: 				770Hz + 1209Hz
		'5'	->	DTMF Digit 5: 				770Hz + 1336Hz
		'6'	->	DTMF Digit 6: 				770Hz + 1477Hz
		'7'	->	DTMF Digit 7: 				852Hz + 1209Hz
		'8'	->	DTMF Digit 8: 				852Hz + 1336Hz
		'9'	->	DTMF Digit 9: 				852Hz + 1477Hz
		'*'	->	DTMF Digit Star (*): 			941Hz + 1209Hz
		'#'	->	DTMF Digit Pound (#): 			941Hz + 1477Hz
		'A'	->	DTMF Digit A: 				697Hz + 1633Hz
		'B'	->	DTMF Digit B: 				770Hz + 1633Hz
		'C'	->	DTMF Digit C: 				852Hz + 1633Hz
		'D'	->	DTMF Digit D: 				941Hz + 1633Hz
		Alternative values for * and #:
		'E'	->	DTMF Digit Star (*): 			941Hz + 1209Hz
		'F'	->	DTMF Digit Pound (#): 			941Hz + 1477Hz

MFR1 mapping

MFR1 tones are represented, in the script, as ASCII characters. (these are used to define ANI/DNIS prefix/suffix, or to explicitly provide the ANI/DNIS for a call).

Please refer to the following table to know which ASCII character is used to represent each existing MFR1 tone: 

		'0'	->	MFR1 Digit 0: 				1300Hz + 1500Hz
		'1'	->	MFR1 Digit 1: 				700Hz  + 900Hz
		'2'	->	MFR1 Digit 2: 				700Hz  + 1100Hz
		'3'	->	MFR1 Digit 3: 				900Hz  + 1100Hz
		'4'	->	MFR1 Digit 4: 				700Hz  + 1300Hz
		'5'	->	MFR1 Digit 5: 				900Hz  + 1300Hz
		'6'	->	MFR1 Digit 6: 				1100Hz + 1300Hz
		'7'	->	MFR1 Digit 7: 				700Hz  + 1500Hz
		'8'	->	MFR1 Digit 8: 				900Hz  + 1500Hz
		'9'	->	MFR1 Digit 9: 				1100Hz + 1500Hz
		'*'	->	MFR1 KP (Start of pulsing):		1100Hz + 1700Hz
		'#'	->	MFR1 ST (End of pulsing):		1500Hz + 1700Hz
		'A'	->	MFR1 STI: 				900Hz  + 1700Hz
		'B'	->	MFR1 STII: 				1300Hz + 1700Hz
		'C'	->	MFR1 STIII: 				700Hz  + 1700Hz
		'D'	->	Not supported in MFR1

		Alternative characters:
		'E'	->	MFR1 KP (Start of pulsing):		1100Hz + 1700Hz
		'F'	->	MFR1 ST (End of pulsing):		1500Hz + 1700Hz

Static constants pushed by the stack, for usage in this script

Actions

Available actions for StackAction function:

Commonly used actions: 

ACTION_END_SIGNALING
ACTION_SET_CAS_BITS
ACTION_SEND_WINK
ACTION_WAIT_WINK
ACTION_SEND_ANI
ACTION_SEND_DNIS
ACTION_WAIT_ANI
ACTION_WAIT_DNIS
ACTION_REPORT_SEIZURE
ACTION_REPORT_VALIDATE_CALL
ACTION_REPORT_ACCEPTED
ACTION_REPORT_ALERTED
ACTION_REPORT_ANSWERED
ACTION_REPORT_BLOCKED
ACTION_REPORT_UNBLOCKED
ACTION_START_TIMER
ACTION_CANCEL_TIMER

Additional actions to implement special variants 

ACTION_SEND_TONE
ACTION_SET_ANI
ACTION_SET_DNIS

Events

Events received by this script on HandleEvent function:

Commonly used events: 

EVENT_CAS_BITS_CHANGED
EVENT_WINK_DETECTED
EVENT_WINK_COMPLETED
EVENT_ANI_RECEIVED
EVENT_DNIS_RECEIVED
EVENT_ANI_SENT
EVENT_DNIS_SENT
EVENT_APP_FWD_MAKE_CALL
EVENT_APP_BWD_MUST_ALERT
EVENT_APP_BWD_MUST_ANSWER
EVENT_APP_END_SIGNALING
EVENT_APP_BLOCK_TIMESLOT
EVENT_APP_UNBLOCK_TIMESLOT
EVENT_TIMEOUT

Additional events to implement special variants 

EVENT_TONE_RECEIVED
EVENT_TONE_SENT

Result codes

Result codes that HandleNewTimeslot or HandleEvent functions must return: 

RESULT_OK
RESULT_FAIL
RESULT_MISMATCH
RESULT_OUT_OF_RESOURCE
RESULT_INVALID_PARAM
RESULT_INVALID_STATE
RESULT_NOT_SUPPORTED
RESULT_TRUNK_RES_NOT_IDLE
RESULT_BLOCKED_LOCALLY
RESULT_BLOCKED_REMOTELY

Call release causes

Call release causes to use with ACTION_END_SIGNALING 

CAUSE_FWD_SEIZURE_COLLISION
CAUSE_FWD_SEIZURE_ACK_TIMEOUT
CAUSE_FWD_TONE_TIMEOUT
CAUSE_FWD_ANSWER_TIMEOUT
CAUSE_FWD_CALL_REFUSED
CAUSE_FWD_REJECT_CALL
CAUSE_FWD_HANG_UP
CAUSE_BWD_TONE_TIMEOUT
CAUSE_BWD_REJECT_CALL
CAUSE_BWD_CALL_REFUSED
CAUSE_BWD_ALERT_TIMEOUT
CAUSE_BWD_ANSWER_TIMEOUT
CAUSE_BWD_HANG_UP

Trace levels

Trace levels (used with function StackLogTrace).

  • Least verbose is TRACE_LEVEL_0 (almost never printed).
  • Most verbose is TRACE_LEVEL_4 (generally printed). 
TRACE_LEVEL_0
TRACE_LEVEL_1
TRACE_LEVEL_2
TRACE_LEVEL_3
TRACE_LEVEL_4
TRACE_LEVEL_ALWAYS
TRACE_LEVEL_ERROR

Mandatory functions to implement in this script

The script must provide the following mandatory functions, that will be called by the CAS stack at appropriate moments.

HandleNewTimeslot( in_TimeslotCtx, in_InitialCasBits )

This function is called to prepare a new timeslot so it's ready to be used to receive events and eventually handle a CASR1 call.

When this function is called, the timeslot must be initially be considered "locally blocked (and CAS bits must be set to "off-hook" state). The stack will later send EVENT_APP_UNBLOCK_TIMESLOT when it's time to go "on-hook" and be ready to make calls.

in_TimeslotCtx

Context containing variables for this timeslot. This context is a LUA table. This table already contains two values:

  • ["TrunkNumber"]
  • ["TimeslotNumber"]

The script can store it's own LUA variables here (like the "call state"), which will be accessible for any event on this timeslot.

in_InitialCasBits

The initial states of CAS bits received from remote equipment (integer like 0x1111)

HandleEvent( in_TimeslotCtx, in_EventType, ... )

This function reports that an event occurred on a timeslot.

in_TimeslotCtx

Timeslot context used by the script to store any timeslot-related information, like the "call state".

This is the table that was passed to HandleNewTimeslot.

in_EventType

The type of the event that was just received

See below for list of events that can be received: CASR1 script events

...

Variable number of parameters, that depend on event type.

To access these parameters, the LUA syntax is as follows: 

	-- Create an array with the variable number of arguments:
	local args = {...}
	-- Accessing the first argument
	local first_argument_value = args[1]

Return value

This function must return RESULT_OK, or one of the return codes defined above.

This result code tells to the stack if the event was properly handled by the script. Upon non-OK code, the stack may decide to terminate the call, assuming the script is incomplete and did not expect the event.

Please note that RESULT_OK is normally returned even in case of events that make the call fail or be dropped. The purpose of this result code is not to indicate if the event cause a call to be dropped, but rather to indicate that the script really does not know what to do with the received event.

CASR1 script events

The CASR1 script will receive (and must handle) the following events (received in function HandleEvent

EVENT_CAS_BITS_CHANGED

Indicates that new CAS bits have been received from remote equipment.

Parameters:

  1. Received CAS bits (integer like 0x1111)
    Indicates that CAS bits values received by remote equipment have changed.

EVENT_WINK_DETECTED

Indicates that a "Wink" has been detected. This event can only follow ACTION_WAIT_WINK.

No specific parameter.

EVENT_WINK_COMPLETED

Indicates that a "Wink" has been sent successfully. This event can only follow ACTION_SEND_WINK.

No specific parameter.

EVENT_TONE_RECEIVED

Indicates that a tone was detected.

Not normally used in CASR1 standard variants, because most variants can rely on ACTION_WAIT_ANI or ACTION_WAIT_DNIS to collect calling/called numbers in one single action.

And thus this event will not report tones that are collected by the CAS stack as part of ACTION_WAIT_ANI or ACTION_WAIT_DNIS.

Parameters:

  1. A one-character string that represents the received tone (digit).
    See Tones mapping to ASCII characters for details about which ASCII character represents which tone.

EVENT_ANI_RECEIVED

Indicates that ANI (calling number) has been sent received (prefix/suffix detected). This event can only follow ACTION_WAIT_ANI.

Note: The received ANI/DNIS digits are not passed to the script as EVENT_TONE_RECEIVED. Instead, the stack stores them as the 'calling number' which will be reported to the application upon ACTION_REPORT_VALIDATE_CALL

No specific parameter.

EVENT_DNIS_RECEIVED

Same as EVENT_ANI_RECEIVED, but for DNIS (called number)

EVENT_TONE_SENT

Indicates that a tone (digit) as been sent successfully following ACTION_SEND_TONE. Not normally used in CASR1 standard variants.

No specific parameter.

EVENT_ANI_SENT

Indicates that ANI (calling number) has been sent successfully (all tones played). This event can only follow ACTION_SEND_ANI. No specific parameter.

EVENT_DNIS_SENT

Same as EVENT_ANI_SENT, but for DNIS (called number)

EVENT_APP_FWD_MAKE_CALL

Indicate that a new "forward" call must be made.

The script shall take appropriate actions to initiate a new call (most likely change the CAS bits to the "off hook" state).

No specific parameter.

EVENT_APP_BWD_MUST_ALERT

Indicates that this "backward" call must now be set to "alerted" state (meaning we have accepted the call, and received required information to proceed).

The decision of when to alert the call is made by the application, and at that moment the script receives this event so it can take appropriate actions to alert a "backward" call. (in most variants, there is nothing to do, on some variants, a "Wink" may be sent).

No specific parameter.

EVENT_APP_BWD_MUST_ANSWER

Indicates that this "backward" call must now be set to "answered" state.

The decision of when set the call "answered" is made by the application, and at that moment the script receives this event so it can take appropriate actions to answer. (in most variants, CAS bits must be set to "off hook" pattern).

No specific parameter.

EVENT_APP_END_SIGNALING

Indicates either that:

  • Application requests to terminate the call.
    The script then take appropriate action, like sending CAS bits to "idle" state, wait for remote equipment to acknowledge, then at the end use ACTION_END_SIGNALING to confirm that termination is completed.
  • Script had already previously called ACTION_END_SIGNALING, (after remote equipment set CAS bits to "idle" or after an error in the script), in which case this event confirms that the application is also ready to terminate the call.
    The script generally returns to "idle" state after that event.

No specific parameter.

EVENT_APP_BLOCK_TIMESLOT

Indicates that the timeslot must be locally blocked, the next time it becomes "idle".

On most variants where this is supported, a timeslot is "blocked" by going "off-hook", but not sending ANI/DNIS and remaining in that state no matter remote state.

This is also the default state for a newly created timeslot.

When this event is received on a non-idle timeslot (in a call, or establishing a call), it does not drop the call. Timeslot will be blocked only once the timeslot is back to "idle".

This state can only be canceled by EVENT_APP_UNBLOCK_TIMESLOT

No specific parameter.

EVENT_APP_UNBLOCK_TIMESLOT

Cancels a previous EVENT_APP_BLOCK_TIMESLOT, which (in most variants) requires to set our CAS bits to "on hook" (unless still in a call).

No specific parameter.

EVENT_TIMEOUT

Indicates that the timer previously started with ACTION_START_TIMER has expired. It's up to the script to determine the meaning of the timeout and take appropriate action.

No specific parameter.

Stack functions that can be called by this script

The CAS stack provides a few functions that the script can call.

StackActionToString( in_Action )

Returns string value of an action type, generally used for printing debug traces.

In the following example the StackAction function is remapped so that the script will print the action name in a trace every time that "StackAction" is called. 

-----------------------------------------------------------------------
--	Wraps StackAction function calls with debug comments
-----------------------------------------------------------------------
CasR1.StackAction = StackAction
function StackAction(name, ...)	
	StackLogTrace(TRACE_LEVEL_2, "Calling StackAction '%s'", StackActionToString(name) )
	CasR1.StackAction(name, ...)
end

StackEventToString( in_Event )

Returns string value of an event type, generally used for printing debug traces.

Example: 

function HandleEvent( in_TimeslotCtx, in_EventType, ... )
	StackLogTrace
	(
		TRACE_LEVEL_3, 
		"Event %s received",
		StackEventToString( in_EventType )
	)

StackCauseToString( in_Cause )

Returns string value of a call release cause, generally used for printing debug traces.

StackLogTrace( in_TraceLevel, in_Format, ... )

Will print a trace (generally debug traces).

Date/time, trunk number and timeslot number are automatically printed with this trace.

These traces will be seen in the Toolpack tblogtrace application (and it's corresponding log file on the server's hard drive).

Parameters:

  • in_TraceLevel:
    Level of the trace (see TRACE_LEVEL )
  • in_Format:
    String that contains the trace to print, plus references to other arguments ("printf" style format)
  • ...:
    Values for printf-style refernces of in_Format.

Example: 

	local cas_bits = 0x1100
	StackLogTrace( TRACE_LEVEL_2, "Send CAS bits %08X", cas_bits )

StackAction( in_Action, ... )

This function executes the specified action (in some cases with the specified action-specific arguments).

The action is done asynchronously, meaning that control will immediately return to the script. Events will be received later according to the actions taken.

Upon an event, the script may perform multiple actions (like starting a timer, declaring the call "alerted" and sending CAS bits for example)

Parameters :

  • in_Action:
    The action to perform.
    (see Stack Actions for list of available actions)
  • ...:
    Variable number of action-specific arguments..
    (see Stack Actions for description of each arguments specific to each action)

Stack actions

ACTION_END_SIGNALING

Indicates either that:

  • Application previously requested to terminate the call (with EVENT_APP_END_SIGNALING), in which case this action is used by the script to indicate that signaling is fully idle (local CAS bits set to "idle", remote equipment has acknowledged too with "idle" CAS bits).
  • Script wants to terminate the call (after remote equipment set CAS bits to "idle" or after an error in the script). After sending ACTION_END_SIGNALING, the script must wait until EVENT_APP_END_SIGNALING is received, which confirms that application is ready to terminate the call. Only at that moment the script shall set it's CAS bits to "idle" value.

Parameter:

  1. The call release cause to report. (See [[#Call_release_causes|Call release causes])

ACTION_SET_CAS_BITS

Changes the CAS bits that we're sending to the remote equipment.

Parameter:

  1. CAS bits to set (integer like 0x1111)

ACTION_SEND_WINK

Used to send a "Wink", which is temporary change of the CAS bits for few milliseconds, then back to initial CAS bits value.

EVENT_WINK_COMPLETED will be received by the script once Wink has completed (CAS bits are back to their initial value). Parameters:

  1. CAS bits to set during the "Wink" (integer like 0x1111)
  2. Duration of the "Wink" (in milliseconds)

ACTION_WAIT_WINK

Used to request a "Wink" detection.

Upon next CAS bits change from remote equipment, the stack will see if the bits match the Wink expected bits.

EVENT_WINK_DETECTED will be reported if CAS bits received from remote equipment change to the expected pattern for a duration within specified range, then go back to original value.

While waiting for a wink, any other CAS bits change not detected as a "Wink" will be reported to the script by EVENT_CAS_BITS_CHANGED

Parameters:

  1. Expected CAS bits during the "Wink" (integer like 0x1111)
  2. Minimum duration of the "Wink" (in ms)
  3. Maximum duration of the "Wink" (in ms)

ACTION_SEND_TONE

Used to send one digit (tone) toward remote equipment. EVENT_TONE_SENT will be received once the tone has been successfully sent. Not normally used in CASR1 standard variants.

Note: This action is not used to send ANI/DNIS (calling/called numbers), it's used to send other tones that may be used within the current CASR1 variant call flow.

Parameter:

  1. Digit (tone) to send. See Tones mapping to ASCII characters for details about which ASCII character represents which tone.

ACTION_SEND_ANI

Used to send ANI (calling number) toward remote equipment.

A prefix may be inserted before ANI, and a suffix maybe appended after the ANI.

EVENT_ANI_SENT will be received once transmission of prefix + ANI + suffix is completed.

Parameters:

  1. Prefix to send before ANI. Can be empty.
    See Tones mapping to ASCII characters for details about which ASCII character represents which tone.
  2. Suffix to send after ANI. Can be empty.
    See Tones mapping to ASCII characters for details about which ASCII character represents which tone.

ACTION_SEND_DNIS

Same as ACTION_SEND_ANI, but for sending DNIS (called number)

ACTION_WAIT_ANI

Used to wait for ANI (calling number) from remote equipment, by detecting tones.

Detection methods for ANI:

  1. Prefix/suffix separators indicate the start and/or end of the transmission of ANI.
    If prefix is detected, it's removed from the ANI. If not detected, it does not matter.
    If suffix is detected, it's removed from the ANI, and ANI is immediately reported as complete.
    If suffix is not detected, then another ANI detection method may still trigger end of ANI (inter-digit timeout, or fixed number of digits)
  2. Fixed expected number of digits
    With that method, ANI or DNIS is considered complete when the specified number of digits have been received.
  3. Inter-digit timeout
    With that method, as soon as there is more than this delay after receiving a digit, the ANI or DNIS is considered complete.

More than one of the methods above can be used. If none of these options are used, the script will consider that ANI is not used (won't be received, must not be sent).

Once ANI has been considered complete by one of the 3 methods above, then EVENT_ANI_RECEIVED is reported to the script.

Parameters:

  1. Prefix to expect before ANI. Can be empty. See explanation above.
  2. Suffix to expect after ANI. Can be empty. See explanation above.
  3. Number of expected digits. Set to 0 to ignore. See explanation above.
  4. Inter-digit timeout. Set to 0 to ignore. See explanation above.

ACTION_WAIT_DNIS

Same as ACTION_WAIT_ANI, but for receiving DNIS (called number).

ACTION_SET_ANI

Used by a script that wants to provide the ANI (rather than using ACTION_WAIT_ANI to receive it).

This function is not normally used. But it can be useful in some cases:

  • For incoming (backward) calls:
    • Script wants to provide a ANI on a network where no ANI is sent by the remote equipment.
    • Script wants to override the ANI detected (ACTION_WAIT_ANI) by another one chosen by the script.
    • Script wants to collect tones one by one (EVENT_TONE_RECEIVED, and built the ANI from these tones.
  • For outgoing (forward) calls:
    • Script wants to override the ANI (calling number) provided by Toolpack when this outgoing call was initialized.

This function must be called before the ANI is used in the signalling process, which means:


Parameter:

  1. ANI to set

ACTION_SET_DNIS

Same as ACTION_SET_ANI, but for DNIS (called number).

ACTION_REPORT_SEIZURE

Tell the application that seizure (off-hook) has been detected on a timeslot.

No parameter.

ACTION_REPORT_VALIDATE_CALL

Tell the application that ANI and/or DNIS have been successfully received, and we now have the information required to process this incoming call.

No parameter.

ACTION_REPORT_ACCEPTED

Tell the application that a "forward" call has been accepted by remote equipment, often by detecting a "Wink".

No parameter.

ACTION_REPORT_ALERTED

Tell the application that a "forward" call has been alerted by remote equipment.

On most variants, there is no specific indication from remote side, and this action must be taken upon EVENT_DNIS_SENT.

On other variants, a "Wink" may be awaited before calling this action (variants where there is a second "Wink" after digits are successfully received by remote equipment).

No parameter.

ACTION_REPORT_ANSWERED

Tell the application that a "forward" call has been answered by remote equipment, generally because "off-hook" CAS bits have been received.

No parameter.

ACTION_REPORT_BLOCKED

Tells the application that the script considers the timeslot as "remotely blocked".

This is generally the case when remote side goes "off hook" and does not send digits for a long time, without going back "on hook".

Reporting a timeslot as "remotely blocked" will inform Toolpack that this timeslot cannot be used to make outgoing calls. Toolpack can thus route outgoing calls accordingly.

No parameter.

ACTION_REPORT_UNBLOCKED

Tells the application that the timeslot is no more "remotely blocked", because remote equipment went "on hook" after it was reported "remotely blocked. (in other words, this cancels ACTION_REPORT_BLOCKED)

No parameter.

ACTION_START_TIMER

Starts a timer.

EVENT_TIMEOUT will be posted if the timer expires before ACTION_CANCEL_TIMER is called.

Starting a timer when another timer was already started will cancel previous timer and replace it with new timer.

Parameter:

  1. Timer duration in milliseconds.

ACTION_CANCEL_TIMER

Cancels a timer previously started with ACTION_START_TIMER.

No parameter.

Debugging the script

Validating LUA language syntax

The LUA language syntax is automatically validated when saving the script from the Web Portal.

The Web Portal will refuse to save a script that has a LUA language syntax error.

Using log traces

The CAS stack provides the StackLogTrace function that allows the script to print traces through execution.

Traces can be of different levels (more or less verbose). It is recommended to leave traces at various levels through the script so it can be easily debugged "in the field" by simply changing the trace level of the CAS stack while testing a call.

It's also a good practice that the script prints "error" traces to report any error in the log. But be careful not to write error traces in the log for "normal" situations, like calls that fail due to answer timeout for example, as we don't want the logs to be filled out with error traces that correspond to a situation that's actually "normal" on a network.

Viewing traces

All traces printed by the CAS script will be received by the Toolpack tblogtrace application, and written to disk on the host server in the corresponding log file.
Retrieved from "https://docs.telcobridges.com/mediawiki/index.php?title=CASr1_scripting&oldid=24378"
Personal tools