Dialogic DSI Protocol Stacks

DTS User Guide

October 2009

U24SSS
www.dialogic.com

Copyright and Legal Notice

Copyright 1993-2009 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without permission in writing from Dialogic Corporation at the address provided below. All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a commitment on the part of Dialogic Corporation or its subsidiaries (Dialogic). Reasonable effort is made to ensure the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document. INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY. Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs only in the countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the address indicated below or on the web at www.dialogic.com. It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available from Dialogics legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement any concepts or applications and does not condone or encourage any intellectual property infringement and disclaims any responsibility related thereto. These intellectual property licenses may differ from country to country and it is the responsibility of those who develop the concepts or applications to be aware of and comply with different national license requirements. Dialogic, Dialogic Pro, Brooktrout, Diva, Cantata, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized), Eiconcard, SIPcontrol, Diva ISDN, TruFax, Exnet, EXS, SwitchKit, N20, Making Innovation Thrive, Connecting to Growth, Video is the New Voice, Fusion, Vision, PacketMedia, NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as related logos, are either registered trademarks or trademarks of Dialogic Corporation or its subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted by Dialogics legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogics trademarks requires proper acknowledgement The names of actual companies and products mentioned herein are the trademarks of their respective owners. Publication Date: October 2009 Document Number: U24SSS, Issue 8 2

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Contents
Revision History ........................................................................................................... 5 1
1.1 1.2

Introduction ........................................................................................................ 6
Related Documentation............................................................................................................ 7 Abbreviations ......................................................................................................................... 8

2
2.1 2.2 2.3 2.4

Distributed Transaction Server ............................................................................ 9

Client Selection Methods ........................................................................................................ 10 Routing Options .................................................................................................................... 12 Route Enabling ..................................................................................................................... 12 Client Sequence Number ........................................................................................................ 12

3
3.1

Distributed Transaction Client ........................................................................... 13

DTC Distribution ................................................................................................................... 13

4
4.1

Configuration .................................................................................................... 14
System Configuration ............................................................................................................ 14 4.1.1 SIU Configuration ..................................................................................................... 14 4.1.2 Host RSI Configuration .............................................................................................. 15 4.1.3 DTC Configuration Commands .................................................................................... 15 4.1.4 DTC Configuration Message - DTC_MSG_CONFIG ......................................................... 17 Protocol Configuration ........................................................................................................... 18 4.2.1 SIU Configuration ..................................................................................................... 18 4.2.2 Host Configuration .................................................................................................... 20

4.2

5
5.1 5.2 5.3

Application Considerations ................................................................................ 21

Status messages from DTS .................................................................................................... 21 Use of Dialog IDs .................................................................................................................. 21 Supported Messages ............................................................................................................. 21

6
6.1 6.2 6.3

Operation .......................................................................................................... 22
DTC Command Line Arguments .............................................................................................. 22 Message Tracing ................................................................................................................... 23 6.2.1 Set Trace Mask Request ............................................................................................ 23 Client Management ............................................................................................................... 26 6.3.1 Client Management Request (DTS_CLIENT_REQ) .......................................................... 26 6.3.2 Client Routing Configuration Request (DTS_ROUTING_REQ) .......................................... 28 6.3.3 Client Management Confirmations (DTS_CLIENT_CONF) ................................................ 31 RSI Link Status Messages ...................................................................................................... 32 Other Message Handling ........................................................................................................ 32 6.5.1 Messages for SCCP ................................................................................................... 32 6.5.2 Messages for the Client ............................................................................................. 33 6.5.3 SCCP Management Messages ..................................................................................... 33 Start-up Sequence ................................................................................................................ 33 Summary of DTS message handling ........................................................................................ 34 6.7.1 DTS Routing Request Message Handling ...................................................................... 35

6.4 6.5

6.6 6.7

Contents

Figures
Figure Figure Figure Figure 1: 2: 3: 4: Distributed Transaction Server Architecture, DTS above SCCP (Mode A) .................................... 6 Distributed Transaction Server Architecture, with MAP traffic distribution (Mode B) ..................... 7 Client Specific Selection ..................................................................................................... 11 Example DTS System Configuration (Mode A DTS above SCCP) ........................................... 14

Tables
Table 1: Active Client Selection ........................................................................................................ 10 Table 2: DTC command line arguments ............................................................................................. 22 Table 3: DTC display options ............................................................................................................ 22

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Revision History
Issue 1 2 Date 07-Sep-01 16-Jun-03 Initial release Branding changed: Septel PCI now SPCI4/SPCI2S, Septel cP now CPM8 and Septel ISA now PCCS6. Addition of Network Context based routing. Further Network Context information and update references to include Dialogic SS7G2x Signaling Gateway in SIU mode. Corrections to state handling for RSI Clarification on use of sequence numbers Rebranded to Dialogic Changes to support Dialogic DSI SS7G3xSignaling Server 8 06-Oct-09 Addition of MAP, INAP and IS41 above DTS for SS7G3x Description

3 4

20-Oct-05 31-Jan-06

5 6 7

26-Jul-06 16-Feb-07 25-Mar-09

Note:

Current software and documentation supporting Dialogic SS7 protocols is available at: http://www.dialogic.com/support/helpweb/signaling

Introduction

