2 Testing Calls and Messages Using the slpit Utility

This chapter describes how to use the Oracle Communications Convergent Charging Controller slpit utility.

About the slpit Utility

The slpit utility sends and receives Intelligent Network Application Part (INAP) operations and acts as an interface to the Transaction Capabilities Application Part (TCAP) protocol.

About the SS7 Protocol Suite gives a brief overview of the Signalling System 7 (SS7) protocol suite, of which INAP and TCAP are a part.

The slpit utility processes operations from an input text file rather than a real network. The input text file is called the script file and it is a file that you create. In the script file, you add commands and send and receive operations that define the call sequences that you want to test. See "Creating the slpit Script File" for more information.

The utility parses the responses from the test application and compares them to the responses that the script file expects.

There are two ways to run the slpit utility. In the first way, it replaces the m3uaIf process so that slpit communicates with slee_acs and xmsTrigger but does not send anything over the IP network. This allows you to test the higher layers of a protocol but does not include any processing that would normally happen inside m3uaIf.

The second way to run the slpit utility allows you to test certain functions that happen in the m3uaIf process. To run the utility this way, you must configure two machines. For example, if you configure machines SLC1 and SLC2, you configure SLC1 exactly like a production SLC, with slee_acs and xmsTrigger talking to m3uaIf. You configure SLC2 with only m3uaIf and the slpit utility on it. See "Running slpit in a Separate SLEE" for information about running the slpit utility in this configuration.

See "About the Convergent Charging Controller Testing Utilities" for an overview of the slpit utility.

Running the slpit Utility

The slpit utility is located in the following directory:

/IN/service_packages/TEST_TOOLS/bin

The basic command for running the slpit utility specifies a service and the name of the script input file. Additional command line options allow you to request validation of the script file, define a global variable, specify the debug output, specify output options, and perform various other actions.

Command Syntax

To run the slpit utility, use one of the following commands:

slpit -k [<option>...] [<script>]
slpit -V
slpit -h

The only command-line option that is typically required to run slpit is -k, which allows you to specify a service key other than the arbitrary default of 101. The following example shows the simplest command to run slpit with a script file:

slpit -k 1 <script file>

You can alternatively provide the script on the command line rather than in a file by using the following syntax where <script> is your script code:

slpit -k 1 < <script>

When you are trying to correct syntax errors in a script, the -c option is useful because it causes slpit to exit immediately after parsing, without running any calls:

slpit -c <script file>

Command-Line Options

The slpit utility takes the following command-line options:

-A

Constructs ANSI SCCP addresses rather than ITU addresses, which is the default.

-a

Act as an application instead of the default interface. For more information, see "Running slpit in a Separate SLEE".

-c

Validate the script file and exit.

-C <CSV_file>

Writes the following values to the specified comma-separated values (CSV) file every ten seconds: the time, calls per second (CPS), and outstanding call count.

-D <name>=<value>

Predefines a global variable with the specified name and value, where <name> is the name of the variable and <value> can be an integer or a double quoted string. Defining a global variable could be useful for making a change to the script easier in the future. For example, you could define the destination phone number and then refer to it in the call definition using the variable. Then, in the future, when you want to define a new call with a different number, you would only need to change the number in one place.

-d <level>

Sets the level of debug output. Valid levels are 0 to 5, with 0 indicating no output and 5 indicating the maximum output.

-g

Makes the utility more tolerant of errors, causing it to continue, if possible, rather than abort.

-h

Prints version and build information, like the -V option, plus a summary of the usage information.

-i <interval>

Report call summary information at the interval specified, which is a number of seconds.

-I <name>

Adds the value of <name> as a suffix to the interface name. This option is required if you run more than one instance of slpit simultaneously in the same SLEE.

-k <key>

Initiates calls with the specified service key value rather than 101, which is the default. The service key values are defined in the /IN/service_packages/SLEE/etc/SLEE.cfg file.

-M <interval>

Used with the -m option to write average timing information per primitive to the CSV file at the interval specified by <interval>. If the specified interval is 0, the average timing information will be written when the script completes. This parameter works only if the slpit script expects a response because the average durations cannot be calculated otherwise.

-m <directory>

Enables logging of timestamps per TCAP primitive for messages sent and received. The utility writes the information by call type to a comma-separated values (CSV) file in the specified directory.

-N

Instructs slpit not to add itself as an interface to the SLEE as the SLEE has added it already.

-n

Makes slpit ignore any received TCAP_CANCEL messages.

-O <flags>

Enables the specified output flags. See "Output Options" for more information.

-o <level>

Sets the level of normal output. Valid levels are 0 to 5, with 0 indicating no output and 5 indicating the maximum level. The default is 3, which produces a reasonable amount of output that is not excessive.

-p <protocol>

Sets the preferred TCAP protocol to use when there is a conflict between the INAP/CAP and MAP tag values, as there is some overlap. Valid values are map, is41, and inap. The default is inap.

-R

Recreates the main dialog, if it no longer exists, using the last received originating reference as a correlation ID. This is required for the CAP3 GPRS message sequence. This option does not work if the -a option is also submitted.

-T

Enables the use of the SLEE Timer interface for delays between sending new requests, or between responses to inbound requests. Without this option, delays are handled by polling. Use of this option is not recommended. The Timer interface is not ideal for this purpose.

-v

Enables verbose output, setting the output level to the maximum. This is equivalent to setting the -o option to 5.

-vv or -v -v

Sets the debug output level to the maximum.

-V

Prints version and build information and then exits.

Output Options

In addition to the overall output level that is controlled by the -o option, you can enable the following more specific output features with the -O option. Most of these options are enabled automatically at various numeric output levels.

calldefntrace

Displays a brief summary of the call definition at each step in the call processing, including an indication of the current step. Automatically enabled at overall output level 4.

callrate

Displays the average call rate achieved before the slpit utility terminates. It calculates the call rate by dividing the total run time by the number of calls started.

callsummary

Prints a table summarizing the number of calls run, the number of successful calls, and the number of partially and totally failed calls. Call types that have at least one aborted call are marked with four asterisks (****); call types with failed calls are marked with a single asterisk (*).

fullcallsummary

Prints a more detailed call summary table than the one produced by the callsummary option. The information is the same as produced by the callsummary option, but the format of the table produced by callsummary is more concise.

triptiming

Records and displays round-trip message times for each call.

sleecheck

Checks for changes in the count of free resource objects in the SLEE at the end of the run. If there are any changes, displays a table of the free counts. The resources can be calls, dialogs, events, and application instances. The rows for resource types that showed a positive delta are marked with a single asterisk (*); those with a negative delta, which indicates a potential memory leak, are marked with four asterisks (****). A positive delta in free resource counts indicates that running one or more calls caused resources to be freed. This is not uncommon with Advanced Control Services (ACS), which is prompted to free a SLEE management event when the first call event arrives.

parsedebug

Enables the extremely verbose debug output for the GNU Bison parser. This option is not automatically enabled at any output level because it is useful primarily when debugging the parser.

Running slpit in a Separate SLEE

When running the slpit utility in a separate SLEE, you must specify the -a and -k command-line options. The -k option must specify the SLEE service key that is assigned to the m3uaIf process in the /IN/service_packages/SLEE/etc/SLEE.cfg file on the machine where the m3uaIf process is running.

Exit Codes

Table 2-1 describes the exit codes that the slpit utility uses to indicate whether the run was successful. The slpit utility writes the exit code to stdout (standard output), which you can redirect to a file if you wish.

slpit -k [<option>...] [<script>] > <outfile>

Table 2-1 slpit Exit Codes

Exit Code	Description
0	Processing completed successfully
1	General or usage error, which usually indicates that the command-line options were not valid.
2	Script parsing error. Either slpit could not read the script file or it encountered a syntax error in the script. The utility displays diagnostics on stderr (standard error output).
4	The initial connection to the SLEE failed, most likely because no SLEE is running.
5	A SLEE entity that slpit required could not be contacted. This can occur when slpit is directed to use the Timer interface for running timers but the interface could not be found.
6	Call creation failed. From most likely to least likely, the possible reasons include: the service key for the call being created is not configured; a resource for a SLEE dialog or for call instances has been exhausted; the SLEE for the service configured on the service key never started or has been stopped.
10	At least one call instance failed. There were no errors that prevented slpit from running to completion, but at least one call instance ended in the FAILED state.
11	At least one call instance aborted. There were no errors that prevented slpit from running to completion, but at least one call instance ended in the ABORTED state.

Managing Script File Processing

The script file is an input file in which you define the call instances that you want the slpit utility to process. Call instances are defined with a set of commands and INAP operations that you specify in sets of send and receive messages. The following example shows the beginning of a call instance definition:

define call assisting_ip_pa {
    SERVICE_NUMBER ?= "555801"

    send {
      initialdp
        calledpartynumber SERVICE_NUMBER
        callingpartynumber "40002000"
        callingpartyscategory 10
        locationnumber "40002000"
        eventtypebcsm analyzedinformation
    }

    receive {
      establishtemporaryconnection
        address "1234"
    }

You start call processing by including a startcall command; for example:

startcall assisting_ip_pa using once

The slpit utility can reference the call types that you define in the script file only after the script file has been parsed. Starting a call creates a call distribution but the distribution does not start creating new call instances until script processing completes.

When you run the slpit utility, it processes all distributions and calls in the script file before stopping.

In general, each call that slpit runs produces one call instance and one or two dialogs in the SLEE. The first dialog is called the main dialog. The second dialog, which will exist only for parts of some calls, is referred to as the assisting dialog.

The first message sent for a call must be an InitialDP or an appropriate TC_BEGIN message. Alternatively, the first action in a call can be a receive message with a cs1InitiateCallAttempt or a cap4InitiateCallAttempt operation.

Note:

Sending an AssistRequestInstructions message creates a second dialog on the same call instance to simulate the dialog between the intelligent peripheral and the service control point (SCP).

When slpit runs in the same SLEE as the application, the correlation ID for each dialog is not required to match. Normally, the TCAP interface would resolve the correlation ID to create the second dialog on the correct call instance.

Note:

Receiving a DisconnectForwardConnection operation is not a special case. The shutdown of the assisting dialog must be explicitly stated.

The slpit utility does little validation to ensure valid call flow. It primarily ensures that the dialog is handled correctly. For example, you do not get a warning if you forget to send an ApplyChargingReport message at the end of a monitored call, but you do get a warning if you do not explicitly terminate a dialog.

Using Distributions

The slpit utility creates a distribution with a list of call types and other parameters that control the launching of calls, which is known as the call rate, and the terminating condition of the distribution, which is generally the number of calls launched. A distribution processes the call types in a round-robin fashion until the completion condition is met. The slpit utility allows you to create the following types of distributions:

• A uniform distribution has an interval and a total call count. The interval specifies the number of seconds that are to elapse before launching each call until the total number of calls is reached. The practical minimum interval is greater than a microsecond but less than a millisecond. The following startcall line, for example, would run the call every 0.5 seconds for a total of 10 times:

  startcall using uniform 0.5 10
  

• A Poisson distribution has a lambda value and a total call count. The lambda value represents the average interval between calls rather than the exact interval.

• The once distribution launches one of each specified call type immediately.

  A once distribution will run through the contents of the given call type once and report a result of SUCCESS, FAILED or ABORT.

The type of distribution is determined by the type of testing that you are performing. You specify the distribution type in the script file using the startcall command, for example:

startcall <id> using <distribution>

So for a script in which you wanted to run only one call that was started with define call 982 {, you would have to start the call with a line like the following:

startcall 982 using once

Using TCAP Primitives

All TCAP messages are primitives although some primitives are not messages. That is, some primitives are transferred only inside the local machine. A TCAP primitive contains zero or more TCAP components and can be one of the types described in Table 2-2.

Table 2-2 Types of TCAP Primitives

Primitive Type	Description
Unidirectional	A single standalone instruction. It is both the start and end of a dialog.
Begin	Begins a dialog with other primitives coming after it.
Continue	A subsequent primitive sent on an existing dialog with other primitives coming after it.
End	The last primitive, which closes its dialog.
Abort	Closes the dialog, possibly due to an error.
Cancel	Closes the dialog when the invoke timer expires without receiving a response. This is an example of a primitive that is not a message.

Receiving Expected Operations

Each received message corresponds to a single TCAP primitive and can contain one or more INAP operations.

The received message must contain the expected INAP operations in the order specified in the receive message section of the call definition. See "Call Definition Commands and Messages" for more information about defining calls.

Note:

Operations can come in one primitive but also can sometimes come in separate primitives, depending on the application or the service.

If the received operation types do not match the expected operation types, the slpit utility aborts the call. If the parameters received for each operation do not match the expected parameters, slpit reports the result of the call as FAILED but continues to process the remaining operations in the call definition. See "About Expressions and Comparators" for more information about parameter values.

Receive operations can time out, which prevents slpit from waiting for call completion when the call has been lost. The global default for timeout is 15 seconds.

When a timeout occurs, you can run a sequence of messages to finish the call. The default action is to abort the call, which closes any open dialogs. Aborting the call is not likely to be the most desirable behavior, however, because it does not cause a TCAP ABORT message to be sent to the application when it is running in the same SLEE. Therefore, if you expect a timeout, you should override the default with a more appropriate action.

Managing Dialogs

The send message includes options that allow you to specify a particular dialog on which to send and also to end a SLEE dialog. You can also use the abort primitive to abort a dialog and use other messages to send an error to ACS.

Specifying a Particular Dialog

To send operations specifically on either the main or assisting dialog, specify the dialog in the send primitive. For example, the following send primitive sends the operations on the assisting dialog:

send assisting {
    <operations>
}

To send on the main dialog, specify main instead of assisting. If you do not specify a dialog, the main dialog is assumed.

Ending a SLEE Dialog

The easiest way to end a SLEE dialog is to include the end option in the last send message in the dialog, as shown in the following example:

send end {
    ...
}

When a call completes, whether it is successful or aborted, the slpit utility automatically closes any open dialogs. If the slpit utility runs in the same SLEE as the application, the application receives only an indication that the dialog is closed and might not handle it in the same way that it does the shutdown of a real TCAP dialog. Therefore, if a call ends with a status of Failed or Okay, and it has dialogs open, the slpit utility displays a warning message. If a call was aborted, you can assume it might have an open dialog.

The slpit utility terminates a dialog when the application sends or receives a terminating event. When the slpit utility ends a dialog, it writes a line of output that indicates the number of messages that are still in the queue. Usually, you can ignore these messages because only internal SLEE messages will be left.

Aborting a SLEE Dialog

You can also explicitly abort a dialog by using the abort message. Specify the open option to abort any open dialogs.

abort  [main | assisting | open]

Completing Calls

Each call instance finishes in one of the following states:

• Aborted

  Processing of the call was interrupted because something was sufficiently wrong that the call could not or should not continue. For example, an attempt was made to send an event when a dialog was no longer available, or a run-time error occurred.

• Failed

  The call was not completely successful but the errors were not sufficient to interrupt the call. The most likely cause is a discrepancy between the received and expected parameters for an operation. The call is failed but allowed to continue because the difference might not be significant.

• Okay

  The call completed without errors.

A call can finish for the following reasons:

• The call process reaches the end of the call definition; the final call state will be either Failed, or Okay depending on whether there were errors in the run.

• A finish call command is run: The call run is immediately finished either with its current state or the override state that is specified in the finish call command.

• The slpit utility encounters a serious error: The utility aborts the call immediately.

Cancelling slpit

You can run multiple calls with slpit, either by specifically defining each call in the script input or by using the uniform or Poisson distribution models.

By default, the slpit utility does not stop generating calls if any call aborts or fails. You can change this behavior by using the cancel after command. You can place this command anywhere outside a call definition in a slpit script. The command has the following forms, each of which is self explanatory:

cancel after none
cancel after abort
cancel after failure
cancel after abort or failure

See "The Call Sequence" for more information about these commands.

You can also allow the slpit utility to continue after an abort or failure until a specified limit is reached.

You can use the following form of the cancel command to cancel a run after a specified number of failures or aborts occurs.

cancel after <number> [abort|failure]

If the number of specified aborts or failures occurs for the call, this command causes the slpit utility to stop call processing and exit. The program accepts either abort or aborts. It also accepts either failure or failures.

The following command specifies a time limit, in seconds, on the number of failed or aborted calls that the slpit utility can receive before it cancels call processing and exits:

cancel after <number> [aborts|failures]in <number> seconds

The program accepts either second or seconds.

Sending an Error

You can send an error to ACS or the application that you are testing by using either the tcapReject message or the error message. See "tcapreject" and "error" for more information.

Creating the slpit Script File

The slpit utility processes a script file that consists of a few commands and a set of INAP send and receive operations, which define the progress of one or more call instances.

Syntax

The following syntax conventions are used to describe the commands and operations that appear in the script file.

[ ]

Square brackets indicate that the enclosed items are optional. For example, the correlationalid parameter in the following operation is optional.

establishtemporaryconnection
  address <digits>
  [correlationid <digits>] 

|

A pipe separates one or more choices. For example, in the following finish call operation, you can optionally specify a final state of aborted, failed, or okay.

finish call [aborted|failed|okay]

...

An ellipsis indicates that an item can be repeated one or more times. In the following example, part must occur at least once but the ellipsis indicates that it can be repeated one or more times.

[variableparts <part> [<part>...]]

<>

Angle brackets indicate a placeholder that you replace with a specific value. The placeholder typically specifies the value's atomic token or basic data type such as <integer>, <string>, or <bcd>.

The slpit utility supports the following three styles of comments, which can appear anywhere in the script file:

• //

  Two forward slashes indicate C++ style comments that can extend to the end of a line. The following line illustrates a full line comment:

  //This is a full line comment        calledpartynumber "049393520" // This is an in-line comment

• #

  A pound character indicates shell-style comments that can extend to the end of a line.

• /*... */

  Text enclosed by asterisks and then forward slashes indicate C-style comments that can extend multiple lines between the beginning and ending delimiters.

Commands

You can include the following commands in the script file in addition to the messages and operations that define a call:

include <file>

Includes the named file in the slpit script, enabling you to include a call sequence that is defined in a separate file. The value of <file> includes the directory path to the file's location.

define call <ID> { <call sequence> }

Defines a set of call sequence messages and operations. The <ID> is an identifier you assign to the call and use to reference the call in other commands. See "The Call Sequence" for more information about <call sequence>.

startcall <ID> [ <ID>...] using <distribution> [<seed>] maxconcurrent <limit>] \ [after <wait_seconds>]

Defines the call types, the number of calls, and the call rate at which to start generating calls. You can start multiple call types and call rates by including multiple startcall commands in the script file.

For all distribution types, you can specify a random seed, which is a number that will be used to initialize the call rate. If not specified, the current clock time is used.

For all distribution types, you can also specify a maximum concurrent number of calls to hold open. This overrides any calls-per-second (CPS) rate and causes a lower CPS rate to be used. This is useful for specifying the maximum load that can be supported for the test system.

For all distribution types, you can specify that the block of calls are to be run after a wait time of a specified number of seconds. This is useful for specifying a stepped call rate, in which you define one startcall for each step, with each one timed to begin after the preceding one has finished.

After the keyword using, you can use the following forms of the command:

uniform <delay> <count>
once
poisson <delay> <count>
poisson <delay> <ramp> <count>

The <delay>, <count>, and <ramp> values must be defined as a number with a decimal point.

The <delay> parameter is the average interval between calls. You can alternatively express this value as calls per second and you can do so by using the cps keyword. For example 10.0 cps is equivalent to a <delay> value of 0.1.

The first form of the poisson command generates calls at random with the average interval between calls specified by the <delay> parameter.

The second form of the poisson command ramps up from zero calls per second to 1/<delay> calls per second, taking about <ramp> seconds to reach the maximum call rate. It then flattens off at that rate.

Call Definition Commands and Messages

The basic format of a call definition looks like this:

define call <ID> {
    <call sequence>
}

Each call type is identified by an ID that can be either a number or a name that starts with a letter and contains only letters, digits, and underscores.

The <call sequence> consists of a set of call definition messages that describe the progress of a call.

The Call Sequence

The call sequence consists of one or more of the following call definition messages:

send [end] [assisting|main] { <message details> ... }
receive [assisting|main] { <reponse details> ... }
allow receive abort assisting
[send] abort [assisting|main|open]
wait <delay>
<ID> = <expression>
<ID> ?= <expression>
waitforcalls <delay> seconds|calls
finish call [aborted|failed|okay]
default timeout none
default timeout <expression> [ { <new call sequence> } ]
close [assisting|main|open]
cancel after [none|abort|fail] [or [abort|fail] ]

send

The slpit send message sends an event containing one or more operations, as determined by the message details, which you can modify through the use of various flags.

send [end] [assisting|main] { <message details> ... }

The end flag causes the messages to be sent as the final event on the dialog. You can use the assisting or main flag to override the dialog on which the message is sent. See "Managing Script File Processing" for more information.

receive

The slpit utility expects to receive an event containing one or more operations as determined by the response details in a receive message, including CS1InitiateAttempt and CAP4InitiateCallAttempt operations. You can use either the assisting or the main flag to override the dialog on which the message is expected to arrive.

receive [assisting|main] { <reponse details> ... }

See "Managing Script File Processing" for more information.

allow receive abort

An allow receive abort message indicates that the slpit utility should expect an abort to arrive from TCAP on the specified dialog at some time in the future. This is different from receive in that the slpit utility does not stop and wait for the abort, but continues processing.

allow receive abort assisting

abort

An abort message causes the slpit utility to send a TCAP abort on the specified dialog or dialogs (the default is the main dialog). Specifying open dialogs causes the slpit utility to abort any dialogs still open for the call.

[send] abort [assisting|main|open]

wait

The wait message causes the slpit utility to pause its processing of the call for a specified delay or until it is interrupted by a received event. You can specify the delay as an integer value representing microseconds or as a floating point value representing seconds. In other words, if the value contains a decimal point, the unit value is seconds. If it does not contain a decimal point, the unit value is microseconds. The following example illustrates the format of the message:

wait <delay>

<ID> = <expression>

The slpit utility uses the <ID> = <expression> definition to evaluate an expression and assign its value to a named variable. You can always assign an expression to ID using <ID> = <expression> but <ID> ?= <expression> only assigns an expression to ID if ID has not been already defined in the script.

<ID> = <expression>
<ID> ?= <expression>

waitforcalls

The waitforcallsmessage causes the slpit utility to pause its processing for a specified number of seconds or until the specified number of new calls started by TCAP_BEGIN requests have finished. You specify the number of seconds to wait or the number of calls to process. The following example illustrates the format of the message:

wait <delay> seconds|calls

finish call

The finish call message finishes the call. You can specify a final state of aborted,failed, or okay to override the established state. For example, finish call okay causes a failed call to be recorded as successful.

finish call [aborted|failed|okay]

default timeout

The default timeout message specifies the default timeout that the slpit utility uses when waiting for a message. If you specify the {<new call sequence>} section, slpit will run the new call sequence when the timeout occurs rather than the lines that follow in the main call definition. If you specify none, it turns off the timeout altogether.

default timeout <expression> [ {<new call sequence>} ]
default timeout none

close

The close message closes the SLEE dialog by way of a DIALOG CLOSED event on the given dialog. If you use the open option, the slpit utility closes all open dialogs.

close [assisting|main|open]

cancel

The cancel after message forces the slpit utility to exit any call immediately when the call fails or is aborted. This feature is most useful when running multiple calls in one slpit run, as when using the uniform and Poisson call distribution models.

This message has the following four formats:

• cancel after none

  This format prevents the slpit utility from exiting the run on the abort or failure of the call.

• cancel after abort

  This format causes the slpit utility to stop processing or generating calls and exit if the call aborts. You can substitute the word aborts for abort.

• cancel after fail

  This format causes the slpit utility to stop call processing and exit if the call fails. You can substitute the words failure, failures, and fails for fail.

• cancel after abort or fail

  This format causes the slpit utility to stop processing or generating calls and exit if the call aborts or fails. You can substitute words as described in the other formats of the cancel message.

You can use multiple cancel messages like this in the same call definition to handle calls that might not fail before a certain command, but could fail after another command.

You can also define a global cancellation strategy outside of a call definition. See "Cancelling slpit" for more information.

About Expressions and Comparators

An expression generates a value that you can use, for example, as the parameter value for a send operation. The simplest form of an expression is a constant value. For example, "5551234" appearing in a slpit script is usually an expression that generates a digit string. More complex expressions are supported:

• Expressions that use the value of a variable by name.

• Expressions that use limited integer arithmetic: subtraction, addition, and multiplication. Integer arithmetic expressions may also contain parentheses for grouping.

For example:

callConnectedElapsedTime(talktime - 20) * 10

You can also specify ranges of numbers as an expression, including the Nature of Address of the generated numbers, which defaults to 3, if not specified. The syntax looks like this:

CLI = RANGE [ (<integer: NoA>) ] "<start of range>" "<end of range>" SEQUENTIAL|RANDOM [DISTINCT|MULTIPLE]

For example,

CLI = RANGE(4) "49900010001" "49900020001" SEQUENTIAL

or

CLI = RANGE "49900010001" "49900020001" RANDOM

Note:

Use the DISTINCT or MULTIPLE option with RANGE for initialdp callingpartynumber messages only.

• MULTIPLE means a calling party can have multiple calls in progress.

• DISTINCT means a calling party can have only one call in progress at a time.

See "initialdp" for more information.

You can obtain values from a text file, such as one for vouchers. For example, the following expression will take a line from vouchers.txt and use that value wherever VOUCHERNUM is used:

VOUCHERNUM=FROM_FILE "vouchers.txt"

If you want to randomly use rows from vouchers.txt, you need to randomize the file before you pass it to the slpit utility. Not having enough rows in your file to match the number of calls causes the slpit utility to produce an error and stop after the numbers run out.

You can obtain INAP numbers from a text file. For example, the APARTY expression will take a line from the APARTY_INAP.txt file and use the value wherever APARTY is used:

APARTY = FROM_INAP_FILE "APARTY_INAP.txt"

If sufficient rows are not available in your file to match the number of calls, the slpit utility produces an error and stops once the numbers have run out. For example:

(5) 111121 screening 1 presind 2 numberplan 3 innorni 0

section of the slpit:

define call  deciseconds_camel {
APARTY = FROM_INAP_FILE "APARTY_INAP.txt"
BPARTY = FROM_INAP_FILE "BPARTY_INAP.txt"
send {
        initialdp       
    appContext         "0,4,0,0,1,0,50,1"
    calledpartynumber     BPARTY
    callingpartynumber    APARTY
    locationNumber   "111144"
}
}

A comparator is a pattern for checking received values such as the parameters in received operations. There are three comparators:

• any

• [=] <expression>

• <comparator> -> <ID>

The any comparator matches any value.

The simplest comparator is an expression that tests for equality. You can optionally precede the expression with = to make the equality test explicit. Because the simplest expression is a constant value, comparators usually test for equality with a simple constant value. It might also be useful to compare to the value of a variable.

The last comparator generates a match or a mismatch based on the result of the comparator, which can be any other comparator. It stores the value being checked in the variable named by <ID>. This allows you to store a received parameter value for later use.

In the syntax description, <integer comparator> indicates that you can include any comparator at that point, but the comparison should be for an integer, so the expression or expressions underlying the comparison should generate integers. The same thing applies for other comparator types like <number comparator>.

<number>:
[(<noa>)] <digits>
[screening <integer>]
[presind <integer>]
[numberplan <integer>]
[innorni <integer>]

For outgoing numbers, the following default values are substituted for any field not specified:

noa=3 screening=0 presind=1 numberplan=1 innorni=0

For incoming numbers, any value is allowed for fields that have not been specified except <digits>.

Call Messages

Call messages are divided into send message operations and receive message operations.

This chapter does not explain the semantics of INAP, MAP, or CAP operations, except where the mapping from the parameters in the script to those in the actual operations is not obvious. Please refer to the relevant standards documentation for the descriptions and procedures for particular operations. See the following standards documents for more information:

• Intelligent Network (IN); Intelligent Network Capability Set 1 (CS1); Core Intelligent Network Application Protocol (INAP); Part 1: Protocol specification. European Telecommunication Standard, ETS 300-374-1, September 1994.

• 3rd Generation Partnership Project; Technical Specification Group Core Network; Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; CAMEL Application Part (CAP) specification (Release 5). 3GPP 29.978 5.4.0 (2003-06).

• Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification (GSM 09.02 version 7.5.0 Release 1998). ETSI TS 100 974 V7.5.0 (2000-07).

In the syntax descriptions in this section, <integer expression> indicates that an expression should appear at that point and the expression should produce an integer. Likewise for the syntax <number expression>. The syntax <integer comparator> indicates that you can include any comparator at that point, but the comparison should be for an integer, so the expression or expressions underlying the comparison should generate integers. Likewise for the syntax <number comparator>. See "About Expressions and Comparators" for more information.

Send Message Operations

You can use the following operations in the send message portion of a call definition.

activityTestResult

This operation is available for use with CAMEL Phase 1. It is the returned result for activityTest. This operation has no parameters.

activityTestResult

alertServiceCentre [<parameters>]

You can use this operation for MAP handling. It sends alerts between MSC and HLR and it has the following parameters in any order:

Table 2-3 alertServiceCenter Parameters

Parameter	Value
msisdn	<number expression>
serviceCentreAddress	<number expression>

alertServiceCenterWithoutResult [<parameters>]

You can use this operation for MAP handling. It sends alerts between MSC and HLR and it has the following parameter in any order:

Table 2-4 alertServiceCenterWithoutResult Parameters

Parameter	Value
msisdn	<number expression>
serviceCentreAddress	<number expression>

anyTimeInterrogation [<parameters>]

This operation queries for information between GSM SCF and HLR. It has the following parameters:

Table 2-5 anyTimeInterrogation Parameters

Parameter	Value	Min.	Max
requestedInfo	(locationInformation | subscriberState)	NA	NA
imsi	<bcd>	NA	NA
msisdn	<bcd>	NA	NA
qmScf	<bcd>	NA	NA
sccp_orig_pc	<integer>	0	65535
sccp_orig_ssn	<integer>	0	255
sccp_orig_tt	<integer>	0	255
sccp_orig_np	<integer>	NA	NA
sccp_orig_noa	<integer>	0	127
sccp_orig_rti	<integer>	0	1
sccp_orig_digits	<digits>	0	15
sccp_dest_pc	<integer>	0	65535
sccp_dest_ssn	<integer>	0	255
sccp_dest_tt	<integer>	0	255
sccp_dest_np	<integer>	0	15
sccp_dest_noa	<integer>	0	127
sccp_dest_rti	<integer>	0	1
sccp_dest_digits	<digits>	NA	NA

Table 2-6 lists the valid combinations of the fields that make up a global title:

Table 2-6 Fields that make up a global title

Global Title Type	Fields
1	noa, digits
2	tt, digits
3	tt, np, digits
4	tt, np, noa, digits

For global title types 3 and 4, the encoding is always binary coded decimal (BCD) that is 1 when there is an odd number of digits and 2 when there is an even number of digits.

applychargingreport

This operation provides feedback from the service switching function (SSF) to the service control function (SCF). It has the following format:

applychargingreport
    thresholdtime <integer>
    endofcallindicator <integer>
    [freecallindicator <integer>]

The following format is available for use with INAP CAMEL extensions:

applychargingreport
    receivingSide <number>
    (timeNoTariffSwitch <number> |
     timeSinceTariffSwitch <number> |
     timeSinceTariffSwitch <number> tariffSwitchInterval <number> )
    [ callActive <number> ]
    [ callReleaseAtTcpExpiry <number> ]

applychargingreportGprs

This operation provides a report from the GPRS SCF to the GSM SSF. It has the following format:

applyChargingReportGprs
    ( gprsvolumeifnotariffswitch <integer> |
      gprsvolumesincelasttariffswitch <integer> [ gprstariffswitchinterval <integer> ] |
      gprstimeifnotariffswitch <integer> |
      gprstimesincelasttariffswitch <integer> [ gprstariffswitchinterval <integer> ] ) 
    <qos-list>
    gprsActive <integer>
    [ gprsPdPid <integer> ]
    [ <ChargingRollover> ]

The <qos-list> section is one or more of the following in any order:

gprsrequestedqos <gprs-info>
gprsnegotiatedqos <gprs-info>
gprssubscribedqos <gprs-info>

The <gprs-info> data is the same as defined in intialDpGprs. See "InitialDpGprs" for more information.

The <ChargingRollover> section is optional, consisting of either:

<TransferredVolumeRollOver> | <ElapsedTimeRollOver

The <TransferredVolumeRollOver> parameter consists of a choice of:

    gprsrovolumeifnotariffswitch <integer> |
    <ro-VolumeIfTariffSwitch>
    

Where <ro-VolumeIfTariffSwitch> consists of a sequence of:

gprsrovolumesincelasttariffswitch <integer> (optional)
gprsrovolumetariffswitchinterval <integer> (optional)

The <ElapsedTimeRollOver> consists of a choice of:

    gprsrotimeifnotariffswitch <integer> |
    <ro-TimeIfTariffSwitch>

Where <ro-TimeIfTariffSwitch> consists of a sequence of:

    gprsrotimesincelasttariffswitch <integer> (optional)
    gprsrotimetariffswitchinterval <integer> (optional)

applyChargingReportAckGprs

This operation has no parameters.

applyChargingReportAckGprs

assistrequestinstructions

This operation is used by the SSF to report a specific charging event to the SCF in response to the ApplyCharging operation. It has the following format:

assistrequestinstructions
[correlationid <digits>]

The message generated by this operation causes the event that contains it to be sent automatically as the first event on a new assisting dialog.

Although you can include the correlationid parameter in the script, it is ignored and overwritten with the value from the most recently received EstablishTemporaryConnection operation.

callinformationreport

This operation sends specific call information to the SCF as requested by a previous callinformationrequest operation. This operation has the following format:

callinformationreport [<parameters>]

A callinformationreport operation should have one or more of the following parameters, appearing in any order, matching the information requested in the relevant callinformationrequest operation:

callattemptelapsedtime <integer expression>
callstoptime <digits>
callconnectedelapsedtime <integer expression>
calledaddress <number expression>
releasecause <cause expression>

The callattemptelapsedtime parameter is measured in seconds while the callconnectedelapsedtime parameter is measured in deciseconds. The callstoptime parameter is a string in the format: YYMMDDHHMMSS.

cap4InitiateCallAttemptResult

This operation sends a response to a cap4InitiateCallAtempt request and has the following format:

cap4InitiateCallAttemptResult [<parameters>]

A cap4IniateCallAttemptResult operation can have one or more of the following parameters, appearing in any order:

offeredCamel4Functionalities <integer expression>
supportedCamelPhases <integer expression>
releaseCallArgExtensionAllowed

The offeredCamel4Functionalities and supportedCamelPhases parameters are 16-bit string values.

collecteduserinformation

This operation has the following format:

collecteduserinformation
digits <digits>

This is not a distinct operation. It represents the result form of the INAP operation, promptAndCollectUserOperation. The digits parameter corresponds to the digitsResponse tag in the result.

entityReleasedGprs

Use this operation when the GPRS session is detached or a PDP context is disconnected and the related event is not equipped for reporting. This operation has the following format:

entityReleasedGprs
gprsReleaseCause <integer>
[ gprsPdPid <integer> ]

entityReleasedAckGprs

This operation has no parameters. It is the returned result for entityReleasedGprs.

error

An error operation has the following format:

error <name> [ invokeId <invoke-ID> ]

An error operation generates a U-ERROR component in the outgoing message. The name parameter determines the error code used. The following values are valid:

cancelled
cancelfailed
etcfailed
impropercallerresponse
missingcustomerrecord
missingparameter
parameteroutofrange
requestedinfoerror
systemfailure
taskrefused
unavailableresource
unexpectedcomponentsequence
unexpecteddatavalue
unexpectedparameter
unknownlegid

Some errors would typically have additional error codes, but the slpit utility supports only the ones listed here.

The <invoke-ID> value is from the last received INVOKE component, unless you specifically define it with the invokeId parameter.

eventreportbcsm

This operation notifies the SCF of a call-related event that was requested by the SCF in a previous RequestReportBCSMEvent operation. Examples of call-related events are busy and no answer. This operation has the following format:

eventreportbcsm [<event>...]

The event parameter has the following format:

eventtypebcsm <type>
[misccallinfo <misccallinfo> | monitormode <mode>]
[legid <legid> | ( <integer> )]
[eventspecificinfo <info>]

The <mode> parameter has one of the following values:

interrupted
notifyAndContinue
transparent

The <legid> parameter has one of the following values:

[sendingsideid] <legtype>
[receivingsideid] <legtype>

The <legtype> parameter has one of the following values:

ltleg1
ltleg2

Event-specific information includes the following:

busycause <cause>
releasecause <cause>
failurecause <cause>
calledpartynumber <number>

eventReportGprs

This operation notifies the GSM SCF of a GPRS session or PDP context related events:

eventReportGprs
gprsEventType <number>
[ gprsPdPid <integer> ]

eventReportAckGprs

This operation has no parameters.

eventReportSms

This operation notifies the GSM service control function (gsmSCF) of a previously requested short message related event. This message has no parameters.

informServiceCentre

This operation is required for SMS gateway procedures between MSC and HLR. This message has the following format:

informServiceCentre [<parameters>]

The parameters consist of the following values:

storedMSISDN <number expression>

initialdp

This operation is used after a trigger detection point (TDP) to issue a request for service. This message has the following format:

initialdp [<parameters>]

An initialdp message can have any of the following parameters, specified in any order:

calledpartynumber <number expression>
originalcalledpartynumber <number expression>
callingpartynumber <number expression>
redirectingpartynumber <number expression>
locationnumber <number expression>
additionalcallingpartynumber <number expression>
callingpartyscategory <categoryvalue or number>
callingpartyspin <digits>
origredirreason <integer> redirindicator <integer>
eventtypebcsm <type>
appcontext <string>
extension <integer> <type> <integer> <digits> <integer>
extension <integer> <type> <integer> <digits>
idp_sccp_orig_pc <integer> // 0 - 65535
idp_sccp_orig_ssn <integer> // 0 - 255
idp_sccp_orig_tt <integer> // 0 - 255
idp_sccp_orig_np <integer> // 0 - 15
idp_sccp_orig_noa <integer> // 0 - 127
idp_sccp_orig_rti <integer> // 0 or 1
idp_sccp_orig_digits <digits>
idp_sccp_dest_pc <integer> // 0 - 65535
idp_sccp_dest_ssn <integer> // 0 - 255
idp_sccp_dest_tt <integer> // 0 - 255
idp_sccp_dest_np <integer> // 0 - 15
idp_sccp_dest_noa <integer> // 0 - 127
idp_sccp_dest_rti <integer> // 0 or 1
idp_sccp_dest_digits <digits>

Note:

Use the DISTINCT or MULTIPLE option with RANGE for initialdp callingpartynumber messages only. See "initialdp".

The following parameter is available for UCP handling:

AspID <string>

The following parameters are available for use with INAP CAMEL extensions:

iMSI <bcd>
countryCode <digits> networkCode <digits> locationAreaCode <integer> [ cellID <integer> ]
[ bearerCapCodingStandard <number> bearerCapITC <number> [ bearerCapTransferMode <number> bearerCapITR <number> bearerCapUIProtol <number> ]]
hlCharacteristicsId <number>
calledPartyBCDNumber [ ( <integer> ) ] "number" [ numberPlan <integer> ]
vlrNumber [ ( <integer> ) ] "number" [ numberPlan <integer> ]
ageoflocationinfo <digits>
subscriberstate <digits>
locationnumberlocationinfo [ ( <integer> ) ] "number" [ numberPlan <integer> ]
extBearerService <hex digits>
extTeleService <hex digits>
callreference <string>
[ callForwardingSSPending ]
iMEI <bcd>
[ Eutrancgimcc <digits> Eutrancgiimnc <digits> Eutrancgi <integer> ]      
[Taidmcc <digits> Taidmnc <digits> Taid <integer> ]

The countryCode and networkCode values can be only three digits long.

The Eutrancgimcc, Eutrancgimnc, Taidmcc, and Taidmnc values can be only three digits long.

Bearer capability fields are optional and are divided in two stages as shown above. If the second stage is not present, the following default values are assigned: bearerCapTransferMode = BC_TM_CIRCUIT (0x0), bearerCapITR = BC_ITR_64_KBIT_S (0x10) and bearerCapUIProtol = BC_UIL1_NOT_PRESENT (0xff)

The following values are available for Bearer Capability fields:

Table 2-7 bearerCapcodingStandard Bearer Capability Values

Constants	Value
BC_CS_ITU_T	0x00
BC_CS_ISO_IEC	0x01
BC_CS_NATIONAL	0x02
BC_CS_NETWORK	0x03

Table 2-8 bearerCapITC Bearer Capability Values

Constants	Value
BC_ITC_SPEECH	0x00
BC_ITC_UDI	0x08
BC_ITC_RDI	0x09
BC_ITC_3_1_KHZ_AUDIO	0x10
BC_ITC_UDI_TA	0x11
BC_ITC_7_KHZ_AUDIO	0x11
BC_ITC_VIDEO	0x18

Table 2-9 bearerCapTransferMode Bearer Capability Values

Constants	Value
BC_TM_CIRCUIT	0x0
BC_TM_PACKET	0x2

Table 2-10 bearerCapITR Bearer Capability Values

Constants	Value
BC_UIL1_ITU_V110_I460_X30	0x01
BC_UIL1_G711_U_LAW	0x02
BC_UIL1_G711_A_LAW	0x03
BC_UIL1_G721_32_KBIT_S	0x04
BC_UIL1_H221_H242	0x05
BC_UIL1_H223_H245	0x06
BC_UIL1_NON_ITU_SRA	0x07
BC_UIL1_ITU_V120	0x08
BC_UIL1_X31_HDLC	0x09
BC_UIL1_NOT_PRESENT	0xff

Table 2-11 bearerCapUIProtol Bearer Capability Values

Constants	Value
BC_UIL1_ITU_V110_I460_X30	0x01
BC_UIL1_G711_U_LAW	0x02
BC_UIL1_G711_A_LAW	0x03
BC_UIL1_G721_32_KBIT_S	0x04
BC_UIL1_H221_H242	0x05
BC_UIL1_H223_H245	0x06
BC_UIL1_NON_ITU_SRA	0x07
BC_UIL1_ITU_V120	0x08
BC_UIL1_X31_HDLC	0x09
BC_UIL1_NOT_PRESENT	0xff

InitialDpGprs

When a trigger is detected at a detection point in the general GPRS state machines, this operation requests instructions from the GSM SCF. This message has the following format:

initialDpGprs
gprsEventType <integer>
gprsMsisdn <number expression>
gprsImsi <number expression>
gprsOriginatingReferenceNumber <number expression>
[ gprsEndUserAddress <PdpTypeOrganisation> <PdpTypeNumber> [ <address byte> ] ]
[ gprsrequestedqos <qos-info> ]
[ gprssubscribedqos <qos-info> ]
[ gprsnegotiatedqos <qos-info> ]
[ gprsaccesspointname <string> ]
[ gprschargingid <integer> ]
[ gprslocationinformation
gprsmobilecountrycode <bcd>
gprsmobilenetworkcode <bcd>
gprsmobilelocationareacOde <bcd>
gprscellidentity <integer>
gprspdpinitiationtype <integer> ]
[ gprsggsnaddress <integer> [ <integer> ] ]
[ sgsnNumber <number expression> ]

The <qos-info> variable can have one of the following parameter values, all of which are integers:

Table 2-12 InitialDpGprs

Parameter	Min	Max
gprsqosprioritylevel	0	255
gprsqosdeloferrsdu	0	7
gprsqosdelorder	0	3
gprsqostrafficclass	0	7
gprsqosmaxsdusize	0	255
gprsqosmaxbrforuplink	0	255
gprsqosmaxbrfordownlink	0	255
gprsqossduerrratio	0	15
gprsqosresidualber	0	15
gprsqostrafhlingpri	0	3
gprsqostransferdelay	0	63
gprsqosguabrforuplink	0	255
gprsqosguabrfordownlink	0	255

InitialDpSms

After it detects a TDP-R, the SMS SSF uses this operation to request instructions from the GSM SCF to complete the short-message submission to the SMSC or the short message delivery to the served subscriber. This message has the following format:

initialDpSms
[<parameters>]

An initialDpSms message can have the following parameters in any order:

callingPartyNumber <number expression>
destinationSubscriberNumber <number expression>
idp_sccp_orig_pc <integer> // 0 - 65535
idp_sccp_orig_ssn <integer> // 0 - 255
idp_sccp_orig_tt <integer> // 0 - 255
idp_sccp_orig_np <integer> // 0 - 15
idp_sccp_orig_noa <integer> // 0 - 127
idp_sccp_orig_rti <integer> // 0 or 1
idp_sccp_orig_digits <digits>
idp_sccp_dest_pc <integer> // 0 - 65535
idp_sccp_dest_ssn <integer> // 0 - 255
idp_sccp_dest_tt <integer> // 0 - 255
idp_sccp_dest_np <integer> // 0 - 15
idp_sccp_dest_noa <integer> // 0 - 127
idp_sccp_dest_rti <integer> // 0 or 1
idp_sccp_dest_digits <digits>
vlrNumber [ ( <integer> ) ] "number" [ numberPlan <integer> ]
countryCode <digits> networkCode <digits> locationAreaCode <integer> [ cellID <integer> ]
mscAddr <digits>
smscAddr <digits>

mergeCallSegmentResult

This message has the following format with no parameters:

mergeCallSegmentResult

moForwardSm

This service forwards mobile-originated short messages between the serving mobile switching center (MSC) or the SGSN and the SMS internetworking MSC. This message has the following format:

moForwardSm [<parameters>]

For MAP version 3, this is a mobile-originated Forward-SM message, which is distinct from the mtForwardSm message. For MAP versions 1 and 2, this operation is a Forward-SM and it can originate or terminate from a mobile device, depending on the type of PDU in the SM-RP-UI.

A Forward-SM message has the following parameters in any order:

MapVersion <integer>

SegmentedBegin
SegmentedBody

imsiOA <number expression>  //optional, only valid for MAP version 3
privateExtension <comma separated object ID string> <integer ASN.1 tag> <hex value> // optional, only valid for MAP version 3
countryCode <digits> networkCode <digits> locationAreaCode <integer> cellID <integer>  // optional, valid for MAP versions 2 and 3

The countryCode, networkCode, locationAreaCode, and cellID parameters are used to construct the global cell ID. The countryCode and networkCode values can be only three digits long.

The SM_RP_DA field can be service center (MO) on an IMSI (MT):

imsi <number expression> (optional for MAP v2/v3 segmented body)
lmsi <number expression> (optional)
ServiceCentreAddressDA <number expression>

In a MAP version 2 or 3 segmented MT message, the imsi parameter is omitted in segments after the initial segment. If it is omitted, the MT message is encoded with the noSM_RP_DA parameter set.

The SM_RP_OA field can be an MSISDN (MO) or a service center (MT):

msisdn <number expression>
ServiceCentreAddressOA <number expression> (optional for MAP v2/v3 segmented body)

In a MAP version 2 or 3 segmented MT message, the originating service center is omitted in segments subsequent to the initial segment. If it is omitted, the MT message is encoded with the noSM_RP_OA parameter set.

Depending on the MAP version, the SM_RP_UI field can contain one of the following PDUs:

Table 2-13 PDUs

PDU	MAP Version	Comment
SMS-SUBMIT	1, 2, and 3	NA
SMS-DELIVER	1 and 2	In MT-ForwardSM for version 3
SMS-STATUS-REPORT	2	In MT-ForwardSM for version 3)