Introduction
The Distributed Transaction Server (DTS) is a system for providing the user with a distributed and scalable platform for access to non-circuit related protocols such as MAP, INAP, IS41 or TCAP. DTS has two modes of operation. These modes are described in this document as Mode A and Mode B for clarity. It is not necessary to specify a mode when using DTS. Mode A: DTS operates between the SCCP and TCAP layers and distributes SCCP traffic to multiple TCAP hosts (Figure 1: Distributed Transaction Server Architecture). DTS operates above a TCAP-User Module, such as MAP, INAP or IS41, and distributes traffic directly to the application hosts (Figure 2: Distributed Transaction Server Architecture, with MAP traffic distribution).

Mode B:

Mode A is supported by SS7G2x and SS7G3x, however the Mode B is not supported on the SS7G2x Signaling Servers. Each of the hosts may be brought into service or taken out of service without affecting the whole node. Similarly, it is also possible to shutdown and restart one of the server platforms.
Host A User Application Module TCAP Host B User Application Module TCAP Host C User Application Module TCAP

DTC

DTC

DTC

RSI Link

DTS SCCP RSI Link

DTS SCCP

MTP SIU A SS7 Linkset

MTP SIU B

SS7 Linkset

Figure 1: Distributed Transaction Server Architecture, DTS above SCCP (Mode A)

6

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Host A

Host B

Host C

User Application Module

User Application Module

User Application Module

RSI Link

DTS

DTS

MAP

MAP

TCAP

RSI LINK

TCAP SS7 Linkset

SCCP

SCCP

MTP

MTP

SIU A

SIU B

SS7 Linkset

Figure 2: Distributed Transaction Server Architecture, with MAP traffic distribution (Mode B)

The servers are implemented using Dialogic DSI SS7G2x or SS7G3x Signaling Servers in Signaling Interface Unit (SIU) mode, which can be configured to run as a resilient pair. The system adds two new modules, the Distributed Transaction Server (DTS) and Distributed Transaction Client (DTC). These combine with the SIUs and existing functionality to provide the architecture shown above in Figure 1. When DTS is used in Mode B, as shown by Figure 2, the DTC module is not used.

1.1

Related Documentation
[1] [2] [3] [4] [5] TCAP Programmers Manual SCCP Programmers Manual INAP Programmers Manual Software Environment Programmers Manual Dialogic DSI Signaling Servers SIU Mode User Manual U06SSS U05SSS U10SSS U16SSS 05-2302-xxx

Introduction

1.2

Abbreviations
DTC DTS PC RSI SCCP SIU SSN TCAP TCAP-User UDT Distributed Transaction Client Distributed Transaction Server Point Code Resilient Socket Interface Signaling Connection Control Part Signaling Interface Unit Sub-System Number Transaction Capabilities Application Part Module which operates above TCAP, such as MAP, INAP or IS41 SCCP Unit Data Message

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

2 Distributed Transaction Server

The server module is necessary to distribute messages to the multiple hosts on behalf of SCCP, (Mode A) or a TCAP-User layer module, such as MAP, INAP or IS41 (Mode B). It appears to SCCP or the TCAP-User module to be a single module above it. An incoming message to DTS that is the beginning of a new dialog will be sent to one client selected from those that are active. A further step may be taken where a suitable client is selected depending on the called party number within the message (section 2.1 Client Selection Methods). Subsequent messages for existing dialogs will be sent back to the same client as long as it is still available. Messages from the client are passed down transparently to the SCCP, or TCAP-User layer. The server is able to manage message distribution by monitoring the different types of messages coming down from the client. As mentioned earlier, messages for the SCCP or TCAP-User layer are passed straight down to SCCP, or the TCAP-User. In order for the server to be able to identify the available clients for messages going up to the client, a set of management messages have been developed specifically for DTS. They include the following: A message from the client to the server indicating that it is available to receive new dialogs. A message from the client to the server indicating that a client is able to receive messages intended for a particular subsystem. A message from the client to the server indicating that a client is able to receive the messages intended for a particular subsystem and network context A message from the client to the server indicating that although active, no new dialogs should be sent to it but existing dialogs should be maintained. A message from the client to the server indicating that the client has instantly become unavailable

The client will receive an acknowledgement for some of these messages. Further details on these messages are given in section 6.3 Client Management.

Distributed Transaction Server

2.1

Client Selection Methods

New dialogs are directed to particular clients by DTS. There are two methods by which DTS can select the client. Active Client Selection involves selecting clients in the active state in ascending/descending instance order for each new dialog received. To do this, the DTS_CLIENT_REQ message (section 6.3.1) is needed to inform DTS of which clients are active. The example shown in Table 1 shows an array of 16 clients. The active clients are the clients that have sent a DTS_CLIENT_REQ message, indicating "startup", to DTS (section 6.3.1).

Table 1: Active Client Selection

1 0 Key:

1 1

1 2

0 3

0 4

0 5

1 6

1 7

1 8

1 9

0 10

0 11

0 12

0 13

0 14

1 15

1 = Active 0 = Inactive Alternatively Client Specific Selection is an extension of Active Client Selection whereby clients are not selected just on their active state, but also selected depending on the subsystem number (routing key) in the message. Using the DTS_ROUTING_REQ message (section 6.3.2), DTS can be configured to direct incoming messages that have a particular subsystem number and network context to single client, or to one of a group of clients (client selection group) as specified in the DTS_ROUTING_REQ message. An example is shown in Figure 3.

10

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Routing Key

Routing Options

Client Selection Group

SSN 0xa NC 0

Strict Rotation

Client 2 Seq Num 0

Client 1 Seq Num 1

Client 0 Seq Num 2

null

null

Next Client

SSN 0xb NC 1

Prefered Order

Client 2 Seq Num 0

Client 1 Seq Num 1

Client 0 Seq Num 2

null

null

SSN 0xc NC 2

Prefered Order

Client 2 Seq Num 0

Client 1 Seq Num 1

null

Client 0 Seq Num 3

null

Figure 3: Client Specific Selection

Figure 3 shows an example of 3 routing keys. The first key will select clients in strict order; the remaining 2 keys will select clients in preferred order. The clients are not selected in instance ID order. The "next_client" pointer on the first key shows how clients will be selected in sequence number order. This is indicated by the sequence numbers 0, 1 and 2, referring to client instance IDs 2, 1 and 0. Each sequence number should be unique within the routing key. The last 2 routing keys will select clients in preferred order, so the first active client is always selected. The sequence number is what determines the position of a client in its selection group. The DTS_ROUTING_REQ messages do not have to be sent with the sequence numbers in order. Clients can be placed in their selection groups in any order. This is shown in the last routing key of 0 where sequence number 3 is allocated before sequence number 2. The DTS_ROUTING_REQ message can also be used to configure DTS to send all incoming messages with subsystem numbers and network contexts not previously specified in other DTS_ROUTING_REQ messages, to a particular client or group of clients. This would be done simply by sending to DTS a DTS_ROUTING_REQ message without a subsystem number and network context.

11

Distributed Transaction Server

2.2

Routing Options
DTS has two methods for the selection of clients within a selection group. The first method is Strict Rotation. Strict Rotation works in a similar manner to Active Client Selection (section 2.1 Client Selection Methods). The difference is that Strict Rotation is restricted to the clients that have been put in the same selection group by way of the DTS_ROUTING_REQ message. The second method for client selection is Preferred Order. This method is simpler than the first and works by selecting the first available client in the group. The same client will always be selected as long as the client is active, by way of the DTS_CLIENT_REQ message and still enabled by the DTS_ROUTING_REQ message. This selection method creates active/activestandby system whereby if there is a problem with the current active client, a message will automatically be passed to the next active client in the selection group.

2.3

Route Enabling
Part of the functionality of the DTS_ROUTING_REQ message is the ability to enable or disable routing to a particular client within a selection group. If routing to a client within a selection group is disabled, then although the client will remain in the group, no incoming messages with the particular routing key shall be directed to that client. The next client in the group will be selected instead. If it is enabled by a DTS_ROUTING_REQ message, then it will be included again.

2.4

Client Sequence Number

Whenever a DTS_ROUTING_REQ message is received, the message must include a sequence number. This number will determine the position of the client in the selection group.

12

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Distributed Transaction Client

The Distributed Transaction Client module (DTC) is required when using DTS to distribute SCCP traffic to multiple TCAP hosts (Mode A). It is not required when distributing TCAP-User traffic. DTC runs on the application platform below the TCAP module, allowing TCAP to be restarted independently of the lower layers. It works with the DTS module to allow for the use of multiple distributed modules. One DTC is required on each client host machine. The DTC maintains a map of server states in order to ensure messages are only sent to active servers. It can then forward messages from TCAP down to an available SCCP server. It also provides server selection mechanisms to balance load between available servers and to avoid servers which are not available. The server status is determined by the state of the RSI link to server module and so the DTC module requires the RSI link status information to be forwarded to it. It also allows these status messages to be passed on to other modules. The DTC module also allows messages sent to and from the DTS module and the user to be traced for system monitoring.

3.1

DTC Distribution
The following files form the distribution of DTC required for the hosts: DTC binary module appropriate for the host operating system (e.g., dtc_nt.exe) DTS include file (dts_inc.h)

13

Configuration

Configuration
4.1 System Configuration
The following system configuration assumes the use of dual resilient SIUs with two or more connected host systems.
Host 0 User Application / Module TCAP DTC Host 1 User Application / Module TCAP DTC Host 2 User Application / Module TCAP DTC

RSI Link

User Application / Module TCAP SIU_MGT SCCP MTP

DTS SCCP MTP SIU A SS7 Linkset SIU_MGT

DTS SCCP RSI Link MTP SIU B

PC 1

SS7 Linkset

PC 2

Figure 4: Example DTS System Configuration (Mode A DTS above SCCP)

4.1.1

SIU Configuration
DTS will function correctly with a single SIU or with SIUs in a dual resilient pair. For improved performance of DTS, SIUs should be used as a dual resilient pair. For further information on this configuration, see the appendix SIU Resilience in the Dialogic DSI Signaling Servers SIU Mode User Manual. The SIU must be appropriately licensed to allow the use of SCCP in Mode A, and SCCP, TCAP and the TCAP-User protocol in Mode B. Module Configuration The DTS module is configured automatically by the SIU whenever the config.txt file includes an SCCP_LSS command with the protocol parameter set to an appropriate DTS value (section 4.2.1 SIU Configuration).

14

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

4.1.2

Host RSI Configuration

As for all SIU hosts, the Resilient Socket Interface (RSI) is used to handle message passing to and from the SIU. When using DTS above SCCP (Mode A) DTC should be used as the monitoring module ID in the rsicmd used to initialize RSI. . The SIU ports used for the RSI links must be allocated in a manner consistent with the host numbering and the TCAP instance IDs should be set to match the host IDs. For example: SIU A IP address 123.123.123.100 SIU B IP address 123.123.123.101 Host 0 rsicmd.exe 0 0x0d 0 123.123.123.100 9000 rsicmd.exe 1 0x0d 0 123.123.123.101 9000