The type of PDU is determined by the message type indicator, TP-MTI:

TP_MTI <number>

For an SMS-SUBMIT PDU, with TP-MTI=1, the following parameters are available:

TP_VPF <number>
replyPath
requestStatusReport
TP_MR <number>
TP_DA [ToN] <string> | TP_DA <number expression>
TP_DCS <number>
TP_VP { <1 or 7 octets (numbers)> }
userDataHeader { <number> <number> ... }
userDataText <string>

Note:

For TP_DA, alphabetic characters (non-telephony digits) are allowed only if ToN = 5 (alphanumeric).

For an SMS-DELIVER (TP-MTI=0), the following parameters are available:

moreMessages <0-1>
replyPath
TP_OA [ToN] <string>
TP_DCS <number>
userDataHeader { <number> <number> ... }
userDataText <string>

Note:

For TP_OA, alphabetic characters (non-telephony digits) are allowed only if ToN=5 (alphanumeric).

For an SMS-STATUS-REPORT (TP-MTI=2), the following parameters are available:

moreMessages <0-1>
TP_MR <number>
TP_RA [ToN] <string>
TP_DCS <number>
userDataHeader { <number> <number> ... }
userDataText <string>

Note:

For TP_RA, alphabetic characters (non-telephony digits) are allowed only if ToN=5 (alphanumeric).