Host 1 rsicmd.exe 0 0x0d 0 123.123.123.100 9001 rsicmd.exe 1 0x0d 0 123.123.123.101 9001

4.1.3

DTC Configuration Commands

The DTC configuration commands when used with S7_MGT are: DTC_CONFIG Configure DTC DTC_SSR DTC Sub System Resource DTC_CONFIG Configure DTC Synopsis The DTC_CONFIG command supplies the global configuration parameters for the DTC protocol, activating DTC and higher protocols. Syntax DTC_CONFIG <num_servers> <server_selection> <host_number> <rsi_status_user_id> Example DTC_CONFIG 2 0 0 0xef Parameters The DTC_CONFIG command includes the following parameters: <num_servers> Number of servers in the system. <server_selection> The selection mechanism used by DTC to select which server to be used. See the DTC User Guide.
15

Configuration

<host_number> The host number, which should be unique across hosts. <rsi_status_user_id> Module ID to forward RSI link status messages to. DTC_SSR DTC Sub System Resource Synopsis The DTC_SSR command configures a local subsystem using DTC. The command works in a similar way to the SCCP_SSR LSS command but configures the subsystem to run on top of DTC instead of SCCP. DTC and SCCP cannot be used at the same time, so the SCCP_SSR and DTC_SSR commands are incompatible with each other. Syntax DTC_SSR <ssr_id> LSS <local_ssn> <module_id> <reserved> <protocol> Example DTC_SSR 1 LSS 0x07 0x0d 0 TCAP Parameters The DTC_SSR command includes the following parameters: <ssr_id> A unique ID for the SSR. <local_ssn> The local sub-system number as defined by the SCCP protocol. <module_id> The module identifier of the user application on the host computer that implements the local sub-system. <reserved> Must be set to 0. <protocol> Should be set to TCAP, MAP, INAP or IS41 according to the layer of the protocol stack to which the user application interfaces. Note: There can be at most one LSS for each of MAP, INAP and IS41.

16

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

4.1.4

DTC Configuration Message - DTC_MSG_CONFIG

The DTC configuration messages are: Synopsis: Message sent from the user to configure the Distributed Transaction Client module. Message Format:
MESSAGE HEADER Field Name type id src dst rsp_req hclass status err_info Len Meaning DTC_MSG_CONFIG (0x776c) 0 user module DTC_TASK_ID May be used to request a confirmation 0 0 0 40

PARAMETER AREA Offset 0 1 2 3 4 5 6 7 8 10 Size 1 1 1 1 1 1 1 1 2 30 Name cnf_ver - must be set to zero sccp_id SCCP module ID tcap_id TCAP module ID dts_id Distributed Transaction Server module ID mgmt_id Management module ID rsi_status_id Module ID to which RSI link status messages are forwarded num_servers Number of servers in system server_selection - Server selection mechanism options Run time options reserved set to zero

Description: This message is used to configure each DTC module for correct operation with the DTS modules on the SIUs. It should be the first message sent to the DTC module and should precede the starting of the RSI link.
17

Configuration

Parameter area contents: cnf_ver The version of the client configuration message. Currently, only version 0 is defined. sccp_id Module identifier defining the destination module ID for messages to the SCCP task. tcap_id Module identifier defining the destination module ID for messages to the TCAP task. dts_id Module identifier defining the module ID for the DTS module (typically 0x30). mgmt_id Module identifier defining the module ID to which module status and error messages are sent. rsi_status_id Module identifier defining the module ID to which RSI link status messages received should be sent. server_selection Set to indicate what kind of selection mechanism should be used by the DTC module in determining which server to use. The defined values for server selection mechanism are:

Value 0 1 2 - 255

Mnemonic DTC_SELECT_SEQ DTC_SELECT_REV_SEQ reserved

Description Selects available servers in a sequential order Selects available servers in a reverse sequential order Not currently defined.

options This field is a 16 bit field used to convey various run-time options to the module as shown in the following table:
Bit 0 Meaning This bit decides where to route messages from TCAP to either DTS or SCCP. 0 Route messages to SCCP. 1 Route messages to DTS. Note: It is recommended to set this bit to one for the normal operation; however, this bit must be set to one for Network Context / multiple local point operation.

4.2
4.2.1

Protocol Configuration
SIU Configuration
The following configuration guidelines show how the SIU(s) should be configured.

18

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

MTP/M3UA The configuration of the MTP/M3UA layer should be performed via the config.txt file in accordance with the normal procedures for a dual resilient configuration. See the Dialogic DSI Signaling Servers SIU Mode User Manual for more information. SCCP The configuration of the SCCP layer is also performed in the config.txt file. In Mode A (DTS above SCCP), the local sub-systems configuration should define each sub-system as using the DTS module as its protocol layer even if TCAP, INAP etc. is running on the host systems. For example:
*SCCP_SSR [<nc_id>] <ssr_id> LSS <local_ssn> <module_id> <lss_flags> <protocol> SCCP_SSR 1 LSS 0x08 0x0d 0x0000 DTS

If DTS is distributing TCAP-User Layer messages (Mode B), the SCCP_LSS protocol parameter should indicate the type. The <module_id> parameter should reflect the module ID of the user-application.
SCCP_SSR 2 LSS 0x08 0x1d 0x0000 DTS-MAP SCCP_SSR 3 LSS 0xfc 0x2d 0x0000 DTS-INAP SCCP_SSR 4 LSS 0x09 0x3d 0x0000 DTS-IS41

TCAP and TCAP-User Module Configuration When DTS distributes TCAP-User messages (Mode B), modules above SCCP should be configured in the normal manner. The SIU will automatically configure the relevant TCAP-User module to route traffic through DTS. DTS Configuration When using DTS with more than 16 hosts the maximum number of hosts to be used should be specified in the DTS_CONFIG <max_instance> parameter. Synopsis The DTS_CONFIG command provides the ability to control the parameters of the DTS module. Syntax DTS_CONFIG <max_instance> <reserved> Example DTS_CONFIG 32 0 Parameters <max_instance> The maximum number of TCAP hosts which will receive traffic from DTS. <reserved> This parameter is reserved for future use.

19

Configuration

4.2.2

Host Configuration
TCAP When TCAP is present on the host system (Mode A), the module should follow the normal configuration as described, with the following exceptions. When configuring TCAP using S7_MGT, the TCAP_CONFIG <tcap_inst> parameter should be set to match the host number, and the <max_instance> parameter should be set to the total number of TCAP systems. TCAP_CONFIG <base_ogdlg_id> <nog_dialogues> <base_icdlg_id> <nic_dialogues> <options> <dlg_hunt>[ [<addr_format>] <partner_id> <tcap_inst> [<max_instance>]] When configuring using messages, the field nsap_id which would normally contain the module ID for SCCP should contain the module ID defined for the DTC module (For example - 0x0d). The field tcap_instance should be set to match the host number. The instance value must be unique across hosts. If more than 16 hosts are used, the tid_ninst, tid_ndref and tid_nseq should be set to 8, 16 and 8 respectively. The current implementation of DTS will not support the use of 24bit ITU TCAP message formats. TCAP User Layers No changes to existing configuration of the protocol modules such as INAP, MAP and IS-41 are required. User-Application When the DTS distributes TCAP-User messages to the application, the application must send its messages to the DTS module, rather than directly to the TCAP-User module.

20

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Application Considerations
When using DTS to distribute SCCP traffic, no additional considerations are needed. However, when DTS distributes TCAP-User traffic (Mode B), the application has the following additional responsibilities.

5.1

Status messages from DTS

As DTC is not used in this configuration, DTS will send the status messages to the application, instead of to DTC. These messages may be processed by the application and must be released. The status messages sent by DTS are:
DTS_CLIENT_CONF SCP_MSG_SCMG_IND 0x076b 0x8745

5.2

Use of Dialog IDs

When DTS distributes traffic to more than one Host system, care should be taken when initiating new dialogs from the Host Application. Multiple hosts should not attempt to use the same Dialog ID. Using separate, nonoverlapping dialog ranges is recommended.

5.3

Supported Messages
In Mode B, DTS will distribute the following Protocol messages: INAP Messages
INAP_MSG_SRV_REQ INAP_MSG_DLG_REQ INAP_MSG_SRV_IND INAP_MSG_DLG_IND INAP_MSG_ERROR_IND INAP_MSG_MAINT_IND 0xc7f0 0xc7f2 0x87f1 0x87f3 0x07f8 0x07f9

MAP Messages
MAP_MSG_SRV_REQ MAP_MSG_DLG_REQ MAP_MSG_SRV_IND MAP_MSG_DLG_IND MAP_MSG_ERROR_IND MAP_MSG_MAINT_IND 0xc7e0 0xc7e2 0x87e1 0x87e3 0x07e9 0x07ea

IS41 Messages
IS41_MSG_SRV_REQ IS41_MSG_DLG_REQ IS41_MSG_SRV_IND IS41_MSG_DLG_IND IS41_MSG_ERROR_IND IS41_MSG_MAINT_IND 0xc7b0 0xc7b2 0x87b1 0x87b3 0x07b9 0x07ba

21

Operation

Operation
6.1 DTC Command Line Arguments
The module takes a number of run time options, which are summarized below. These include options for tracing the program as it progresses.
Table 2: DTC command line arguments
Option -m -d Default 0x0d 0x001f Notes DTC module ID. Display Options Add together required values for tracing options.

The value for the display options should be the sum of the values given below:
Table 3: DTC display options
Display Option DTC_DISP_TX DTC_DISP_RX DTC_DISP_ERROR DTC_DISP_MGMT DTC_DISP_STATUS Value 0x0001 0x0002 0x0004 0x0008 0x0010 Notes Trace messages sent Trace messages received Trace errors Trace client management requests and confirmations Trace messages sent

Example: dtc_nt.exe m0x0d d0x001c

22

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

6.2
6.2.1

Message Tracing
Set Trace Mask Request
Synopsis: Message sent to DTS to trace both primitive and non-primitive messages sent to or sent from DTS. Message Format:
MESSAGE HEADER Field Name type id src dst rsp_req hclass status err_info len Meaning DTS_MSG_TRACE_MASK (0x5769) 0 User Module DTS_TASK_ID (0x30) Used to request a confirmation 0 0 0 12 PARAMETER AREA Offset 0 4 8 Size 4 4 4 Name op_evt_mask ip_evt_mask non_prim_mask

This message causes a copy of messages received and sent by DTS to be taken and sent to the trace_id specified in the DTS Configuration request configured by the SIU, facilitating the examination of the messages for diagnostic purposes. The module is able to trace three types of messages. The mask values op_evt_mask and ip_evt_mask trace data messages sent or received by the DTS module. The non_prim_mask allows tracing of management and configuration messages.