Table 2-14 Min and Max for Parameters

Parameter	Value	Min	Max
sccp_orig_pc	<integer>	0	65535
sccp_orig_ssn	<integer>	0	255
sccp_orig_tt	<integer>	0	255
sccp_orig_np	<integer>	0	15
sccp_orig_noa	<integer>	0	127
sccp_orig_rti	<integer>	0	1
sccp_orig_digits	<digits>	0	15
sccp_dest_pc	<integer>	0	65535
sccp_dest_ssn	<integer>	0	255
sccp_dest_tt	<integer>	0	255
sccp_dest_np	<integer>	0	15
sccp_dest_noa	<integer>	0	127
sccp_dest_rti	<integer>	0	1
sccp_dest_digits	<digits>	0	15

There must be exactly one each of imsi, lmsi, ServiceCentreAddressDA, and noSM_RP_DA. There must be exactly one of msisdn, ServiceCentreAddressOA, noSM_RP_OA, and imsiOA. You can use the imsiOA parameter only for MAP3.

If the SegmentedBegin parameter is present, the only other parameters allowed are MapVersion and IMSI. The result is that a TCAP_BEGIN message is sent with the appropriate application context but with no component (the User Information part of the TCAP_BEGIN message contains a MAP-OPEN with an optional IMSI in it.) If the IMSI parameter is present in the SegmentedBegin, the RP-DA in the ForwardSM should be a LMSI, but this is not enforced by the slpit utility.