23

Operation

op_evt_mask The output event trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module when the server module sends the associated protocol message. 31 0 30 0 29 0 28 0 27 0 26 0 25 0 24 0

23 0

22 0

21 0

20 0

19 0

18 0

17 0

16 0

15 0

14 0

13 0

12 0

11 0

10 0

9 0

8 0

7 0 SCCP_UDT MAP INAP IS41

6 0

5 0

4 0

3 IS41

2 INAP

1 MAP

0
SCCP_UDT

= SCCP Unit Data messages from SCCP to TCAP = MAP messages from MAP to the Application = INAP messages from INAP to the Application = IS41 messages from IS41 to the Application

ip_evt_mask The input event trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module when the server module receives the associated protocol message. 31 0 30 0 29 0 28 0 27 0 26 0 25 0 24 0

23 0

22 0

21 0

20 0

19 0

18 0

17 0

16 0

15 0
24

14 0

13 0

12 0

11 0

10 0

9 0

8 0

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

7 0 SCCP_UDT MAP INAP IS41

6 0

5 0

4 0

3 IS41

2 INAP

1 MAP

0
SCCP_UDT

= SCCP Unit Data messages from SCCP to TCAP = MAP messages from the Application to MAP = INAP messages from the Application to INAP = IS41 messages from the Application to IS41

non_prim_mask The non-primitive trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module when server module receives the associated non-primitive message. 31 0 30 0 29 0 28 0 27 0 26 0 25 0 24 0

23 0

22 0

21 0

20 0

19 0

18 0

17 0

16 0

15 0

14 0

13 0

12 0

11 0

10 0

9 0

8 0

7 0

6 0

5 0

4 0

3 0

2
SERVER_ ERR

1
RSI_ STATUS

0
CLNT_ MGT

CLNT_MGT = Client module management messages RSI_STATUS = Status messages passed from RSI SERVER_ERR = Server module error messages

25

Operation

6.3
6.3.1

Client Management
Client Management Request (DTS_CLIENT_REQ)
Synopsis: This will be sent from client to the server module (DTC to DTS) to inform it of changes to the client state. Message Format:
MESSAGE HEADER Field Name type id src dst rsp_req hclass status err_info len Meaning DTS_CLIENT_REQ (0x776a) 0 DTC_TASK_ID DTS_TASK_ID Used to request a confirmation 0 0 0 1 PARAMETER AREA Offset 0 Size 1 Name Request type octet.

Description: This message is used by the client to inform the server that it wishes to startup or shutdown. The instance field of the message is to be used to identify the sender and receiver of the message. Senders of this message should use GCT_set_instance to identify the server to which the message is addressed. On reception of the message the procedure GCT_get_instance can be used to retrieve the instance field, which will identify the sender of the message. Parameter area contents: The request type octet is coded as follows:
Request Client Start-up Request Client Shutdown Prepare Client Shutdown Request
26

Mnemonic DTS_CLIENT_STARTUP DTS_CLIENT_SHUT_PRE DTS_CLIENT_SHUTDOWN

Value (Decimal) 1 2 3

Value (Hex) 0x1 0x2 0x3

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Startup Messages Before messages can be sent to a client and before a client sends messages to a server, a startup message must have been sent from the client to the server. This message indicates to a server that the server should expect to receive dialogs from the client and that the client is available to receive new dialogs from the server. This message also identifies the instance of the client that the server uses as a unique ID for that particular client. The state of a client that has sent this message is considered to be in the "startup" state. If a valid startup message is received, it will be acknowledged by the server in a separate message to the client. Shutdown-Prepare Messages These messages indicate to the server that no new dialogs should be sent to the client that sent the shutdown-prepare message. So although new dialogs will be sent to the client, existing dialogs will be maintained. The server will mark this client as being in the "shutdown-prepare" state. If a valid shutdown-prepare message is received an acknowledgement will be sent back to the client in a separate message. New dialogs should be accepted by the client until it has received an acknowledgement from the server. Shutdown Messages A shutdown message will immediately prevent any message being sent from the server to the client that sent the shutdown message. No further messages will be accepted by the server from a client that is in the "shutdown" state. A valid shutdown message will be acknowledged in a separate message.

27

Operation

6.3.2 Client Routing Configuration Request (DTS_ROUTING_REQ)

Synopsis: This message is sent from the client to the DTS module in order to configure routing at DTS based on sub-system. This message may also be optionally sent via the DTC module. Message Format:
MESSAGE HEADER Field Name Type Id Src Dst rsp_req Hclass Status err_info Len Meaning DTS_ROUTING_REQ (0x776d) 0 DTC_TASK_ID (or client module ID) DTS_TASK_ID Used to request a confirmation 0 0 0 Number of bytes of user data PARAMETER AREA Offset 0 1 len - 1 Size 1 len 2 1 Name Request type octet. Parameters in Name-Length-Data format. Set to zero indicating end of message

Description: This message is used by the client to inform the server that the client wishes to be included in the group of clients which are able to receive messages destined for a particular subsystem. This message and the DTS_CLIENT_REQ message can be sent in any order. But if client-specific routing is to be used, the client must both be in the active state and enabled by receipt of a DTS_ROUTING_REQ message. The instance field of the message is to be used to identify the sender and receiver of the message. Senders of this message should use GCT_set_instance to identify the server to which the message is addressed. On reception of the message, the procedure GCT_get_instance can be used to retrieve the instance field, which will identify the sender of the message.

28

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

Parameter area contents: The request type octet is coded as follows:

Request Enable Disable Mnemonic CLNT_ROUTING_ENABLE CLNT_ROUTING_DISABLE Value (dec) 1 2 Value (hex) 0x1 0x2

The value of the request type octet will determine if the client will be able to receive messages that are destined for a particular subsystem. If the value indicates "disabled" then although the client will be part of the group of clients (selection group) receiving messages for a subsystem (routing key), messages for the subsystem will be sent to other "enabled" clients in the same selection group. The DTS_ROUTING_REQ message can be sent at any time to enable or disable a client in a group. The following table lists the parameters associated with each DTS routing configuration message:
Parameter ENABLE SSN Sequence number Network context Routing options O
1

Routing Request DISABLE O

2

M D D

M D D

Note 1: If a parameter value of this type is not present, then a default routing key is assumed. Note 2: These parameters must match those used to enable the routing. If the message used to enable the routing contained this parameter, then the message used to disable it must also contain the parameter with a matching value.

Key
M O D Mandatory Optional Default The parameter will always be included in the message. The parameter may or may not be included in the message depending on the circumstances in which the message is sent. If not present, default values are assumed.

The following parameter names are defined for use in the DTS routing configuration message:
Parameter Sub-system number Sequence Number Routing Options Network Context Mnemonic DTSPN_ssn DTSPN_seq_number DTSPN_routing_opt DTSPN_network_context Value (dec) 1 2 3 5 Value (hex) 0x01 0x02 0x03 0x05

29

Operation

The coding for each parameter type is given in the following tables:
Parameter name Parameter length Parameter data DTAPN_ssn Fixed, length 1 The sub-system number part of the routing key. A value of 0 is considered to be null.

Parameter name Parameter length Parameter data

DTSPN_seq_number Variable, length 1 or 2 This value is used to determine the order of clients in a group determined by routing key. Lower numbered values are considered earlier in the sequence, and numbers should be unique within that routing key.

Parameter name Parameter length Parameter data

DTSPN_network_context Variable, length 1 or 2 Network Context Range from 0 to 3 Default is 0.

Parameter name Parameter length Parameter data

DTSPN_routing_opt Fixed, length 1 Routing Options Bit 0: 0 Strict Routing (Default) 1 Preferred Order Currently, only bit 0 of the options is used; other bits should be set to zero.

Parameter name Parameter length Parameter data

DTSPN_routing_opt Fixed, length 1 Routing Options Bit 0: 0 Strict Routing (Default) 1 Preferred Order Currently, only bit 0 of the options is used; other bits should be set to zero.

30

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

6.3.3

Client Management Confirmations (DTS_CLIENT_CONF)

Synopsis: This will be sent from the server to the client module (DTS to DTC) to acknowledge client management requests. Message Format:
MESSAGE HEADER Field Name type id src dst rsp_req hclass status err_info len Meaning DTS_CLIENT_CONF (0x076b) 0 DTS_TASK_ID DTC_TASK_ID 0 0 0 0 1 PARAMETER AREA Offset 0 Size 1 Name Indication type octet.

Description: This message is used confirm client management request messages (CNT_MGMT_REQ) on client startup/shutdown. The instance field of the message is to be used to identify the sender and receiver of the message. Senders of this message should use GCT_set_instance to identify the server to which the message is addressed. On reception of the message the procedure GCT_get_instance can be used to retrieve the instance field, which will identify the sender of the message.

31

Operation

Parameter area contents: The management indication type is coded as follows:

Request Client Start-up Acknowledgement Client Shutdown Prepare Acknowledgement Client Shutdown Acknowledgement Mnemonic DTS_CLIENT_STARTUP DTS_CLIENT_SHUT_PRE Value (dec) 1 2 Value (hex) 0x1 0x2

DTS_CLIENT_SHUTDOWN

0x3

Message Acknowledgements The start-up, shutdown-prepare, and shutdown messages all have a single message sent back in acknowledgement. The message type is the same for all acknowledgements, but there is a single octet in the parameter area that indicates whether it is an acknowledgement for a start-up, shutdown-prepare, or a shutdown message.

6.4

RSI Link Status Messages

The server can receive messages regarding the status of the link between itself and another client. A message received indicating that the link is up is ignored. If a message is received stating that the link is down, the client at the other end of the link is immediately assumed to be in the "shutdown" state. This is because with the link down, the server does not know the state of the client. If the link went down only for a moment, a start-up message would still have to be sent from the client before the server would accept any messages from the client, or the server sending any messages to it.

6.5
6.5.1

Other Message Handling

Messages for SCCP
Messages for SCCP are simply passed transparently to SCCP. The source of the message will be marked as the server.

32

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

6.5.2

Messages for the Client

Messages for the client cannot simply be passed as those destined for SCCP, or a TCAP-User module. The first question to be answered is whether the message is part of an existing dialog or the start of a new dialog. If the message is the start of a new dialog, then this means that the message can be sent to any client in the "start-up" state. If there is only one client in the "start-up" state, then the message will go there. If there is more than one client in the correct state, then the selection method indicated in the configuration message for the server comes into effect. Currently, there are two selection methods available. Clients can be selected in ascending order of instance IDs, or descending instance IDs. This is to provide load sharing between clients. Alternatively, if the message forms part of an existing dialog, the instance of the client can be extracted from the message and the message will be sent to the client instance.