If the SegmentedBody parameter is present, a normal moForwardSM operation is sent (in a Continue) but with no application context. You must always pair SegmentedBegin and SegmentedBody operations with appropriate MAP versions and a receive{}message between them.

The following segmentation scenarios are valid.

• IMSI and LMSI parameters in segmented message:

  Table 2-15 IMSI and LMSI Parameters Segmentation Scenario

  Primitive	MAP-OPEN	ForwardSM RP-DA	Segment
  TCAP_BEGIN	imsi	N/A	Begin
  TCAP_CONTINUE	N/A	lmsi	Body #1
  TCAP_CONTINUE	N/A	noSM-RP-DA	Body #2

• IMSI only in a segmented message:

  Table 2-16 IMSI-only Parameters Segmentation Scenario

  Primitive	MAP-OPEN	ForwardSM RP-DA	Segment
  TCAP_BEGIN	empty	N/A	Begin
  TCAP_CONTINUE	N/A	Imsi	Body #1
  TCAP_CONTINUE	N/A	noSM-RP-DA	Body #2

• IMSI and LMSI in a non-segmented message:

  Table 2-17 IMSI and LMSI Non-Segmentation Scenario

  Primitive	MAP-OPEN	ForwardSM RP-DA	Segment
  TCAP_BEGIN	imsi	imsi	N/A

• IMSI only in a non-segmented message:

  Table 2-18 IMSI-only Non-Segmentation Scenario

  Primitive	MAP-OPEN	ForwardSM RP-DA	Segment
  TCAP_BEGIN	empty	imsi	N/A

You may specify either the userDataheader or the userDatatext or both. You must specify the header byte by byte, and in decimal or hex (with 0x as a prefix) – for example, userDataHeader {0x17 0x34}. The header is automatically prefixed with a one-byte length field.

The userDatatext parameter will be added to the packet after the userDataheader parameter in either GSM 7-bit (default) or Unicode UCS2/UTF16 (big endian, meaning the most significant bytes in multi-byte data types are stored first) or binary, depending on the value of the data coding scheme TP_DCS.

The slpit utility does not support compressed user data.

You can specify TP_VF (validity period format) and TP_VP (validity period). See GSM 03.40 v7.5.0 sections 9.2.3.3 and 9.2.3.12 for encoding details. For example:

• tp_vf 0

  VPF of 0, or not specified, means no validity period format.

• tp_vf 1

  Enhanced format (new to MAP version 3) tp_vp {0x42 0x80 0x00 0x00 0x00 0x00 0x00}. Relative; 128 (0x80) seconds and single-shot=true.

• tp_vf 2

  Relative format tp_vf { 128 }, where 128 is decimal and means 645 minutes.

• tp_vpf 3

  Absolute format tp_vp { 0x40 0x50 0x32 0x61 0x10 0x20 0x00}. 2004-05-23 16:01:02 GMT.

mtForwardSM

This operation is a MAP version 3 mobile-terminated Forward-SM and is available for use with MAP. It forwards mobile terminated short messages between the gateway mobile switching center (MSC) and the servicing MSC or the SGSN.

mtForwardSm [<parameters>]

An mtForwardSm operation should have the following parameters, appearing in any order:

MapVersion <integer>  // only 3 is valid
SegmentedBegin
SegmentedBody

The SM_RP_DA field must be an IMSI number for MT-ForwardSM if the message is not getting segmented. If the message is segmented, the SM_RP_DA can be a LMSI, in which case the segmentedBegin should contain the IMSI:

imsi <number expression>   // optional in the SegmentedBegin
lmsi <number expression>   // optional in the SegmentedBody

In a segmented MT-ForwardSM operation, the IMSI is omitted in segments following the initial segment. If it is omitted, the operation is encoded with the noSM_RP_DA parameter set.

The SM_RP_OA field must be a service center for MT-ForwardSM:

ServiceCentreAddressOA <number expression> (optional)

In a segmented MT-ForwardSM operation, the originating service center is omitted in segments following the initial segment. If it is omitted, the operation is encoded with the noSM_RP_OA parameter set.

The SM_RP_UI field must contain an SMS-DELIVER or an SMS-STATUS-REPORT for MT-ForwardSM. For more information, see "moForwardSm".

sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

If SegmentedBegin is present, the only other parameters allowed are MapVersion and IMSI. This results in a TCAP_BEGIN being sent with the appropriate application context but no component (the User Information part of the TC_BEGIN contains a MAP-OPEN with an optional IMSI in it). If the IMSI is present in the SegmentedBegin, the RP-DA in the ForwardSM should be a LMSI, but this is not enforced by the slpit utility.

If SegmentedBody is present, a normal moForwardSM is sent in a CONTINUE but with no application context. You are responsible for always pairing SegmentedBegin and SegmentedBody operations, with matching MapVersions and a receive{} message between them.

See the segmentation scenarios in the "moForwardSm" section for more information.

You may specify either the userData header or the text or both. You must specify the header byte by byte in decimal or hex (with a 0x prefix) – for example, userData { 0x02 0x17 0x34}. The first number in the user data header should be the length, in bytes, of the remainder of the user data header. In this case, 0x02 indicates that there are two more bytes to follow in the header.

Any user data text will be copied after the user data header, with bit padding inserted to align to a septet boundary.

readyForSM

This operation is available for MAP handling. It is used between the message switching center (MSC) and the VLR and between the VLR and the HLR. If a subscriber has available memory, the MSC initiates this service and the VLR indicates this condition to the HLR. If a subscriber, whose message waiting flag is active in the VLR, has radio contact in the MSC, the VLR initiates this service.Likewise, if a subscriber has available memory, the SGSN initiates this service to indicate this to the HLR. Also, if a subscriber whose message waiting flag is active in the SGSN has radio contact in the GPRS, the SGSN initiates this service.

readyForSM [<parameters>]

A readyForSM operation should have the following parameters, appearing in any order.

imsi <bcd>
alertReason <alertReason> | <number>

The <alertReason> value can be one of the following:

ms_Present
memoryAvailable

reportSMDeliveryStatus

This operation is available for MAP handling. It is used by the message switching center (MSC) to set the message waiting data into the HLR or to inform the SLR of a successful short message (SM) transfer after polling.

reportSMDeliveryStatus [<parameters>]

A reportSMDeliveryStatus operation should have the following parameters, appearing in any order.

msisdn <number expression>
serviceCentreAddress <number expression>
smDeliveryOutcome <smDeliveryOutcome> | <number>

The <smDeliveryOutcome> value can be one of the following:

memoryCapacityExceeded
absentSubscriber
successfulTransfer

sendRoutingInfoForSm

This operation is for MAP handling and has the following format.

sendRoutingInfoForSm [<parameters>]

A sendRoutingInfoForSm operation should have the following parameters, appearing in any order.

MapVersion <number>
msisdn <number expression>
AttemptDelivery <0-1>
ServiceCentreAddress <number expression>
(optional parameters)
MessageTypeIndicator <number>
OriginatingSmeAddr <number expression>
GprsSupport <0-1>
sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

sendRoutingInformation

This operation is available for MAP handling and has the following format:

sendRoutingInformation [<parameters>]

A sendRoutingInformation operation should have the following parameters, appearing in any order:

interrogationType <0-1>
gmscAddress <number expression>
msisdn <number expression>
(optional parameters)
sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

An interrogationType value of 0 indicates a basic call; a value of 1 indicates a forwarding call.

smsNotification

This operation is available for IS-41 support. Your application can expect to receive one of these from an MSC when a SME comes back online after sleeping through a direct delivery attempt.

smsNotification [<parameters>]

An smsNotification operation can have the following parameters.

smsnot_MIN <bcd-string> // 10 digit number
smsnot_ESN <integer> <integer> // 0..2ˆ8, 0..2ˆ24

smsNotificationResult

The response to an smsNotification operation does not contain any parameters.

smsNotificationResult

locationRequest

This operation is available for IS-41 support and has the following format:

locationRequest [<parameters>]

A locationRequest operation has the following parameters:

locreq_BID <integer> <integer> <integer> <integer> // 0..2ˆ16, 0..2ˆ8, 0..2ˆ24, 0..2ˆ8
locreq_DIGITS <integer> <integer> <bcd-string>
locreq_MSCID <integer> <integer> // 0..2ˆ16, 0..2ˆ8
locreq_SYSTEMMYTYPECODE <integer>
sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

The locreq_BID (Billing ID) parameters are: Market ID, Switch Number, ID Number, and Segment Counter. The locreq_DIGITS parameters are: Type of Digits, Nature of Number, and BCD Digits. The locreq_MSCID parameters are: Market ID, and Switch Number.

The locreq_SYSTEMMYTYPECODE parameter sets VENDOR_IDENTIFIER_, which is the only content of locreq_SYSTEMMYTYPECODE.

You can use the following values for VENDOR_IDENTIFIER:

VENDOR_IDENTIFIER_NotUsed = 0,
VENDOR_IDENTIFIER_EDS = 1,
VENDOR_IDENTIFIER_Astronet = 2,
VENDOR_IDENTIFIER_LucentTechnologies = 3,
VENDOR_IDENTIFIER_Ericsson = 4,
VENDOR_IDENTIFIER_GTE = 5,
VENDOR_IDENTIFIER_Motorola = 6,
VENDOR_IDENTIFIER_NEC = 7,
VENDOR_IDENTIFIER_NORTEL = 8,
VENDOR_IDENTIFIER_NovAtel = 9,
VENDOR_IDENTIFIER_Plexsys = 10,
VENDOR_IDENTIFIER_DigitalEquipmentCorp = 11,
VENDOR_IDENTIFIER_INET = 12,
VENDOR_IDENTIFIER_Bellcore = 13,
VENDOR_IDENTIFIER_AlcatelSEL = 14,
VENDOR_IDENTIFIER_Tandem = 15,
VENDOR_IDENTIFIER_QUALCOMM = 16,
VENDOR_IDENTIFIER_Aldiscon = 17,
VENDOR_IDENTIFIER_Celcore = 18,
VENDOR_IDENTIFIER_TELOS = 19,
VENDOR_IDENTIFIER_Stanilite = 20,
VENDOR_IDENTIFIER_CoralSystems = 21,
VENDOR_IDENTIFIER_SynacomTechnology = 22,
VENDOR_IDENTIFIER_DSC = 23,
VENDOR_IDENTIFIER_MCI = 24,
VENDOR_IDENTIFIER_NewNet = 25,
VENDOR_IDENTIFIER_SemaGroupTelecoms = 26,
VENDOR_IDENTIFIER_LGInformationAndCommunications = 27,
VENDOR_IDENTIFIER_CBIS = 28,
VENDOR_IDENTIFIER_Siemens = 29

locationRequestResult

This is the response to a locationRequest operation.

locationRequestResult [<parameters>]

A locationRequestResult operation has the following parameters:

smsreq_ESN <integer> <integer> // 0..2ˆ8, 0..2ˆ24
smsreq_MIN <integer> // must be 10 digits
smsreq_MSCID <integer> <integer> // 0..2ˆ16, 0..2ˆ8

The MSCID, ESN and MIN parameters are mandatory in the response. However, if the ESN is unknown, it is set to "0 0"; if the MIN is unknown it is set to "0000000000".

smsRequest

This operation is available for IS-41 support. Your applications should never receive one of these. It is included only to assist in testing scenarios in which the service control point, acting as an SMSC, receives an unexpected operation.

smsRequest [<parameters>]

A smsRequest operation can have the following parameters.

smsreq_MIN <bcd-string> // 10 digit number
smsreq_IMSI <number expression>
smsreq_MDN <integer> <integer> <bcd-string>
smsreq_ESN <integer> <integer> // 0..2ˆ8, 0..2ˆ24
smsreq_notificationIndicator <integer> // 0..255
smsreq_teleserviceIdentifier <integer> // 0..65535
sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

The smsreq_MDN parameters are: Type of Digits, Nature of Number, and BCD Digits.

smsRequestResult

This is the response to an smsRequest operation.

smsRequestResult [<parameters>]

An smsRequest operation can be an Ack or a Nack. Acks contain an address, and can also return ESN data. Nacks may specify a value for the accessDeniedReason parameter.

smsreq_ESN <integer> <integer> // 0..2ˆ8, 0..2ˆ24
smsreq_address <integer> <integer> <bcd-string> // NoN, NPI, digits
smsreq_accessDeniedReason <integer> // 0..255

smsDeliveryPointToPoint

This operation is available for IS-41 support. You can use this to deliver a short message over IS-41.

smsDeliveryPointToPoint [<parameters>]

The slpit utility supports three text-based teleservices, CDMA 4098, CDMA 4101, and TDMA 32513 and two use cases for the text message. The first is human-readable text with an optional header. The text is encoded as 7-bit ASCII for CDMA or IRA for TDMA. (The actual encoding step is independent of the smdpp_userDataEncoding parameter.) You may not specify both text and header for a TDMA message.

The CDMA text plus header has the following format:

tag length encoding num_fields header padding-1 text padding-2

The text and header fields can have the following values:

Table 2-19 smsDeliveryPointToPoint values

Field	Value
tag	0x01
length	The number of octets after this one.
encoding	The first five bits of the smdpp_userDataEncoding value. Note that everything after this is shifted 3 bits to the left.
num_fields	The number of characters (7 or 8-bit) after this octet.
header	Zero or more octets of GSM user-data-header. This is taken directly from the smdpp_userDataHeader value.
padding-1	Padding required to make the header end on a septet boundary. This is only done if the encoding is 2 (7-bit ASCII, default) or 3 (IA5).
text	Encoded message text. This will always be 7-bit ASCII.
padding-2	Padding required to make this whole block end on an octet boundary.

The TDMA text has the following format:

length type padding text

The fields can have the following values:

Table 2-20 TDMA values

Field	Value
length	The number of octets following this one.
type	The first 5 bits of smdpp_userDataEncoding.
padding	3 bits of padding, so that text starts on an octet boundary.
text	Text as something resembling IRA, with each character 7 bits wide but stored in an octet with the high bit off.

With the second use case for text messaging, you cannot use the human-readable text parameter (smdpp_userDataText); you must put the raw bytes of the message into the header (smdpp_userDataHeader). The header and text are packed into the message for the different use cases as follows:

The CDMA header only has the following format:

tag length encoding num_fields data padding

These fields have the following values:

Table 2-21 CDMA header values

Field	Value
tag	NA
length	NA
encoding	NA
num_fields	NA
data	The octets specified in smdpp_userDataHeader shifted 3 bits to the left.
padding	Empty bits required to bring the block to an octet boundary.

The TDMA header has the following format:

length type padding data

These fields have the following values:

Table 2-22 TDMA header values

Field	Value
length	NA
type	NA
padding	NA
data	The octets specified in the smdpp_userDataHeader

Note that the translation of text from the human-readable input form to ASCII or IRA is not perfect. When in doubt, try using the header to set the raw data.

A smsDeliveryPointToPoint may have the following parameters.

Table 2-23 smsDeliveryPointToPoint Parameters

Parameter	Type	Value
smdpp_teleservice	<integer>	4098, 4100, 32513
smdpp_MIN	<bcd-string>	10 digit
smdpp_ESN	<integer>< integer>	0..28, 0..224
smdpp_origAddr	<integer>< integer><bcd-string>	NoN, NPI, digits
smdpp_origOrigAddr	<integer>< integer><bcd-string>	NoN, NPI, digits
smdpp_destAddr	<integer>< integer><bcd-string>	NoN, NPI, digits
smdpp_origDestAddr	<integer>< integer><bcd-string>	NoN, NPI, digits
smdpp_messageCount	<integer>	0..28
smdpp_notInd	<integer>	0..28
smdpp_chargeInd	<integer>	0..28
smdpp_userDataEncoding	<number>	NA
smdpp_userDataHeader	{<number>...}	NA
smdpp_userDataText	<string>	NA
CDMA	{ <parameters> }	NA
TDMA	{ <parameters> }	NA

The smdpp_teleservice parameter is mandatory, and must be set according to IS-41-D before the TDMA or CDMA sections can be used. For more information about these parameters, please consult TIA/EIA-41-D-1997 (IS-41), 3GPP2 C.S0015-A (CDMA) and TIA/EIA-136-710-C (TDMA).