6.5.3

SCCP Management Messages

If a request is received (SCP_MSG_SCMG_REQ) from the client, this message is passed transparently down to SCCP. Currently the indication (SCP_MSG_SCMG_IND) is passed up to a single client that can be in the "startup" or "shutdown-prepare" states. If there is more than one client in either of these states, the client with the lowest instance ID will receive the message.

6.6

Start-up Sequence
The following section describes a recommended start-up sequence for DTS-based systems. Restart SIU units On each host Start host GCT environment Start host protocol modules Start DTC module on host Send protocol configuration messages Send DTC configuration message Enable host-SIU RSI link Send required DTS_CLIENT_REQ and optional DTS_ROUTING_REQ messages (section 6.3)

Begin normal TCAP traffic operation

33

Operation

6.7

Summary of DTS message handling

The tables below summarize the information provided in sections 6.3, 6.4, and 6.5 with reference to how messages received by the DTS module are handled. Where it is stated that a message is ignored, the message may still be traced if this is activated via the MMI. For messages to be routed to clients using Client Specific Selection functionality, the clients must be in the "startup" state and routing must be enabled for the clients in the selection groups that have been set up. If the clients in the selection groups are enabled, but have not been put in the "startup" state by way of a DTS_CLIENT_REQ message, then new dialogs will not be routed to the clients. If client is in "start-up" state:
Incoming message to Server STARTUP message from client SHUTDOWN_PREPARE from client SHUTDOWN from client Result Client already at start-up the message is ignored. Client set to shutdown-prepare state no new dialogs. Client set to shutdown state no messages will be sent to the client, nor will any be accepted from the client by the server. Message accepted (section 6.7.1). Passed transparently to SCCP. Passed up to client with the lowest instance ID that is not in the shutdown state. Client is assumed to be in shutdown-prepare state and will remain so until a start-up message is received. No effect in server waiting for start-up message.

DTS_ROUTING_REQ from client SCCP management request from user SCCP management indication from SCCP Link status message from RSI link down Link status message from RSI link up

If client is in "shutdown-prepare" state:

Incoming message to Server STARTUP message from client SHUTDOWN_PREPARE from client SHUTDOWN from client Result Client is available to receive new dialogs. Client already set to shutdown-prepare state message is ignored. Client set to shutdown state no messages will be sent to the client, nor will any be accepted from the client by the server. Passed transparently to SCCP. Passed up to client with the lowest instance ID that is not in the shutdown state. Client already at shutdown-prepare the message is ignored. No effect in server waiting for start-up message.

SCCP management request from user SCCP management indication from SCCP Link status message from RSI link down Link status message from RSI link up

34

Dialogic DSI Protocol Stacks DTS User Guide Issue 8

If client is in "shutdown" state:

Incoming message to Server STARTUP message from client SHUTDOWN_PREPARE from client SHUTDOWN from client SCCP management request from user SCCP management indication from SCCP Link status message from RSI link down Link status message from RSI link up Result Client is available to receive new dialogs. Client set to shutdown-prepare state no new dialogs. Client already set to shutdown state - the message is ignored. Server will not accept messages from clients in shutdown state the message is ignored. Passed up to client with the lowest instance ID that is not in the shutdown state. Client already set to shutdown state - the message is ignored. No effect in server waiting for start-up message.

6.7.1

DTS Routing Request Message Handling

The tables below summarize the processing of DTS_ROUTING_REQ messages. For more information on this message type, see sections 2.1 and 6.3.2. Any subsystem numbers used are for example only. If no routing keys exist:
Incoming DTS_ROUTING_REQ message to Server Enabled, strict routing, routing request message Enabled, preferred order, routing request message Disabled, strict routing, routing request message Disabled, preferred order, routing request message Any other message Result New key created, strict routing, with single client in selection group. New key created, preferred order, with single client in selection group. No key created No key created Result as specified in section 6.7

35

Operation

If strict routing, default routing key (SSN = 0) exists:

Incoming DTS_ROUTING_REQ message to Server Enabled, strict routing, routing request message (SSN = 0) Enabled, preferred order, routing request message (SSN = 0) Disabled, strict routing, routing request message (SSN = 0) Disabled, preferred order, routing request message (SSN = 0) Incoming messages for TCAP Any other message Result New client added to selection group. Client not added to group mismatched routing option. Client disabled within selection group. Client will not be disabled within group mismatched routing option. Will be routed via enabled clients within selection group of default routing key. Result as specified in section 6.7.

If strict routing, specific routing key (SSN = 0x10 and NC = 0) exists:

Incoming DTS_ROUTING_REQ message to Server Enabled, strict routing, routing request message (SSN = 0x10 and NC = 0) Enabled, preferred order, routing request message (SSN = 0x10 and NC = 0) Disabled, strict routing, routing request message (SSN = 0x10 and NC = 0) Disabled, preferred order, routing request message (SSN = 0x10 and NC = 0) Incoming messages for TCAP (SSN = 0x10 and NC = 0) Incoming messages for TCAP (SSN other than 0x10 and NC = 0 ) Any other message Result New client added to selection group. Client not added to group mismatched routing option. Client disabled within selection group. Client will not be disabled within group mismatched routing option. Will be routed via enabled clients within selection group of specific routing key. Will be routed using default routing key (if exists), otherwise message routed as specified in section 6.7. Result as specified in section 6.7.

36