Each teleservice may place a particular restriction on the data specified. These restrictions aren't generally enforced by the slpit utility, because you might want to send bad data. The following are common restrictions:

• CDMA 4098

  No userdata header present.

• CDMA 4100

  Encoding type is 0.

• TDMA 32513

  No userdata header present.

The following lists show the common encoding values:

• CDMA

  Table 2-24 CDMA values

  Value	Name	Width
  0	octet-unspecified	8
  1	Extended protocol message	NA
  2	7-bit ASCII (default)	7
  3	IA5	7
  4	UNICODE	16
  5	Shift JIS	8 / 16
  6	Korean	8 / 16
  7	Latin/Hebrew	8
  8	Latin	8

• TDMA

  Table 2-25 TDMA values

  Value	Name	Width
  1	IRA	7
  2	User specific	8
  3	Latin	8
  5	Latin/Hebrew	8

If you are using the CDMA teleservices, you can specify the following parameters in the CDMA subsection:

Table 2-26 CDMA parameters

Parameter	Type	Value
smdpp_messageId	<integer><integer><boolean>	0..24, 0..216, true/false
smdpp_validityPeriod	<integer>	See 4.5.6.1 of 3GPP2 CS 15-A
smdpp_validityPeriod	<string>	YYMMDDhhmmss
smdpp_deferredDeliveryTime	<integer>	See 4.5.6.1 of 3GPP2 CS 15-A
smdpp_deferredDeliveryTime	<string>	YYMMDDhhmmss
smdpp_priorityInd	<integer>	0..3
smdpp_privacyInd	<integer>	0..3
smdpp_languageInd	<integer>	0..255
smdpp_alertOnDelivery	<integer>	0..3
smdpp_DAKRequested	<boolean>	true/false
smdpp_MAKRequested	<boolean>	true/false
smdpp_RAKRequested	<boolean>	true/false

If you are using the TDMA teleservice, you can specify the following parameters in the TDMA subsection:

Table 2-27 TDMA parameters

Parameter	Type	Value
smdpp_messageTypeInd	<integer>	0..23
smdpp_messageRef	<integer>	0..213
smdpp_privacyInd	<integer>	0..23
smdpp_urgencyInd	<integer>	0..22
smdpp_DAKRequested	<boolean>	true/false
smdpp_MAKRequested	<boolean>	true/false
smdpp_messageUpdating	<boolean>	true/false
smdpp_vp_absolute	<integer>	0..1
smdpp_vp_relativeTimerValue	<integer>	0..255
smdpp_vp_absoluteSeconds	<integer>	0..232
smdpp_vp_absoluteTZOffsetDirection	<integer>	0..1
smdpp_vp_absoluteTZOffsetMinutes	<integer>	0..720
smdpp_vp_absoluteTZOffsetDSI	<integer	0..1

smsDeliveryPointToPointResult

This is the response to an smsDeliveryPointToPoint operation.

smsDeliveryPointToPointResult [<parameters>]

An smsDeliveryPointToPoint operation may be an Ack or a Nack. Nacks contain an SMS_CauseCode parameter, specified as follows:

smdpp_causeCode <integer> // 0..2ˆ8

slpitLegResult

This operation is available for INAP level 2 (CS-2) handling.

slpitLegResult

This operation has no parameters.

specializedresourcereport

This operation has no parameters.

specializedresourcereport

tcapreject

tcapreject
    problemtype <type>
    generalproblem <problem>

A tcapreject operation will have the slpit utility send a TCAP_REJECT primitive on the main dialog. The problem type and ID are taken from the parameters. The mandatory parameter is problemtype which must be an integer from the following list:

Table 2-28 Integer List

Integer	Value
-1	none
0	general
1	invoke
2	return_result
3	return_error

The generalproblem parameter is also an integer, from 0 to 255. The reject source is set to TCAP_REJECT_LOCAL.

unstructuredSS

This operation is available for MAP handling. It sends a MAP2_ProcessUnstructuredSSRequest. The only language available is the default GSM alphabet because that is the only language that TC_PROTOS currently supports.

unstructuredSS [<parameters>]

An unstructuredSS operation can have the following parameters, appearing in any order:

msisdn <number expression>
msisdnReference <number expression>
originatingReference <number expression>
destinationReference <number expression>
ussd <string>
iMEI <bcd>
countryCode <digits> 
networkCode <digits> 
locationAreaCode <integer> 
cellID <integer>
sccp_orig_pc <integer> // 0 - 65535
sccp_orig_ssn <integer> // 0 - 255
sccp_orig_tt <integer> // 0 - 255
sccp_orig_np <integer> // 0 - 15
sccp_orig_noa <integer> // 0 - 127
sccp_orig_rti <integer> // 0 or 1
sccp_orig_digits <digits>
sccp_dest_pc <integer> // 0 - 65535
sccp_dest_ssn <integer> // 0 - 255
sccp_dest_tt <integer> // 0 - 255
sccp_dest_np <integer> // 0 - 15
sccp_dest_noa <integer> // 0 - 127
sccp_dest_rti <integer> // 0 or 1
sccp_dest_digits <digits>

The countryCode and networkCode can be only three digits long.

A MapOpen is inserted into the TCAP primitive's UserInformation area. The msidnReference is used to populate the msisdnReference in the MapOpen. The destinationReference populates the destinationReference in the MapOpen. The originatingReference is used to populate originationReference in the MapOpen The msisdn is used to populate the msisdn parameter in the UnstructuredSSRequest.

[empty]

The slpit utility can also send empty TCAP primitives. You can accomplish this by leaving the body of the send message blank as shown in the following example:

send
{
}

Receive Message Operations

The following operations are available in the receive message portion of a call definition.

abort

The format of this operation is:

abort

Use this operation to receive aborts that you expect. The Calls Aborted count is not updated, but the Calls Succeeded count is updated. When you use this operation, the script expects an abort so the test is successful in that it received one and continues. This is especially useful when running multiple calls because a standard abort would cause slpit to stop processing.

activityTest

This operation is available for use with CAMEL Phase 1. It is used to check continued existence of a relationship between SCF and SSF. This operation has no parameters.

activityTest

anyTimeInterrogation

This operation is available for handling MAP. It is used for time information enquiries between GSM SCF and HLR. It has the following format and parameters:

anyTimeInterrogation
    [ locationInformation
    [ age <integer comparator> ]
    [ geographical <number comparator> ]
    [ vrl <number comparitor> ]
    [ location <number comparator> ]
    [ cell <number comparator> ]
]

You can define the parameters to the locationInformation part of this operation in any order.

applycharging

This operation has the following format:

applycharging
    thresholdtime <integer comparator>
    [warningtime <integer comparator>]

The following format is available for handling CAMEL:

applyCharging
    maxDuration <integer>
    [ release <integer> tone <integer> ]
    [ tariff <integer> ]

applyChargingGprs

This operation is available for GPRS handling and it takes one of the following two forms:

applyChargingGprs
    gprsTransferredVolume <integer>
    [ gprstariffswitchinterval <integer> ]
    [ gprsPdPid <integer> ]

applyChargingGprs
    gprsElapsedTime <integer>
    [ gprstariffswitchinterval <integer> ]
    [ gprsPdPid <integer> ]

callinformationrequest

This operation requests the SSF to record information about a call and use the CallInformationReport operation to report it to the SCF. This operation has the following format:

callinformationrequest <requested fields>

A callinformationrequest operation must have at least one of the following labels requesting particular information. They may appear in any order:

callattemptelapsedtime
callstoptime
callconnectedelapsedtime
calledaddress
releasecause

These are effectively flags and do not have any associated values.

cap4InitiateCallAttempt

This operation requests the SSF to initiate a CAP4 call attempt and returns the result in a cap4InitiateCallAttemptResult message. It has the following format:

cap4InitiateCallAttempt [<parameters>]

A cap4InitiateCallAttempt operation may have any of the following parameters, in any order:

callingpartnumber <number comparator>
callreference <number comparator>
callsegmentid <integer>
destroutingaddr <number comparator>
gsmscf <number comparator>
legid <integer>
suppresstcsi

collectinformation

This operation requests the SSF to perform the call processing actions that collect destination information from a calling party. This operation has the following format, with no parameters.

collectinformation

connect

This operation requests the SSF to route a call to its destination. It has the following format:

connect [<parameters>]

The connect operation can have any of the following parameters in any order:

originalcalledpartnumber <number comparator>
    callingpartynumber <number comparator>
    redirectingpartynumber <number comparator>
    redircount <integer> redirreason <integer>
    destroutingaddr <number comparator>
    callingpartyscategory <integer> | callingpartyscategory <category>
    genericnumbers numberqualifier <qualifier> <number comparator>
...numberqualifier <qualifier> <number comparator>

You must include the destroutingaddr parameter. The <category> parameter is one of:

unknowncategory
operatorfrench
operatorenglish
operatorgerman
operatorrussian
operatorspanish
ordinarycallingsubscriber
callingsubscriberwithpriority
datacall
testcall
payphone

The <qualifier> parameter is either an integer value or one of the following:

additionalCalledNumber
additionalConnectedNumber
additionalCallingNumber
additionalOriginalCalledNumber
additionalRedirectingNumber
additionalRedirectionNumber

connectGprs

This operation is available for GPRS handling. When establishing a PDP context, it modifies the Access Point Name. This operation has the following format:

connectGprs
gprsAccessPointName <string>
[ gprsPdPid <integer> ]

connecttoresource

On receipt from the GSM SCF, this operation connects the IP to the incoming call. This operation has the following format:

connecttoresource
[ legid <integer> ]
[ address <digits> ]

If no address is specified, the received operation must have none indicated for its resourceAddress tag. If an address is specified, it must match the address in the ipRoutingAddress tag.

continue

This operation requests the SSF to proceed with call processing at the detection point (DP) where it previously suspended call processing to wait for instructions from the SCF. This operation has the following format and no parameters:

continue

continueGprs

This operation is available for GPRS handling. It requests the GPRS SSF to proceed with the GPRS session or context processing at the detection point (DP) where it previously suspended processing to wait for instructions from the GSM SCF. It has the following format:

continueGprs [ gprsPdPid <integer> ]

The release cause must be between 0 and 255 inclusive.

continueSms

This operation requests the SMS SSF to proceed with processing at the detection point (DP) where it previously suspended processing to wait for instructions from the GSM SCF. It is available for CAMEL handling and it has no parameters.

continueSms

continuewithargument

This operation requests the GSM SSF to proceed with call processing at the detection point (DP) at which it previously suspended call processing to wait for instructions from the GSM service control function. It also provides additional service-related information to the called party or the calling party while call processing proceeds.Parameters that are provided in the operation replace the corresponding signalling parameters in the call control function (CCF) and are used in subsequent call processing. Parameters that are not replaced by the operation retain their value in the CCF for subsequent call processing. This operation is available for INAP level 2 (CS-2) handling and has the following format:

continuewithargument [<parameters>]

The continuewithargument operation can have the following parameters:

legId <integer>
cap4CallSegmentId
cap4LegId <integer>

Use either the legId parameter or use the cap4CallSegmentId and the cap4LegId parameters. For CAP4 protocols, use the cap4CallSegmentId and the cap4LegId parameters. The legId parameter is not valid for CAP4 protocols.

cs1InitiateCallAttempt

This operation requests the SSF to initiate a CS1 call attempt. Although it can produce errors, it has no returned result. It has the following format:

cs1IniateCallAttempt [<parameters>]

A cs1InitiateCallAttempt operation can have any of the following parameters, in any order:

callingpartynumber ,number comparator.
callingpartyscategory <integer> | callingpartyscategory <category>
destroutingaddr <number comparator>

disconnectforwardconnection

This operation is used in two cases: 1) To disconnect a connection to a specialized resource function (SRF) and 2) to clear a connection to an assisting SSF. In the first case, it disconnects a forward connection from the SSF. In the second case, it disconnects the temporary connection between the initiating SSF and the assisting SSF and between the assisting SSF and its associated SRF. The operation has the following format with no parameters:

disconnectforwardconnection

disconnectforwardconnectionwithargument

This operation is available for INAP level 2 (CS-2) handling.

disconnectforwardconnectionwithargument partytodisconnect legid <integer>

The partytodisconnect parameter with the legid variant is the only supported parameter for this operation.

disconnectleg

This operation is available for INAP level 2 (CS-2) handling. It requests the GSM SSF to release a leg associated with the call. Other legs are retained.

disconnectleg reason <cause comparator> [legid <legid> | ( <integer> )]

Please see the description of "releasecall" for the possible values for the reason parameter. See the description of "eventreportbcsm" for a description of the possible values for legid.

establishtemporaryconnection

This operation creates a connection to a resource for a limited period of time to play an announcement or collect information and so on. It has the following format and parameter:

establishtemporaryconnection address <digits>

The address parameter, which is a string in double quotes, is mandatory.

furnishcharginginformation

This operation requests the SSF to generate or register a call record or to include some information in the default call record.This operation has no parameters:

furnishcharginginformation

Note:

Increasing the output level causes the parameters of the received operation to be written out even though the slpit utility does not check them.

mergecallsegments

This operation is available for INAP level 2 (CS-2) handling. It has the following format and mandatory parameters

mergecallsegments sourcecallsegment <integer> targetcallsegment <integer>

moForwardSmResult

This operation is available for MAP handling. It has no parameters:

moForardSmResult

mtForwardSmResult

This operation is available for MAP handling. It has no parameters:

mtForwardSmResult

playannouncement

This operation is used for in-band interaction with an analog user or for interaction with an Integrated Services Digital Network (ISDN) user. It has the following format and parameters:

playannouncement
     [connectedparty <integer>]
     annid <integer comparator> [, <integer comparator>...]
     [variableparts <parts>]

If you include the variableparts parameter, you must include one or more of the part value specifiers:

price <integer> <integer>
digits <digits>
time <integer> <integer>
date <integer> <integer> <integer>
integer <integer>

These correspond to the obvious sub-tags in the variableparts parameter of the outgoing operation. The price specifier should have two integer parameters giving dollars (or big currency unit) and cents (or little currency unit) respectively. You specify the time value in hours and minutes and the date value as day of the month, month number (1-12), and year (0-99).

prearrangedend

This operation has no parameters. It expects the other side of the dialog to send the fake TCAP primitive TCAP_PRE_END.

prearrangedend

promptandcollectuserinformation

This operation interacts with a user to collect information. It has the following format and parameters:

promptandcollectuserinformation
     annid <integer comparator> [, <integer comparator>...]
     [minnumberofdigits <integer>]
     maxnumberofdigits <integer>
     [<digit parameter>...]
     [variableparts <part> [<part>...]]

You can use the following specifiers for digit parameter in any order:

endofreplydigit <digits>
canceldigit <digits>
startdigit <digits>
interdigittimeout <integer>
firstdigittimeout <integer>

If you include the variableparts parameter, you must specify one or more of the following part value specifiers. See the description of "playannouncement" for more information.

readyForSMResult

This operation is available for MAP handling. It has no parameters:

readyForSMResult

releasecall

This operation causes the SCF to terminate an existing call at any phase for all parties. It has the following format and one parameter:

releasecall reason <cause comparator>

You can specify an integer for the reason parameter or one of the following names:

unalloc_num
norm_call_clr
user_busy
no_user_resp
no_answer
call_rejected
num_changed
out_of_order
inval_num_fmt
normal
temp_failure

releaseGprs

This operation causes the GSM service control function (SCF) to terminate an existing GPRS Session or PDP context at any phase. It is available for GPRS handling and it has the following format:

releaseGprs gprsReleaseCause <integer> [ gprsPdPid <integer> ]

releaseSms

This operation causes the GSM (SCF) to terminate a short message submission attempt or short message delivery attempt and is allowed only within a control relationship. It is available for CAMEL handling and has the following parameter:

releaseSms reason <integer comparitor>

reportSMSDeliveryStatusResult

This operation is available for MAP handling:

reportSMDeliveryStatusResult [<parameters>]

A reportSMSDeliveryStatusResult operation must have the following parameter:

msisdn <number expression>

requestreportbcsmevent

This operation causes the SSF to monitor for call-related BCSM events such as busy or no-answer and notify the SCF when one is detected. This operation has the following format:

requestreportbcsmevent [<event>...]

A requestreportbcsmevent must have one or more event descriptions:

eventtypebcsm <type> [monitormode <mode>] [legid <legid> | ( <integer> )]
   [dbspecificcriteria <criteria>]

The value off legid must be one of the following:

[sendingsideid] <legtype>
[receivingsideid] <legtype>

The value of criteria must be one of the following:

numberofdigits <integer comparator>
applicationtimer <integer comparator>

For example:

eventTypeBCSM oNoAnswer (2) dpspecificcriteria applicationTimer 20

requestReportGprsEvent

Causes the GSM SCF to request the GPRS SSF to monitor for a GPRS session event or a PDP context event, such as establish or detach, and to notify the GSM SCF when one is detected.You can request monitoring of more than one event in a single operation but each one will be reported in a separate EventReportGPRS operation.This operation has the following format:

RequestReportGprsEvent gprsEventType <number> [ gprsPdPid <integer> ]

requestReportSmsEvent

Causes the GSM service control function to request the SMS SSF to monitor for a short message related event such as failure, delivery, or submission, and to notify the GSM SCF when it detects one. You can request monitoring of more than one event with a single operation but each event will be reported in a separate EventReportSMS operation. This operation is available for CAMEL handling and has the following format.

eventTypeSms [ smsFailure | smsSubmitted ]

resettimer

This operation causes the SCF to refresh the tSSF application timer to avoid the tSSF time-out at the service SSF. This operation supports only one parameter, timervalue. You cannot specify the timer ID and it is not checked in the received operation. It defaults to tSSF.

resettimer timervalue <integer>

returnError

The operation has the following format:

returnError|tcapError [invokeID <integer>] errorCode <integer>

The returnError operation and the tcapError parameter operation are synonymous. If you specify invokeID, it must match the response. Otherwise, the returned invokeID is not checked. In the slpit script, calls start with an invokeID of 0 and the value is increased by 1 for each subsequent call.

sendcharginginformation

This operation instructs the SSF on the charging information to be sent. No parameters are supported for this operation and the received content is not validated.

sendcharginginformation

sendRoutingInfoForSmResult

This operation is available for MAP handling and has the following format and parameters:

sendRoutingInfoForSmResult [ imsi <number comparitor> ] [ nnn <number comparitor>]

sendRoutingInformationResult

This operation is available for MAP handling and has the following format and parameters:

sendRoutingInformationResult [ imsi <number comparitor> ]
     [ nnn <number comparitor> ]

splitleg

This operation causes the GSM SCF to request the GSM SSF to separate one party from the source call segment and place it in a new target call segment. This operation is available for INAP level 2 (CS-2) handling and has the following format and parameters.

splitleg legtobesplit <integer> newcallsegment <integer>

tcapError

This operation has the following format and parameters:

returnError|tcapError [invokeID <integer>] errorCode <integer>

The returnError parameter and tcapError parameter are synonymous. If you specify invokeID, it must match the response. Otherwise, the returned invokeID is not checked. In the slpit script, calls start with an invokeID of 0 and the value is increased by 1 for each subsequent call.

unstructuredSSResult

This operation is available for MAP handling and has the following format and parameters.

unstructuredSSResult ussdString <string>

The ussdString parameter is the expected parameter in an unstructuredSSResult operation. If you do not specify it, no check is performed. If a check is performed, the string must match the returned string, or the call will be counted in the failed call statistics.

Example Scripts

This section illustrates the call definition statements in a slpit script file for two sample calls: a standard point A to point B call and a call that plays an announcement.

A Standard Call

The statements in this example define a standard point A to point B call with one subsequent reservation in which the called party hangs up. This is not a CAMEL call.

define call atb_two_periods {
    DN ?= "39421234567"
    CLI ?= "3099440000"

    send {
      initialdp
        calledpartynumber DN
        callingpartynumber CLI
        callingpartyscategory 10
        locationnumber CLI
        eventtypebcsm analyzedinformation
    }

    receive {
      applycharging
        thresholdtime any -> threshold
        warningtime threshold - 10

      requestreportbcsmevent
        eventtypebcsm omidcall (2)

      requestreportbcsmevent
        eventtypebcsm oCalledPartyBusy (2)
        eventtypebcsm oNoanswer (2)
        eventtypebcsm oabandon (1)
        eventtypebcsm RouteselectFailure
        eventtypebcsm oDisconnect (2)
        eventtypebcsm oDisconnect (1)

      callinformationrequest
        callattemptElapsedTime
        callstopTime
        callConnectedElapsedTime
        calledaddress
        releaseCause

      connect
        destroutingaddr DN
    }

    talktime = threshold

    wait 1.0

    send {
      eventreportbcsm
        eventtypebcsm omidcall (2)
    }
    receive {
      applyCharging
        thresholdtime any -> threshold
        warningtime threshold - 10

      RequestReportBCsMEvent
        eventtypebcsm omidcall (2)
      continue
    }

    talktime = talktime + threshold

    wait 1.0

    send {
      eventreportbcsm
        eventtypebcsm odisconnect (2)

      applychargingreport
        thresholdtime 20
        endofcallindicator 1

      callinformationreport
        callattemptelapsedtime 10
        callstoptime "001002000000"
        callConnectedElapsedTime (talktime - 20) * 10
        calledaddress DN
        releasecause 31
    }

    receive {
      releasecall
        reason 31
    }
}

startcall atb_two_periods using once

A Call that Plays an Announcement

The statements in this example define a simple call that requests assistance and plays an announcement.

define call assisting_ip_pa {
    SERVICE_NUMBER ?= "555801"

    send {
      initialdp
        calledpartynumber SERVICE_NUMBER
        callingpartynumber "40002000"
        callingpartyscategory 10
        locationnumber "40002000"
        eventtypebcsm analyzedinformation
    }

    receive {
      establishtemporaryconnection
        address "1234"
    }

    send {
      assistrequestinstructions
    }

    receive {
      playannouncement
        annid any
    }

// Might receive the abort any time after sending the SRR.
    allow abort assisting

    send {
      specializedresourcereport
    }

    receive {
      disconnectForwardConnection
    releasecall
      reason normal
    }

// The abort might not have arrived yet.
    abort open
}