Dialogic DSI Development Package For Linux Release Notes: Document Reference: RN003DPK Publication Date: March 2013

Dialogic DSI Development Package for Linux - Release Notes
Dialogic DSI Development Package for Linux Release Notes

Document Reference: Publication Date: RN003DPK March 2013
Contents
Release 6.5.1 ................................................................................................................ 2 Release 6.4.0 .............................................................................................................. 13 Release 6.3.8 .............................................................................................................. 22 Release 6.3.3 .............................................................................................................. 29 Release 6.2.9 .............................................................................................................. 32 Release 6.2.3 .............................................................................................................. 37 Release Notes for V6.10 ............................................................................................. 45 Release Notes for V6.04 ............................................................................................. 48 Release Notes for V6.03 ............................................................................................. 50 Release Notes for V6.01 ............................................................................................. 53 Release Notes for V5.11 ............................................................................................. 54 Release Notes for V5.09 ............................................................................................. 60
Release 6.5.1
Release 6.5.1 1 Overview

This release is a feature release which introduces the Dialogic DSI Diameter Stack providing support for the IETF Diameter Base Protocol and the ability to develop applications using Java. The Dialogic DSI Diameter Stack is a software implementation of the IETF Diameter Base Protocol which is intended to facilitate development of user applications that interface to LTE and IMS networks for the implementation of services in the areas of: Mobility, Location, Online Charging and Offline Charging. This release also adds a Java class library (gctApi.jar) which allows applications developed in Java to access the native C message passing library (gctlib) for allocating, releasing, sending and receiving messages for communicating between modules in a Dialogic DSI Software Environment. This release also contains a critical software update for any users of very new SS7LD boards. Boards with serial numbers RC920000 and greater number will not operate correctly with earlier software releases and must use this release. In addition to adding support for Diameter, this release adds: new license capacities for the SS7MD board and for M3UA, Drop & Insert capability for the SS7LD board, support for IPv6 when using RSI, support for M3UA multiple Local Application Servers (LAS) and support for 4096 M3UA routes. The release includes further changes and corrections as detailed below. This is the first Generally Available release of the Dialogic DSI Development Package for Linux since 6.4.0 and it is fully backwards compatible with that release.
1.1
Applicability
This release is applicable for all users. It is critical for users of SS7LD boards with serial numbers RC920000 and greater as previous software releases will not function on this version of the board. Users should note that the following changed directory names: The rpm UPD install path is now /opt/DSIUPD (previously /opt/dpkupd) and the shared library installation directories are now /opt/DSI/32 and /opt/DSI/64 (previously /opt/DSI/lib32 and /opt/DSI/lib64 respectively). The following User Documentation updates are applicable to this release of the Development Package: Dialogic Dialogic Dialogic Dialogic DSI DSI DSI DSI Software Environment Programmers Manual, Issue 13 Diameter Stack DMR Programmers Manual, Issue 3, Diameter Stack Diameter Functional API Manual, Issue 3, Network Interface Boards SS7LD Programmers Manual, Iss 3.
Release 6.5.1
1.2
Resolved Customer Issues

Updates to resolve the following customer issues are included in this release: IPY00100380, IPY00100673, IPY00100565 and IPY00102013.
2 New Functionality
2.1 Support for latest SS7LD Boards
New revisions of the SS7LD board with serial numbers RC920000 and greater use an on-board FPGA version that is incompatible with previous software releases. This release includes updated ssdl binary, SS7LD device driver and ss7.dc7 code file (V1.11) for use with all revisions of the board.
2.2
Dialogic DSI Diameter Stack

The Dialogic DSI Diameter Stack is a software implementation of the IETF Diameter Base Protocol which is intended to facilitate development of user applications that interface to LTE and IMS networks for the implementation of services in the areas of: Mobility, Location, Online Charging and Offline Charging. This release supports the S6a, S6d, S13, S13, SLh, SLg, Ro and Rf interfaces. The Dialogic DSI Diameter Stack includes a message based binary module (DMR), a Functional API Library and utility components and header files for use when developing a User Application. Dialogics Diameter Module (DMR) implements the Diameter Base Protocol offering a message based API to the User Application to control Diameter sessions. DMR is a member of the family of Dialogic DSI Components and offers similar message-based interfaces and management capabilities to those offered for other SS7 and SIGTRAN protocol layers. DMR uses the services provided by the SCTP layer of the Dialogic DSI SIGTRAN Stack for the transfer of messages between Diameter Peers. Use of DMR is documented in the DMR Programmers Manual. Dialogics Diameter Functional API is an API layer for use by the User Application allowing easy development of Diameter applications without being encumbered with complex encoding and decoding rules. This release introduces a Functional API for Java users. This contains a set of Java classes to support development of applications interfacing with the DMR module. It provides a Java-based API, designed to work in conjunction with the Dialogic DSI Software Environment messagebased interface. Full details of the API are contained in the Diameter Functional API Manual. The DSI Diameter Stack can be configured using the s7_mgt configuration utility which reads text based configuration commands from the config.txt file. The syntax of these commands is documented in the Software Environment Programmers Manual.
Release 6.5.1
2.3
Diameter License Server Operation

Operation of licensing for the Dialogic DSI Diameter Stack is slightly different from other Dialogic DSI Protocols in that is uses a License Server which must be running prior to starting the Diameter Stack. This section details operation of the license server: First ensure that a valid run-time license is placed in a well know location (outside the Development Package tree so that it is not overwritten when the Development Package is updated). For example use /opt/DSI-LICENSES. Before running gctload, startup the license server using the following command: /opt/DSI/LIC/lmgrd local c/opt/DSI-LICENSES Now startup gctload in the normal way. In order to add or change license files, after stopping gctload, it is necessary to shutdown the license server. This is achieved using the following command: /opt/DSI/LIC/lmutil lmdown c/opt/DSI-LICENSES The user will be presented with a list of running license servers on the local machine. The license server serving the dialogic vendor should be selected. When starting the DMR binary it is necessary to specify the path to the run time license on the command line using the Lp option. The following is an example of the appropriate system.txt syntax: FORK_PROCESS dmr Lp/opt/DSI-LICENSES
Note: Whilst the Dialogic DSI Diameter Stack is the only licensed procotol that requires a License Server, in the event that other Dialogic DSI Protocol Stacks are running (and using the dialogic vendor key), these protocols will also be licensed using the License Server whenever the license files are located in the folder managed by the License Server.
2.4
DTU/DTR Java Example Diameter Applications

The DSI Diameter Stack is supported by two new example applications written in Java: DTU Example Application for sending Diameter Update Location Requests. DTR Example Application for responding to Diameter Update Location Requests using Update Location Answers. Example configuration files are contained in the UPD/RUN directory. The Java source code for the examples is contained in the UPD/SRC directory. The existing makeall.sh shell script has been updated to build the applications and the resultant Java jar files will be placed in the UPD/BIN directory. Pre-built versions of the jar files are located in the JAVA directory.
Release 6.5.1
2.5
GCTLIB Support for Java Class access

This release add a Java class library (gctApi.jar) which supports access by Java applications into the native C message passing library gctlib. Further details on the Classes and methods supported are included in the Software Environment Programmer's Manual. These class files are required for use of the DSI Diameter Functional API but are also suitable for other Java applications which require access into the message-passing environment.
2.6
ssdm Additional SS7MD licenses

This release adds support to ssdm for additional licenses for the Dialogic DSI SS7MD Network Interface Board. The new licenses offer 96, 192, 384 and 512 LSL link equivalents providing more granularity and higher capacity. The largest license supports termination of up to 16 or monitoring of up to 32 High Speed Links. Note: When using Low Speed Links (LSL) a single instance of the Dialogic DSI MTP3 layer supports a maximum of 256 links.
2.7
SS7LD Drop and Insert Functionality

This release adds the ability to perform cross-connects between pairs of T1/E1 interfaces allowing a network facing interface which contains both voice and signaling to be separated into signaling (which is processed locally) and voice which can be passed via the second T1/E1 interface to the media processing card. Drop and Insert functionality is configured using the existing STREAM_XCON command in config.txt as detailed in the Software Environment Programmer's Manual. User of the Drop and Insert functionality requires both the updated ss7.dc7 (V1.09) code file and the ssdl and s7_mgt binaries.
2.8
MAP - NotifySubscriberDataModified service

Support for the MAP NotifySubscriberDataModified service has been added in accordance with the MAP specification 3GPP TS 29 002 version 10.3.0 (Release 10). The service is MAP-V3 only as defined in the specification.
2.9
MAP ProvideSubscriberLocation service

Support for the MAP ProvideSubscriberLocation service has been extended to include additional parameters. The implementation is now compatible with the MAP specification 3GPP TS 29 002 version 10.3.0 (Release 10).
2.10
MAP Additional Roaming Not Allowed Cause

New MAP V3 services error parameters have been added in support of the ProvideSubscriberLocation service. Additionally the new error parameter Additional Roaming Not Allowed Cause is now supported. These new error parameters are enabled for use by all MAP-V3 services supported by the MAP implementation that use the applicable error codes.
5
Release 6.5.1
2.11
M3UA Additional Licenses

This release adds support for new higher capacity licenses of 384, 512 and 768 equivalent links. The full range of supported M3UA licenses and the capacity of each is detailed in the table below:
Designation SS7SBHSTM3UAU SS7SBHSTM3UAS SS7SBHSTM3UAR SS7SBHSTM3UAL SS7SBHSTM3UAK SS7SBHSTM3UAJ SS7SBHSTM3UAM SS7SBHSTM3UAN SS7SBHSTM3UAP SS7SBHSTM3UAG Throughput 312kb/s 1,232kb/s 2,464kb/s 4,920kb/s 9,832kb/s 19,664kb/s 29,496kb/s 39,328kb/s 58,984kb/s 78,648kb/s Max Associations 4 16 32 64 128 256 256 256 256 256 TDM Link Equivalents* 4 16 32 64 128 256 384 512 768 1024
*This comparison assumes the use of 64kb/s links at a maximum loading of 0.6 Erlang. Individual user deployments may exhibit different characteristics from this in which case it may be necessary to provision more or less capacity accordingly.
2.12 2.13
M3UA Support for 4096 Routes

This release increases the number of M3UA routes supported to 4096.
M3UA Multiple Local AS support

This release supports the configuration and operation of multiple Local Application Servers (LAS). Changes to the configuration model now enable up to 4 LASs to be defined. Each LAS can be active across one or more shared associations with traffic distinguished by Routing Context (RC). A peer IPSP or SGP would typically have an entry in its routing table for each LAS with a 1:1 mapping of routing key to LAS. For each routing key a RC is defined which accompanies the traffic on the association, to identify the LASserver relationship to which it belongs. Previously all traffic was received by the single LAS and then distributed based on SI to the user parts. With Multiple LAS, traffic for a particular routing key from the peer SG or RAS is treated separately and when it arrives at the ASP it is distributed to the correct LAS, based on the RC. Each LAS-server relationship may be activated or deactivated independently of any other. This new functionality can be configured using s7_mgt using the LAS parameter in place of the AS parameter in the SNAPI and SNLBI commands. The RC value should now be specified on the SNLBI command.
Release 6.5.1
When used with configurations that include MTP User protocols such as ISUP or MAP, LAS1 will be configured with the appropriate Service Indicator and Module ID automatically. For all other LAS values the MTP_USER_PART command should be used. s7_mgt does not configure protocols which run above LAS2, LAS3 and LAS4. To define the service indicator and the module ID of the application or module to process messages for a specific LAS, the MTP_USER_PART command should be used.
LAS ID value 1 2 3 4 Network Context Value NC0 NC1 NC2 NC3 Default M3UA Module ID 0xd2 0xd6 0xd7 0xd8
Forexample:
MTP_USER_PART MTP_USER_PART MTP_USER_PART MTP_USER_PART NC0 NC1 NC2 NC3 05 05 05 05 0x2d 0x3d 0x6d 0x5d
To send traffic for additional LAS the following lines need to be present in the system.txt file, to send messages to the correct module ID. LOCAL REDIRECT REDIRECT REDIRECT REDIRECT 0xd2 0xc2 0xd6 0xd7 0xd8 * * * * * M3UA module Management task M3UA LAS2/NC1 M3UA LAS3/NC2 M3UA LAS4/NC3
0xd2 0xd2 0xd2 0xd2
The CNOPS and CNNCI commands now support multiple network contexts. The optional NC parameter can be used to identify the M3UA network context for which the remaining parameters apply. The M3UA network context is linked to the LAS as described in the table above. If the NC parameter is omitted the configuration applies to NC 0/LAS 1. CNOPS:MODULE=M3UA,MOD_ID=0x6d; CNOPS:MODULE=M3UA,MOD_ID=0xfd,NC=1;
2.14
M3UA Routing Key Management

This release adds support for the Routing Key Management (RKM) procedures when operating as an ASP. M3UA will send REG_REQ and DREG_REQ messages and handle the respective REG_RSP and DREG_RSP responses. Further details are available on request.
Release 6.5.1
2.15
RSI - IPv6 Support

This release adds support for connections between RSI clients and servers over IPv6 networks and for the destination address to be specified as a hostname. Configuration of an IPv6 link is achieved via the updated rsicmd utility which now accepts an IPv6 address (or hostname) on the command line. For a server connection, the IP address parameter is currently ignored and a socket is opened to allow a connection on the specified port via the hosts IPv4 or IPv6 address. For a client connection, the IP address parameter should either be an IPv4 address (in a.b.c.d format), an IPv6 address (in abcd:1234::5678 format as per RFC5952) or a hostname (eg rsihost.example). In the case of a hostname which resolves to multiple IP addresses (both IPv4 and IPv6), RSI will resolve the name once and will then attempt to connect to the server (over an IPv4 or IPv6 connection as appropriate) to each resolved address in turn until a connection is made.
3 Other Changes
3.1 Software Installation
Two changes have been made relating to software installation to remove inconsistencies in directory naming conventions: The rpm UPD install path is now /opt/DSIUPD (previously /opt/dpkupd). The shared library installation directories are now /opt/DSI/32 and /opt/DSI/64 (previously /opt/DSI/lib32 and /opt/DSI/lib64 respectively).
3.2
SS7LD Device Driver

The SS7LD signaling board device driver has been updated to remove a potential start up issue due to invalid host PCI bus access.
3.3
ssdm HSL Link Congestion (IPY00100380)

This release corrects an issue which limited (to 2,000) the maximum number of outstanding (unacknowledged) octets on an HSL link. As a result, links with high latency may have experienced link congestion and reduced throughput.
3.4
ssdm Low Speed Link Resource Exhaustion

This release corrects a problem that on the SS7MD board could lead to links entering a failed unrecoverable state as a result of receiving high traffic load in conjunction with a high number of configured links (eg 124).
Release 6.5.1
3.5
ssdm - LIU Statistics Gathering

This release corrects a threading issue which could result in the loss of LIU statistics request messages which in turn could result in exhaustion of messages in the software environment. The condition was triggered either when multiple outstanding requests for LIU statistics are present on the same port or when an LIU was reconfigured whilst an outstanding statistics request was being processed. Both conditions are now handled correctly.
3.6
SCCP Round-robin routing using Load Share tables

This release adds an SCCP global title load share table option to provide round robin selection of point codes. This option is bit 1 of the options field of the SCP_MSG_GLST_ADD message. When set to 1, successive messages are sent to the next available destination point code in a round-robin manner (irrespective of the SLS value in the message). When set to zero the SLS value is used to determine route selection.
3.7
SCCP Generating UDTS or SST response using RSP pc_mask

This release corrects operation when generating UDTS or an SST response towards a point code where the configured RSP (Remote Signaling Point) is identified by a pc_mask (rather than an explicit match of the point code. This ensures that the National Indicator is appropriately set from the configured RSP data.
3.8
SCCP Routing label format in API_MSG_TX_REQ id

SCCP can now optionally indicate the routing label format in the id field of API_MSG_TX_REQ messages. This is achieved when using config.txt by setting bit 2 in the <options2> parameter of the SCCP_CONFIG command. For message-based configurations set bit 2 (SCPX2F_PC_SIZE) in the ext2_options field of the SCP_MSG_CONFIG message. When enabled the id field in the API_MSG_TX_REQ message will be set to 0 for 14-bit, 1 for 24-bit and 2 for 16-bit point codes.
3.9
ISUP - 8 Bit SLS Operation

This release corrects generation of 8 bit SLS values when using bit 22 of the ext_1_options field for Circuit Group Configuration (ISPX1GOP_SLS8).
3.10
ISUP - Circuit group supervision message type handling (IPY00100673)

On receipt of a Circuit Group (Un)Blocking message or acknowledgement containing an invalid Circuit Group Supervision Message Type Indicator field, ISUP will now generate a Confusion Message with cause set to 110.
Release 6.5.1
3.11
ISUP - BICC Timer Configuration (IPY00100565)

Previously when a BICC variant circuit group was configured, ISUP incorrectly overwrote any user-configured timer values in the associated timer table. This has been corrected so that user-configured timer values are preserved.
3.12
TCAP - Maximum instance now 255

TCAP now supports instance values in the range 0 to 255. When using config.txt, the TCAP instance is configured using the <tcap_inst> parameter in the TCAP_CONFIG command.
3.13
TCAP Unnecessary use of large messages

TCAP now only attempts to allocate large messages when the payload exceeds 320 bytes. Previously, when large messages were available TCAP would allocate them in places where it was not necessary.
3.14
TCAP Use of maximum incoming dialogs

This release corrects an issue that prevented TCAP working correctly when configured for maximum (65535) incoming dialogs and zero outgoing dialogs.
3.15
TCAP Dialog Idle Timer (IPY00102013)

This release corrects a fault with the TCAP Dialogue Idle Timeout which previously resulted in timeouts greater than 6,553 seconds expiring early.
3.16
MAP Generation of Begin Subscriber Activity

When the MAP user specifies MAPPN_dest_ref and MAPPN_orig_ref parameters together with MAP-V1 application context parameter in a MAPOPEN-REQ message, the MAP module automatically sends a Begin Subscriber Activity (BSA) component to TCAP. Previously if the user also included the MAPPN_ellipsis parameter in the message the MAP binary could terminate. This issue has been corrected.
3.17
M3UA MTP label format in RX indications

M3UA now provides an indication of the MTP3 label format (or point code size) in the id field of the API_MSG_RX_IND message. This allows the user part module to determine the format of the MTP3 routing label contained within the message.
Mnemonic MTPTFR14 MTPTFR24 MTPTFR16 Value 0 1 2 Description MTP label contains 14-bit point codes MTP label contains 24-bit point codes MTP label contains 16-bit point codes
10
Release 6.5.1
3.18
M3UA Max SIF Length

A new parameter enables the size of Signaling Information Field (SIF) in outgoing transfer requests to be checked to ensure that the maximum SIF within the network is not exceeded. When using s7_mgt for configuration, the maximum SIF length is set using the MAXSIF parameter for the CNNCI command in config.txt.
3.19
M3UA Trace bit for Transfer Requests

A new trace event bit M3U_EVTI_SS7_TX_REQ (bit 16) has been added to the input event mask to enable tracing of MTP-TRANSFER-REQ messages received from the user part.
3.20
M3UA Updated header file definitions

Some M3UA message types and parameter names have been renamed in order to better reflect their usage. For example the message M3U_MSG_CNF_INT_NA (0x72c4) has been renamed M3U_MSG_CNF_NC to reflect that it is used to configure Network Context parameters. An all cases the original definitions are retained for backwards compatibility.
3.21
M3UA 8-bit SLS values with 5-bit rotation

This release corrects the operation of SLS rotation to ensure that when operating with 8-bit SLS values and 5-bit SLS rotation the most significant bits of the SLS are preserved rather than being set to zero.
3.22
M3UA DPC added to AS indications

This release adds the affected point code to the M3UA AS active and inactive indication messages M3U_MSG_AS_ACT_IND (0x02e0) and M3U_MSG_AS_INACT_IND (0x02e1). When using s7_log the point code is automatically decoded.
3.23
MST Filter M2PA SNM and SNT messages

This release adds two new bit values for use in the ss7_mask parameter in the MST TAP configuration message (MST_MSG_CFG_TAP). Bit 5 is used to allow receipt of MTP3 Signaling Network Management (SNM) messages and bit 6 is used to allow receipt of Signaling Network Test and Maintenance (SNT) messages when monitoring the M2PA protocol.
3.24
s7_log Increased Precision Timestamps

This release supports finer granularity in timestamps generated by s7_log. Selecting the tp command line option will cause timestamps to show microsecond resolution as follows: YYYY-MM-DD hh:mm:ss.uuuuuu
3.25
s7_log Additional Decode

s7_log provides additional decode of certain messages as follows: The DPC contained in M3UA AS active and inactive indication messages M3U_MSG_AS_ACT_IND and M3U_MSG_AS_INACT_IND is decoded.
11
Release 6.5.1
Decode of MTP_MSG_LINK_CONG message now correctly reports congestion status. TCAP Maintenance Events TCPEV_DLG_TIM_TIMEOUT and TCPEV_EXCESSIVE_DLG_ABORTS are now decoded.
3.26
s7_play Handling of missing newline (IPY00101131)

This release corrects an issue which could result in s7_play failing to correctly process a message when the line is not terminated by a newline character (\n).
Dialogic 22-Feb-13 Revised 06-Mar-13
12
Release 6.4.0
Release 6.4.0 1 Introduction

This is a feature release which adds support for Red Hat Enterprise Linux 6 and provides increased capacity support for the SS7MD board (up to 8 boards in a server) and the SS7LD board (up to 8 links in a system over multiple boards). The release also includes protocol updates to SCCP, MAP, M2PA and MST and enhanced status reporting through gctload. Further changes and corrections are includes as detailed below. This is the first full release of the Dialogic DSI Development Package for Linux since 6.3.8 and it is fully backwards compatible with that release. NOTE: Dialogic recommends that the complete Development Package is used when upgrading from a previous release. If this is not possible users should note that licensed protocol binaries from the 6.4.0 (and later) releases will not work with versions of the gctlib shared object library prior to the 6.4.0 release. If a user needs to use a 6.4.0 (or later) licensed binary in conjunction with an earlier release of the Development Package then it is essential to also install and use the gctlib shared library from the 6.4.0 (or later) Development Package.
1.1
Applicability
This release is applicable to all users. If a user needs to use a 6.4.0 (or later) licensed binary in conjunction with an earlier release of the Development Package then it is essential to also install and use the gctlib shared library from the 6.4.0 (or later) Development Package. The following User Documentation updates are applicable to this release of the Development Package: Dialogic Dialogic Dialogic Dialogic Dialogic Dialogic DSI DSI DSI DSI DSI DSI Software Environment Programmers Manual, Issue 10 Protocol Stacks SCCP Programmers Manual, Issue 9, Protocol Stacks TCAP Programmers Manual, Issue 12, Protocol Stacks MAP Programmers Manual, Issue 16, Network Interface Boards SPCI Programmers Manual, Iss 7, Protocol Stacks DTS User Guide, Issue 9.
This release includes an updated ss7.dc4 code file (V5.12) for use with the Dialogic SS7HD Network Interface Board and the ss7.dc7 (V1.08) code file for use with the Dialogic SS7LD Network Interface Board. The release notes for the code files are available separately. This release includes an updated SNMP M3028_6_2 MIB package (V2.02) which includes support for the Dialogic DSI SS7G41 Signaling Server.
13
Release 6.4.0
1.2

Updates to resolve the following customer issues are included in this release: IPY00099225, IPY00093617, IPY00094357 and IPY00099532.
2 New Functionality
2.1 Support for Red Hat Enterprise Linux 6
This release includes support for the Red Hat Enterprise Linux 6 distribution including device drivers for the SS7MD, SS7LD, SS7HD and SPCI boards.
2.2
SS7LD 8 link support

A new 8 link license for the SS7LD board allows up to 8 links to be supported (up to 4 per board) in an SS7LD board installation. This functionality requires use of the SSDL and s7_mgt binaries from this release and the appropriate license.
2.3
SS7MD Support for up to 8 Boards in a Server

This release extends the number of SS7MD boards which can be supported in any individual server from four to eight.
2.4
GCTLOAD Enhanced Status reports

This release includes updates to gctload to provide additional information when run with the t option to provide status reports. All status reports now include the date and time in the output. The gctload t1 output now includes additional measurements which may optionally be reset by the user using the command gctload t1r which will display the current values and then reset the new measurements. The new measurements are the maximum number of messages allocated in each partition since reset and the number of congestion events since the last reset. In addition the time of the last congestion onset and the time of maximum message allocation (since reset) are both displayed. The gctload t1 output now also indicates whether there are time limited licenses in use within the system. The gctload t3 output has been modified and now includes the process id of the last process to read from the message queue. A new gctload t4 option has been added to list all host software licenses current in use and in the event that the license is time limited it shows the expiry date for the license.
2.5
SCCP Per-RSP Configuration of SIO/SSF

To allow use of different Sub Service Field (SSF) values across a network, SCCP now allows optional configuration of the Service Indicator Octet (SIO) on a per RSP basis. When using s7_mgt for configuration, this is achieved using the new optional parameter <ssf> in the SCCP_SSR command: SCCP_SSR <ssr_id> RSP <remote_spc> <flags> <pc_mask> [<ssf>]
14
Release 6.4.0
Note: The use of multiple SSF values requires appropriate capabilities in the underlying MTP3 link set configuration.
2.6
SCCP Disable UDTS generation on routing failure

A new option allows the user to prevent SCCP from automatically generating a UDTS/XUDTS response when it is unable to route a message. When using s7_mgt for configuration, this is achieved by setting bit 1 in the <options2> field of the SCCP_CONFIG command. SCCP_CONFIG <local_spc> <ssf> <options> [<options2> [<partner_id> <instance>] ] Note: The <options2> field was previously called <management_options> the operation of bit 0 remains unchanged from previous versions.
2.7
SCCP - Connection Oriented Configuration

s7_mgt now supports configuration of SCCP Connection Oriented operation using config.txt. Connection Oriented operation is activated by setting bit 31 in the <options2> parameter of the SCCP_CONFIG command. This will result in s7_mgt using the following fixed parameter values in the SCP_MSG_CONFIG message:
Parameter num_uc uc_onset uc_abmt base_id top_id min_id max_id 2048 1536 1024 1024 2047 0 2047 Value
2.8
MAP - CHECK-IMEI V3 Request Parameter made Optional

Some proprietary implementations of the CHECK-IMEI service do not include the RequestedEquipmentInfo parameter. In order to allow compatibility with these implementations, the MAP module has been changed so that the MAPPN_requestedequipinfo (515) parameter is no longer mandatory for the MAP V3 CHECK-IMEI request operation. Users should note however that for full compliance with the MAP V3 specification the RequestedEquipmentInfo should be included.
15
Release 6.4.0
2.9
MAP Additional parameters for SMSC services

Support for the following parameters has been added within MAP:
Parameter Additional Alert Reason Indicator SM Delivery Not Intended IP SM GW Indicator IP SM GW Delivery Outcome IP SM GW Absent Subscriber Diagnostic SM Mnemonic MAPPN_add_alert_reason_ind MAPPN_sm_deliv_notintended MAPPN_ip_sm_gw_ind MAPPN_ip_sm_gw_deliv_outcome MAPPN_ip_sm_gw_abs_sub_diagsm Value (dec) 586 587 588 589 590 Value (hex) 0x24a 0x24b 0x24c 0x24d 0x24e
The parameters are used within the following services; full details are contained within the MAP Programmers Manual: SendRoutingInfoForSM service (MAP v3) InformServiceCentre service (MAP v3) ReportSMDeliveryStatus service (MAP v3) ReadyForSM service (MAP v3)
2.10
M3UA - Audit for Congested Destinations

This release extends the destination audit mechanism to include periodic auditing of a congested destination following receipt of SCON from a Signaling Gateway.
2.11
MST Long Message Support

This release supports the ability to pass messages containing between 321 and 4200 payload octets to the user without truncation. Previously messages were truncated at 320 octets. The new functionality is enabled by setting bit 0 in the options field of the MST configuration message (MST_MSG_CONFIG). Users must also ensure that sufficient long messages are created using the NUM_LMSGS command in the system.txt file.
2.12
MST License Capacity Alarm

In the event that the actual data throughput through the MST module exceeds an onset threshold of 80% of the licensed capacity the module will generate an alarm using the MGT_MSG_LIC_EVENT message with event_type set to value 4 (Throughput Alarm) and event_indicator set to value 1 (Alarm Active). When the throughput reduces below an abatement threshold (40% of the licensed capacity) the clearing of the alarm is indicated by the same message but with the event_indicator set to value 0 (Alarm Inactive).
2.13
s7_mgt - SCTPN SACK delay timer

The SACK Delay timer may now be configured using the CNTOS command. The previous default value of 200ms could result in retransmissions by the remote end under low traffic loads. The default value is now 10ms and can be configured with the command:
16
Release 6.4.0
CNTOS:TTYPE=SCTP,TO=SACKD,TMSEC=50;
2.14
s7_log - Daily log files

A new option has been added to s7_log for use when rolling log files are enabled to cause a new file to be started the first time a new event is logged each day. This functionality is enabled by adding the new r option (in conjunction with the n option). This behavior applies to both text and PCAP format log files. For example: s7_log -ffilename.log -n10 r -s10000
3 Other Changes
3.1 ssdm - In Service Duration Statistics Revised (IPY00093617)
The In Service Duration reported for MTP2, Q.SAAL and ATM running on the SS7MD board has been changed to units of 100ms for compatibility with other boards.
3.2
ssdm Board Statistics and Event Reports

A number of minor corrections have been made to statistics gathering for the SS7MD board including: preventing negative values at initialization, preventing corruption of MTP2 statistics when reading layer 1 statistics and correcting the OOS and PRBS measurements in the LIU statistics. This release prevents generation of multiple consecutive ATM Stream State Out of Service indications and corrects the algorithm for reporting AAL5 frame errors.
3.3
GCTLIB - GCT_pending_msgs() (IPY00094357)

This release changes the operation of the GCT_pending_msgs() function to ensure that the DSI environment is up and running before attempting to access it. Previously a segmentation fault was possible if an application called GCT_pending_msgs() when gctload was not running.
3.4
MTP2 / Q.SAAL - Configurable trace_id

The SS7MD, SS7LD and SS7HD boards now support MTP2/Q.SAAL tracing to the alternative <trace_id> as specified using the TRACE_MOD_ID command in config.txt. For the SS7HD board this requires the use of ss7.dc4 V5.12 or later and for the SS7LD board this requires the use of ss7.dc7 V1.08 or later.
3.5
TCAP - Receipt of TCAP Abort

A fault has been corrected where, under certain conditions, received TCAP Abort messages were reported to the TCAP User as P-ABORT rather than UABORT.
17
Release 6.4.0
3.6
TCAP - User Information in P-ABORT-IND

TCAP, when operating in ITU-T mode, has been enhanced to report User Information from a received TC-P-ABORT Dialogue Portion to the user in the TCPPN_USER_INFO parameter which is now optional for this message. Previously User Information was only reported for TC-U-ABORT.
3.7
MAP - Accept MAP Refuse PDU from a TCAP P-ABORT

This release detects and decodes User Information contained in received PABORT-IND messages. If the information is for a MAP-Dialogue PDU with Refuse Info reason = invalidDestinationReference or invalidOriginationReference, the module will send a MAP-OPEN-CNF message to the MAP-User setting the appropriate MAPPN_refuse_rsn and with MAPPN_result = dialogue refused (1). This results in a received MAP Dialogue Refuse PDU being reported to the MAP-User in the same way, whether reported by TCAP as a P-ABORT or a UABORT.
3.8
MAP - Reports timeout on Abort from TCAP

The TCAP module has an option (TCPF_DLG_TIM_ABORT) that will automatically abort dialogues after a timeout period. MAP has been updated to recognise these aborts and close the associated MAP dialog. When this happens MAP will send a MAP-DIALOGUE-IND, MAP-P-ABORT-IND message to the MAP-User with the new provider reason (MAPPN_prov_rsn) = MAPPR_idle_timeout (7).
3.9
MAP - Diagnostic corrected when L_REJECT received

An invalidly formatted response message causes TCAP to send an L_REJECT message (problem code = Badly Structured Component) to MAP and MAP will then send a MAP-NOTICE-IND message with a problem diagnostic (MAPPN_prob_diag) to the MAP-User. Previously MAP reported the problem diagnostic Response Rejected by Peer (1) with the Notice message. This has been corrected for this release to report the problem diagnostic Abnormal Event Received from Peer (2).
3.10
MAP - ASN.1 BIT STRING encodings

This release ensures that sufficient parameter octets are available to convey the maximum amount of ASN.1 BIT STRING encoded data required by the MAP specifications. Previously some parameters only supported a single octet which was insufficient. The MAPPN_mwd_status parameter (which is the only parameter encoded/decoded within the MAP module) now always sends six ASN.1 BIT STRING encoded bits but will support receipt of three, four or six bits of validly formatted ASN.1 BIT STRING data.
18
Release 6.4.0
3.11
SCTP/SCTPD - Detection of path recovery

This release improves detection of SCTP path failure and restoration in a multi-homed environment. It corrects an issue which in specific circumstances resulted in failure to detect path recovery. Previously if path failure was detected by lack of acknowledgement to a DATA element and no subsequent DATA elements were transmitted then path recovery was not detected. Transmission of a subsequent DATA element cleared the issue.
3.12
SCTP/SCTPD - Receipt of INIT on an active association (IPY00099225)

This release corrects operation upon re-initialisation of an SCTP association that has not been closed (ie. receipt of an INIT whilst association is active) which previously caused the module to fail.
3.13
SCTP/SCTPD - Tracing received messages

This release includes the ability to trace data messages sent from SCTPD to SCTP. The functionality can be enabled by setting the DATA_REQ (bit 5) in the ip_evt_msg parameter within the SCTP_MSG_TRACE_MASK message (0x5285)
3.14
SCTP/SCTPD TSN Event Indications

This release adds support for additional diagnostic event indications using the new SCTP_MSG_EVENT_IND (0x029e) message. The message status value will include the Event Type value as shown below.
Event type SCTP_EVT_UNEXP_EVENT SCTP_EVT_HIGH _TSN SCTP_EVT_LOW_TSN Value 1 2 3 Description The retransmission list is invalid for the association Invalid SACK received with a TSN higher than the expected range Invalid SACK received with a TSN lower than the expected range
3.15
M2PA Link Configuration Defaults

The M2PA Link Configuration message (M2P_MSG_LINK_CONFIG) now allows timer values and congestion thresholds to be set to their default value by setting the corresponding field in the message to zero. Default values are defined in the M2PA Programmers Manual Issue 4.
3.16
M2PA Timer Operation

This release corrects an issue with M3UA timers that could cause incorrect timer duration. In addition T3 operation has been corrected so that on expiry (during the proving period), the alignment cycle is aborted and the links goes into the Out Of Service state.
19
Release 6.4.0
3.17
M2PA Link Statistics Duration Counters

Minor corrections have been made to the generation of duration values (stats_duration & cong_duration) in the M2PA Read Statistics Request (M2P_MSG_R_STATS).
3.18
M2PA Message retrieval

This release includes a correction to ensure that all messages can successfully be retrieved following a link failure. Previously messages received from MTP3 after a link had failed were not buffered and could not be retrieved.
3.19
MST Recovery from lost connection

The algorithm used for in-sequence message delivery has been corrected to ensure immediate recovery following loss of an association.
3.20
MST Measurements and Event Indications

A number of minor corrections have been made to the MST statistics gathering mechanism within the MST_MSG_R_STATS, MST_MGS_R_THR_STATS and MST_MSG_R_ASSOCIATION_STATS messages. Within the MGT_MSG_LIC_EVENT message, the protocol_type is now correctly set to the value 5 (LICMOD_MST) to allow the recipient to determine the source of the event.
3.21
s7_mgt - HSL <data_rate>

In previous releases, s7_mgt would incorrectly configure the system where the MTP_LINK or MONITOR_LINK commands for HSL links omitted the <data_rate> parameter. Where the <data_rate> parameter is omitted, information from the LIU_CONFIG command will now be used.
3.22
s7_mgt - INAP_FE command

In previous releases, the INAP_FE command did not configure the module ID for the local FE correctly. s7_mgt will now use the module ID of the LSS associated with the SSN which is encoded in the <sccp_address> parameter.
3.23
s7_mgt - MTP3 with alternate module ID

This release corrects a problem, when the CNOPS command was used to configure an alternative module_id for the MTP3 module, but the link activation request message was sent to the default module ID for MTP3.
3.24
s7_play module_id configuration

s7_play now allows the module_id that it uses for its input queue to be modified dynamically during execution of a playback file. A new R command can be used within the playback file to configure the module_id that s7_play uses for subsequent message reception. The command takes a single 16 bit parameter designated m as follows: R-m002d
20
Release 6.4.0
3.25
s7_play Waiting forever

This release prevents s7_play waiting forever for a response to a message that it failed to send. In the event that during execution of the W command GCT_send() fails, s7_play now reports an error and terminates.
3.26
s7_log Additional decode (IPY00099532)

s7_log now fully decodes the MGT_MSG_LIC_EVENT message. When decoding the M3U_MSG_NOTIFY_IND message, s7_log now only displays the ASP identifier when present in the message. Previously ASP=0 was displayed when the ASP identifier was not present. s7_log will now log messages traced from the MTP3 to MTP2 interface on the SPCI board to the PCAP log file. These messages are of type SS7_MSG_TX_REQ and were not previously mapped to PCAP format.
3.27
dsistat - M3UA, TCAP & LIU Status

The dsistat management tool has been enhanced to report TCAP resource and TCAP dialog status. Handling of the id value for when requesting the status of a M3UA Remote Server has been corrected and additional LIU measurements for bit errors and code violations are displayed.
3.28
dsitrace - M3UA and AAL5 Tracing

The dsitrace management tool has been enhanced so that it can be used to activate ATM AAL5 tracing. The default trace mask for M3UA used by dsitrace has been modified to request tracing API_MSG_TX_REQ and API_MSG_RX_IND messages. Previously the input and output mask were by default set to 0 requiring a user to always specify which messages should be traced. Dialogic 22-Mar-12 Revised 13-Apr-12
21
Release 6.3.8
Release 6.3.8 1 Introduction

This is a maintenance release which includes protocol enhancements to M3UA, SCCP, TCAP, MAP, MST, SCTPN and SCTP in addition to a number of changes and corrections as detailed below. This release is fully backwards compatible with the previous release.
1.1
Applicability
This release is applicable to all users. For correct operation of SCTP/SCTPD and SCTPN binaries, it is essential that the updated s7_mgt binary is also used. Release notes for the board code files are contained in separate documents and can be downloaded from the web-site. The following code files have been updated and are included as part of this Development Package: ss7.dc4 V5.11 ss7.dc7 V1.06 The following User Documentation updates are applicable to this release of the Development Package: Dialogic DSI Software Environment Programmers Manual, Issue 9, Dialogic DSI Protocol Stacks MAP Programmers Manual, Issue 15, Dialogic DSI Signaling Software Sigtran Monitor Programmers Manual, Issue 5.
1.2

Updates to resolve the following customer issues are included in this release: IPY00093718.
2 New Functionality
2.1 SCCP / M3UA Support for 16 bit Point Codes
SCCP can now be configured to operate with 16 bit Point Codes as used in Japan. This mode of operation is selected by setting bit 15 of the ext_options parameter in the SCCP Module Configuration message (SCP_MSG_CONFIG ) or setting bit 31 in the <options> field of the SCCP_CONFIG command in config.txt. When using 16 bit point codes, users should ensure that compatible options are selected for the MTP3 or M3UA layers. M3UA can now be configured to operate with 16 bit point codes for use in Japan. This option is selected by setting the SS7MD parameter to ITU16.
22
Release 6.3.8
2.2
SCCP Segmentation/Re-Assembly for XUDTS

This release extends segmentation and re-assembly functionality to include XUDTS messages. SCCP now handles segmentation and re-assembly for XUDTS messages in the same manner as XUDT messages.
2.3
TCAP - Include TCAP Version in outgoing messages

This release adds an option to force the TCAP module to include TCAP Protocol Version information in the messages it sends to SCCP. The TCAP Version information sent for ITU identifies Q.771-5 1997 (and 1993) specifications and for ANSI T1.114 1996. This option is enabled by setting bit 12 of the options parameter in the TCAP_MSG_CONFIG message or bit 12 of the <options> field in the TCAP_CONFIG command in config.txt.
2.4
TCAP - Option to stop sent address being replaced by received address

This release adds an option to force TCAP to always use the original Called Party Address throughout an outgoing dialogue rather than allowing it to be replaced by the address received in the first response received from the far end. To activate this feature, bit 11 of the <options> parameter in the TCAP_CONFIG command should be set to 1.
2.5
MAP - Selective Tracing enabled by default

Selective Tracing within MAP, as documented within the MAP Programmers Manual, is now enabled by default for all events. If required the MAP_MSG_S_SELTRACE_MASK message can be used to modify which events are selectively traced.
2.6
M3UA - SLS Rotation 8 bit option

The options field of the M3U_MSG_CNF_INT_NA message has been extended to support a new option to allow full 8 Bit SLS rotation. Bit 0 should be set to 1 to activate SLS rotation. When SLS rotation is activated, options bit 1 is set to 1 to select 8 bit SLS rotation or set to zero for default SLS rotation based on MTP label format.
2.7
M3UA - Selective Tracing

M3UA operation has been enhanced to automatically generate a trace of any received message that results in generation of an M3U_MSG_M3U_EVENT (0x02ee) event indication. The trace is intended to assist with problem diagnosis and is sent to the trace module id (0xef by default but may be configured with the TRACE_MOD_ID <trace_id> command)
23
Release 6.3.8
2.8
MST Management Events and Selective Tracing

MST generates a Selective Trace indication whenever a formatting error is detected within the received packet. This release introduces additional, more specific, reasons for the formatting error and generates an additional event report to the management module when a formatting error occurs. The event report uses a new message MST_MSG_EVENT_IND (0x0e4c) Generation of Selective Tracing and Management Event Indications is, by default, enabled however this release adds the ability to enable or disable both on a per event basis using a new message which sets the selective trace mask (MST_MSG_SELTRACE_MASK (0x5e50). Both new messages are documented in the Sigtran Monitor Programmers Manual - Issue 5.
2.9
MTR - AnyTimeInterrogation
The MTR example application in the User Part Development package has been updated to include support for the MAP AnyTimeInterrogation service.
3 Other Changes
3.1 Software Installation
The example system and protocol configuration files supplied with the Development Package have been renamed 'example_system.txt' and 'example_config.txt' respectively. This is intended to prevent customer modified configuration files getting deleted when the package is updated.
3.2
GCTLIB - REDIRECT
The operation of the REDIRECT command has been corrected so that redirection only applies when messages are being sent and does not impact or modify the input queue that a receiving module reads from.
3.3
Device Drivers (IPY00093718)

The signaling board device drivers have been updated to remove a dependency on the deprecated kernel header file ioc32.h when building drivers for 2.6.15 kernels or later. This, for example, removes an issue encountered when building with Debian 6.0.2 AMD64 containing kernel 2.6.32. In the previous release on insertion of the SS7LD device driver some chassis experienced PCI-e related NMI errors. This issue has also been resolved.
3.4
SS7MD ssdm improvements

This release includes improvements to ssdm and the device driver for the SS7MD board to prevent premature board shutdown or board failure indications during periods of host congestion. The ssdm binary includes additional diagnostic capabilities to assist with factory diagnosis of field issues.
24
Release 6.3.8
Operation of the MVD_MSG_LIU_STATUS and LIU_MSG_R_STATE messages have been corrected to ensure the correct line interface status is always reported. When monitoring MTP2 Low Speed Links or Q.703 Annex A High Speed Links using the SS7MD board, changes in the state of the MTP2 Backward Indicator Bit are counted and stored in the NACK_count field of the MTP2 measurements. Value validation for VCI/VPI values has been corrected and some restrictions relaxed. For VPI values a maximum of 4 bits can be set and for VCI values a maximum of 10 bits can be set. The total number of bits set applies across all boards in a system. For systems where this constraint is too restrictive, further information on VCI/VPI configuration can be supplied on request.
3.5
ssdl Messages longer than 256 Octets

This release includes a correction within SSDL to ensure messages containing more than 256 octets are correctly handled.
3.6
SCCP Connection ID allocation

The method of allocating incoming SCCP Connection IDs for Connection Oriented operation has been enhanced so Connection IDs will cycle through the full range of values before reusing previous values.
3.7
TCAP - ASN.1 non-minimum length encodings are now accepted

The TCAP specification Q.773 states that when ASN.1 encoding messages, length encodings should use as few as possible octets, e.g. encodings such as 0x8174 and 0x820074 should both be sent as 0x74. Previously both the TCAP module would reject received network messages that did not conform to this rule. This restriction has been relaxed to accept messages use ASN.1 nonminimal length encoding. Outgoing message are always encoded in accordance with the TCAP specification using the minimum number of octets for ASN.1 lengths.
3.8
MAP - GPRS Node Indicator parameter support

MAP services SendRoutingInfoForLCS and SubscriberLocationReport now support the GPRS Node Indicator parameter, MAPPN_gprs_node_ind (123).
3.9
MAP - Correction to Ellipsis parameter processing

Unrecognised parameters in received MAP messages are stored in the MAP Ellipsis parameter (MAPPN_ellipsis). This release corrects a problem (for some services including CHECK_IMEI) that previously caused only the first unrecognised parameter to be stored. A potential problem with ellipsis parameter formatting has also been corrected.
25
Release 6.3.8
3.10
MAP - TC-REJECT parameters passed to user

On receipt of a valid TCAP REJECT component from the network, MAP now uses two new parameters to pass additional TCAP component data to the MAP user for diagnostic purposes. MAPPN_tcap_rej_problem_code (584) contains the Problem Code (0 to 7) of the REJECT component and MAPPN_tcap_rej_problem_type (585) contains the Problem Code tag that was used (0x80 to 0x83). The interpretation of the problem code value is dependent on the tag used. Reception of a valid REJECT component will cause a MAP-NOTICE-IND dialog message or a MAP-SERVICE-CNF message (with error parameter) to sent to the MAP-User. In both cases the two new parameters will now be returned in the messages. For the MAP-NOTICE-IND message, the existing parameter MAPPN_invoke_id (14) will now also be returned with the new parameters to identify the component referenced by the REJECT (MAPPN_invoke_id is already returned by the MAP-SERVICE-CNF message).
3.11
MAP - ASN.1 indefinite length termination octets being returned in ellipsis data
When MAP encounters unrecognised data in received messages, it is returned to the MAP-User in the Ellipsis parameter. In the previous releases where the unrecognised data has been encoded using ASN.1 indefinite length encoding, it is possible for length termination octets EOC (two 0x00 octets) to be returned at the end of the Ellipsis parameter data. This release corrects the fault. Ellipsis parameter data will not be incorrectly terminated by indefinite length encoding termination octets.
3.12
MAP - Begin Subscriber Activity with single address

For previous releases if the MAP-User specified only one of MAPPN_dest_ref (2) and MAPPN_orig_ref (4) parameters, sending of the BEGIN-SUBSCRIBERACTIVITY (BSA) service would be attempted and fail with MAPSWE_TX_FMT_ERR being reported. This has been corrected so that if only one of the parameters is present, it is ignored and the BSA component is not sent.
3.13
MAP - MAPPN_unk_sub_diag in MAP NOTE-MMEVENT service

MAP now allows the optional parameter MAPPN_unk_sub_diag (61) to be used in the response for the MAP NOTE-MM-EVENT service when a User Error of Unknown Subscriber is returned.
3.14
MAP - User and Provider Errors supported for all services

MAP now allows the error parameters MAPPN_user_err (21) and MAPPN_prov_err (22) in all MAP services that return a response to the MAPUser.
26
Release 6.3.8
3.15
SCTP/ SCTPN Default Rx Window Size

This release addresses an issued identified with some Linux kernel SCTP implementations which could result in the association failing under heavy load. When configured in conjunction with s7_mgt from this release SCTPN allows the kernel to use the system default receive window size. Previously s7_mgt explicitly requested SCTP/SCTPN to use a receive window size of 64K bytes. Now it requests SCTP/SCTPN to use the default window size and within SCTP this is set to 64K bytes whilst for SCTPN it is set to the default kernel value.
3.16
SCTPN - Default SACK Delay value

This release sets the default SACK delay value to 10ms which is more appropriate for use in a telecoms network than the previous 200ms value.
3.17
SCTPN Preventing unnecessary Tx message discard

This release contains corrections to SCTP transmit operation to prevent unnecessary message discard as the underlying transmit buffer reaches capacity.
3.18
SCTP / SCTPN - Management Event Indications

SCTP and SCTPN now generate event indications to management whenever the state of an association or a path within an association changes. The messages (SCTP_MSG_STATUS_CHANGE, SCTP_MSG_NETWORK_STATUS & SCTP_MSG_CONG_STATUS) are identical in format to the messages documented within the SCTP Programmers Manual which are issued to the SCTP user. The events are fully decoded by the updated s7_log binary.
3.19
SCTP - Long Heartbeat Memory Leak

This release corrects an issue where a received Heartbeat message in excess of 300 bytes would cause a memory leak within the SCTP association and eventually lead to association failure requiring module restart.
3.20
M3UA - Management error messages

Management error messages received from an M3UA peer contain a range of Tags, some of which were erroneously being rejected. The module has been updated to accept all tags that can be present. In addition the range of error codes allowed has been extended.
3.21
M3UA - MBM local traffic mode

A backwards compatibility issue for systems where MBM configuration messages are still used has been rectified. The issue affected systems using message based configurations where the local traffic mode was set using the MBM_MSG_CFG_AS (0x72f7) message. The traffic mode was not sent in ASPACTIVE requests to the peer, but has now been rectified.
27
Release 6.3.8
3.22
M3UA - Multiple DOWN indications

In the previous release M3U_ASS_STATUS_DOWN indications were repeated during association activation until the remote end became active. In this release a single DOWN indication will be generated when the association is activated, and any retries will not be reported.
3.23
MST - Failure to recover from System Congestion

This release corrects a problem which previously could cause failure of MST to recover from system congestion. MST also ensures that the instance field is correctly set in messages issued to the application.
3.24
MTU More messages to send flag

This release includes a correction within the MTU example application for the setting of the more messages to send flag when sending an SMS. In addition there is a correction to the address setting in the TP-OA parameter.
Dialogic 21-Nov-11
28
Release 6.3.3

This release is a feature release which adds support for the new Low Density Half Length PCIe form factor Dialogic DSI SS7LD Network Interface Board. This is the first Generally Available version of the Development Package for Linux since V6.10. All users should refer also to the Release 6.2.3 and Release 6.2.9 Release Notes (below) for full details of the changes in the format of the Development Package which now consolidates all host binaries and code files into the Development Package. This release is fully backwards compatible with the previous release.
1.1 1.2
Applicability
This release is suitable for all users.

Updates to resolve the following customer issues are included in this release: IPY00093553 and IPY00093295.
2 New Functionality
2.1 Support for SS7LD Board
This release adds support for the Dialogic DSI SS7LD Network Interface Board. It includes a new binary SSDL and a new code file ss7.dc7 specifically for use with SS7LD boards. Full details of the operation of the SS7LD Board are provided in the Dialogic DSI SS7LD Network Interface Board Programmers Manual, Issue 2 which should be read in conjunction with the ss7.dc7 code file release notes.
2.2
INAP API - New AIN protocol services

This release adds three new services (ResourceClear, TerminationAttempt and SendNotification) for the AIN protocol - GR-1299-CORE. Further details on the parameter coding for these services is available on request.
3 Other Changes
3.1 s7_log Filename format
s7_log now allows the format of the filename for rotating log files to optionally keep the .log extension as the last part of the filename so that the format is maint.2.log (instead of maint.log.2). This is activated by including the x option on the command line.
29
Release 6.3.3
3.2
Extended License Check delay (IPY00093553)

This release corrects an issue that under some circumstances (in particular on newer faster machines) resulted in the software license check for all licensed binaries taking an extended time to complete (eg several minutes).
3.3
Device Drivers under Debian-based distributions

This release corrects a device driver build issue encountered under certain Debian-based Linux distributions (eg Ubuntu).
3.4
ssdm - Board Failure Under High Traffic Loads

In previous releases, ssdm could exhaust its internal resources when operated under high traffic conditions. This issue has been resolved.
3.5
s7_mgt - Max links for Diva boards

The s7_mgt limit on the number of signaling links supported on the DIVA Signaling board has been increased from 4 links to 64 links.
3.6
tempmon Operation in 64-bit Systems

The tempmon utility, for use with SS7MD boards has been corrected to avoid falsely returning null temperature values on 64-bit machines.
3.7
gctlib Potential Core Dump When Using Incorrect Configurations

This release corrects an issue that could have resulted in a core dump if either ssd or s7_mgt was run when gctload is not running.
3.8
INAP API - Correction to certain AIN tag values

Three tag values, used for existing AIN services have been corrected as follows:
Parameter AINPN_GenericName (551) AINPN_TriggerInformation (24) AINPN_AMABillingFeature (65) Affected AIN Services AnalyzeRoute InfoAnalyzed, InfoCollected AnalyzeRoute, Disconnect, SendToResource Previous TAG 0xa1 0x9f, 0x21 0x9f, 0x3a Corrected Tag 0x9f, 0x21 0x9f, 0x81, 0x21 0x9f, 0x58
30
Release 6.3.3
3.9
INAP API - Ellipsis processing for CAMEL protocols (IPY00093295)

For this release, decoding of ellipsis has been changed for CAMEL services that define additional parameters following the ellipsis. For these services any unknown data (and all following parameter data) in a received message will always be placed in the ellipsis parameter as if it was located at the end of the message. The following services are affected by this change: CAP v2 InitialDP CAP v3 InitialDPSMS CAP v3 InitialDPGPRS CAP v3 ApplyChargingReportGPRS CAP v4 EstablishTemporaryConnection CAP v4 Connect CAP v4 InitialDPSMS CAP v4 InitialDPGPRS CAP v4 ApplyChargingReportGPRS
3.10
INAP API - IN_decode_error()AIN op code handling

The API function IN_decode_error() now correctly supports operation codes greater than 256 which is particularly important for AIN operations where operation codes are always greater than 256. Previously only the least significant 8 bits were recovered. Dialogic 12-May-11
31
Release 6.2.9

This release is a maintenance release containing a number of important corrections relating to the operation of the SS7MD board. It also includes important changes to SCTP and MST binaries and a number of minor changes and corrections to M3UA and MAP. The release is fully backwards compatible with the previous release.
1.1
Applicability
This release is suitable for all users. Due to the important corrections included in this release, all users of the SS7MD card should upgrade existing deployments to this release as soon as practical in order to avoid potential issues including board lock-up. All users of the Sigtran Monitoring software (MST) should also upgrade to this release to avoid potential message loss of some M3UA messages.
1.2

Updates to resolve the following customer issues are included in this release: IPY00091767, IPY00092738.
2 New Functionality
2.1 SS7MD Use of Protected Monitoring Points
This release enhances SS7MD support for monitoring by introducing a new mode of operation for use when attaching to a Protected Monitoring Point (PMP). In this mode the receiver sensitivity of the E1/T1 interfaces on the SS7MD is increased to compensate for the loss introduced by the PMP. The new mode of operation is selected using the liu_type parameter in the LIU_CONFIG command in config.txt. When monitoring using a PMP liu_type should be set to 8 for E1 interfaces and 9 for T1 interfaces. When connecting to a PMP this should be the preferred mode of operation.
2.2
SS7MD Link status for AAL5 Monitor Links

This release enhances the mechanism for generating IN SERVICE / OUT OF SERVICE indications for an AAL5 Monitored Link so that if the rate of received messages falls below a fixed threshold of 10 messages per second the link is deemed to be out of service. Under normal operating conditions the link management messages will ensure that traffic exceeds this rate. Link state is indicated using the ATM_MSG_LINK_STATE (0x026b) message defined in the SS7MD Programmers Manual.
32
Release 6.2.9
2.3
ssdm Enhanced Tracing Capabilities

This release adds support for tracing of messages received from the SS7MD board when in AAL5 monitoring mode. Tracing is enabled at run-time by setting Trace Masks using a new message ATM_MSG_TRACE_MASK. Further details are available on request.
2.4
MST - Enhanced Tracing Capabilities

This release adds support for tracing of messages and events received and generated by MST. Tracing is enabled at run-time by setting Trace Masks using a new message MST_MSG_TRACE_MASK. Further details are available on request. In addition, MST will also automatically report any badly formatted messages received from the network using the Selective Trace mechanism.
3 Changes
3.1 SYSTEM.TXT Default NUM_MSGS
The example system.txt file now uses a value for NUM_MSGS of 5000 (instead of 10000 previously). This is to avoid unnecessarily consuming large amounts of memory in small, low throughput systems.
3.2
ss7.dc6 - SS7MD Monitoring Failures (IPY00092738)

Under certain circumstances, when operating the SS7MD in MTP2 monitoring mode, reception of over-length frames could cause the board to lock-up. Also when operating in AAL5 monitoring mode, reception of CRC errors could cause the board to lock-up. Typically this behavior would have been triggered as a result of errors or frame slips on the E1/T1 interface. The ss7.dc6 code file (V1.13) within this release corrects both these issues.
3.3
ssdm - MTP2 Retransmission Buffer Size

The previous release artificially limited the capacity of the MTP2 Retransmission Buffer for the SS7MD board when in Basic Error Correction Mode to 400 octets. This has been corrected so the capacity is now up to 2000 octets.
3.4
ssdm - Reading SS7MD Statistics

This release corrects an issue which, under certain circumstances, could cause statistics request messages (ATM, LIU & MTP2) for the SS7MD board to be rejected or lost.
3.5
ssdm - Board Watchdog

This release implements a heartbeat mechanism to ensure rapid detection and shutdown of SS7MD boards in the event of failure.
33
Release 6.2.9
3.6
ssdm - Failure to free licenses on reset

This release corrects an error in the release of per-link licenses for the SS7MD board when the board is reset which previously could result in exhaustion of licenses following multiple resets of the board.
3.7
ssdm Additional internal diagnostics

The ssdm binary includes additional diagnostic capabilities to assist with factory diagnosis of field issues. The capabilities do not impact normal operation and are not applicable to the user.
3.8
MAP - Maximum size of user UESBI data

To align with the MAP specification, the maximum size of UESBI data has been reduced (from 128 to 16 octets). This affects the MAPPN_uesbi_iua and MAPPN_uesbi_iub parameters.
3.9
MAP Additional error codes

MAP now supports the following user error codes: MAPUE_unknown_MSC (3) MAPUE_no_handover_number_available (25) MAPUE_subsequent_handover_failure (26) MAPUE_forwarding_failed (47)
3.10
MAP - Missing mandatory parameters in user response data

MAP now checks for missing mandatory parameters when the MAP-User enters response data. For previous releases it was only request data that was checked for missing mandatory parameters. The check now applies to both request and response primitive entry using the MAP_MSG_SRV_REQ message. Reporting of missing parameters is unchanged (from request checking): a MAPSWE_USER_MAND_MISSING error is reported in a MAP_MSG_ERROR_IND message and the number of the first mandatory parameter not found is given in the parameter data.
3.11
MAP Handling of segmented Result components

In the event that reassembly of partial response data fails (for TCAP segmentation using TC-RESULT-NL and TC-RESULT-L messages), instead of simply discarding the previously stored data, MAP will abort the affected InvokeID. If abort occurs after a TC-RESULT-NL message, U-CANCEL is sent to TCAP, followed by MAP_CNF with a Provider error to the MAP-User and finally a UREJECT to TCAP. Aborts that occur after a TC-RESULT-L message will just send the MAP_CNF message with Provider error. The Abort may be caused by parameter format checks or exhaustion of the buffer space. Exhaustion of the buffer space is also reported using MAPSWE_TC_RESULT_NL_TOO_BIG. In addition this release modifies the processing of the SendParameters service so that response data received in multiple messages (one or more TCRESULT-NL messages followed by a TC-RESULT-L) is correctly handled.
34
Release 6.2.9
3.12
MAP Invalid user-supplied Invoke id in response

If MAP receives an unknown Invoke ID in a response primitive in the MAP_MSG_SRV_REQ message, a software event report will now be generated. The event report uses the MAP_MSG_ERROR_IND message with error code MAPSWE_USER_INVOKE_ID_UNKNOWN (27) with the id field set to the UserDialogID and the first Diagnostic code set to the invalid InvokeID. MAP will also optionally generate a selective trace message with trace reason code MAPt_user_invoke_id_unknown (16).
3.13
SCTP - Bundled chunks (IPY00091767)

This release corrects the handling of multiple SCTP chunks in a single message to ensure that all chunks are correctly delivered to the user. Previously if more than ten chunks were received bundled in a single SCTP message, delivery to the user was not guaranteed.
3.14
SCTP - SCTP_MSG_TX_REQ Invalid Stream

If an invalid stream is passed from the user in a SCTP_MSG_TX_REQ message it will now be rejected with a SCTPE_BAD_PARAM error code rather than be rejected by the remote end after transmission of the message.
3.15
SCTP - Transmit Buffer Allocation

This release increases the number of SCTP Transmit Buffers allocated to reduce the likelihood of entering congestion. Typically two buffers are used for each data message and previously this resulted in congestion being encountered at lower buffer occupancy than intended.
3.16
M3UA - Network Appearance Removal

Prior to this release M3UA would only process a M3U_MSG_UNMAP_NA (0x72cd) message for M3UA links 0-3. This has been corrected and now works for all M3UA links.
3.17
M3UA - Link Deactivation

Operation of the message M3U_MSG_DEACT_ASSOC (0x72cf) which causes an association to shutdown has been changed back to the pre Release 6.2.3 operation such that an SCTP_MSG_ABORT (0x728c) is sent to SCTP to requesting an immediate shutdown. This ensures more deterministic behavior.
3.18
M3UA - DAVA causes crash

A problem within M3UA that potentially could cause the binary to crash upon reception of DAVA (Destination Available message) from an SGP has been corrected.
35
Release 6.2.9
3.19
MST - M3UA Message Parse Error

Previous releases incorrectly calculated padding bytes following variable length parameters when recovering received M3UA messages. This resulted in some lost messages and an incrementing count in the Bad Format of the per-module statistics. This fault, which typically only impacted messages containing the optional Correlation ID parameter, has been corrected.
3.20
s7_log - Additional Decode

s7_log now provides a full decode of all M2PA and M3UA status messages and notifications. In addition when displaying TCAP software events, if an unknown event is encountered it will display the <event_code> as an integer.
3.21
s7_mgt - Board Failure Diagnostics

s7_mgt now forwards SSD event notifications (MGT_MSG_EVENT_IND and MGT_MSG_DIAG_IND) to module_id 0xef (REM_API_ID) to allow the events to be logged by s7_log.
3.22
User Part Examples - Support for 64-bit Build

The User Part Development (UPD) make script, makeall.sh, has been updated to allow the UPD examples to be built as 32-bit (default) or 64-bit binaries. The commands to build the UPD modules as 32-bit binaries are: ./makeall clean ./makeall.sh 32bit The commands to build the UPD modules as 64-bit binaries are: ./makeall clean ./makeall.sh 64bit
3.23
Device driver version written to kernel log

To facilitate diagnostics, the version number of the device driver is now written to the kernel log. This version number is the same as the release of the Development Package. Dialogic 13-Apr-11
36
Release 6.2.3

This release is a feature release containing new functionality and changes to the overall structure of the Development Package. The release adds SNMP capability for boards and host protocol software and includes several protocol updates and corrections as detailed below. This release consolidates all the functionality of the previous Development Package along with all Host Protocols binaries, all board code files and the , User Part Development Package (UPD) into a single distribution. All hostbased software binaries take the same binary release number using a new three-part release designation Release x.y.z. This is the first release since V6.10 and incorporates the first release of all host based protocols subsequent to the following (Changes since these releases are documented in these release notes): MTP3 V5.04 ISUP V5.08 TUP V4.02 SCCP V3.09 TCAP V6.05 MAP V5.16 IS41 V4.05 INAP V5.01 M3UA V5.01 M2PA V3.01 SUA V1.05 MST V2.00 Release notes for the board code files are contained in separate documents and can be downloaded from the web-site. The following code files are included as part of this Development Package: ss7.dc3 V1.16 ss7.dc4 V5.09 ss7.dc6 / ima.dc6 / ss7mcd.dc6 V1.10 The following User Documentation updates are applicable to this release of the Development Package: Dialogic Dialogic Dialogic Dialogic Dialogic DSI DSI DSI DSI DSI SS7 Protocol Stack MAP Programmers Manual, Issue 14, SS7 Protocol Stack TCAP Programmers Manual, Issue 11, SS7 Protocol Stack SCCP Programmers Manual, Issue 8, SS7 Protocol Stack M3UA Programmers Manual, Issue 6, Protocol Stacks SNMP User Manual, Issue 2.
This release is backwards compatible with the previous release.
37
Release 6.2.3
1.1
Applicability
This release is suitable for all users. In particular users of the Dialogic DSI SS7MD Board are advised to upgrade to this release as it includes enhancements to the driver and code file to prevent occasional board shutdown issues.
1.2

Updates to resolve the following customer issues are included in this release: IPY00091590, IPY00091767 and IPY00092143.
2 New Functionality
2.1 Enhanced Development Package Structure
The Development Package for Linux has been enhanced to include, in a single distribution, all the software required by board and host software users of the Dialogic DSI SS7 Boards and Dialogic DSI Protocol Stacks. The Development Package now includes all host protocol binaries, board code files and the example software from the User Part Development Package. This allows users to update multiple components within a single installation cycle. As part of this change, all host based software now uses a three part release number in the form Release x.y.z to uniquely identify the software version. The new format replaces the Vx.yy format used previously and aligns with the format used on other Dialogic Products. Furthermore all host based binaries that form part of this distribution have the same release number. For example:
DSI gctload Release 6.2.3 (Build 1030) Part of the Dialogic(R) DSI Development Package for Linux Copyright (C) Dialogic Corporation 1994-2010. All Rights Reserved.
In order to provide common binary names across different operating systems and therefore simplify use and documentation, the names of a number of host binaries have changed so that they no longer include the _lnx designation. Users will need to modify the system.txt file accordingly in order to use the new filenames. tick_lnx becomes tick tim_lnx becomes tim mtp3_lnx6 becomes mtp3 isup_lnx6 becomes isup tup_lnx6 becomes tup sccp_lnx6 becomes sccp tcap_lnx6 becomes tcap map_lnx6 becomes map is41_lnx6 becomes is41 mst_lnx6 becomes mst In order to remove ambiguity the DSI shared objects are now located in subdirectories, lib32 for the 32 bit libraries and lib64 for the 64 bit libraries.
38
Release 6.2.3
2.2
SNMP Support
This release adds SNMP support for boards and protocols to the Development Package. The Dialogic Distributed Structured Management Information (DSMI) Simple Network Management Protocol (SNMP) Agent provides SNMP monitoring functionality for the Dialogic DSI SS7 Development Package. Dialogic DSMI SNMP software supports SNMP V1, V2 and V3 reporting the state and events for Dialogic DSI SS7 Boards and Dialogic DSI Protocol Stacks through use of SNMP traps as well as queries from a SNMP manager. The Dialogic DSMI MIBs are distributed within /opt/DSI as a compressed ZIP file: dsi-mibs.zip. For details of the DSMI SNMP MIBs supported, events, SNMP traps and configuration refer to the Dialogic DSI Protocol Stacks SNMP User Manual. SNMP events generated by MTP3 can optionally be traced by setting bit 22 (MTP_EVT_SNMP_DSA) op_evt_mask parameter of the MTP_MSG_TRACE_MASK message. SNMP events generated by M3UA can optionally be traced by setting bit 14 (M3U_EVTO_SNMP_DSA) in the op_evt_mask parameter of the M3U_MSG_TRACE_MASK message.
2.3
User Part Development Package

The example software and configuration files within the User Part Development (UPD) package have been updated and changed to simplify use. This release features new and updated configurations which all use the DSI s7_mgt configuration utility rather than message based scripts, making the configuration process more complete and easier to follow. The UPD provides users with an easy way to try out various DSI protocols and also provide developers with example source code on which they can base their own applications. In addition the User Part Development Package Makefiles have been updated to simplify the build process should users wish to rebuild the samples. A number of issues in the sample source code have been resolved and all the binaries rebuilt.
2.3.1
New Functionality
M3UA configurations have been added for MTU, MTR and CTU this allows users to use M3UA directly without having to first convert the previous M2PA offering. The INTU code has been updated to recognise CAPv4 and CAPv4 for IMS Application Contexts. MTU/MTR now support additional MAP services including USSD services, MT Forward SMS and SRI for SMS
39
Release 6.2.3
2.3.2
Usage Instructions
Prebuilt binaries for all examples are supplied within the Development Package. These can easily be rebuilt (to produce 32bit binaries by default or 64bit binaries by using the 64bit flag) using the makeall file as follows. makeall.sh clean makeall.sh Or makeall.sh clean makeall.sh 64bit
2.3.3
Running UPD samples

From within the UPD RUN directory select the directory for the concerned sample, and then the configuration type (M3UA, MTP or M2PA) and CONFIG, CONFIG_1 or CONFIG_2. For M3UA and M2PA configurations in the config.txt file change the IP addresses to match the local and remote systems. For MTP configurations ensure the board type, codefile and board interface task are correct for the host system within the config.txt and system.txt files. From within the same directory run gctload and then the sample itself unless it is started (forked) within system.txt. For detailed information on running each sample, refer to the relevant UPD sample user guide. Note: The development package contains the latest version of the configuration files which may differ from those given in the user guides.
2.4
Reading number of pending messages

The ability to read back the number of outstanding messages queued on a message queue has been added. This can be achieved using a command line option for gctload or programmatically using a new function GCT_pending_msgs() contained within gctlib. To use gctload the user should run a second instance of gctload using the t3 option as follows, this will list the number of queued messages on each local message queue: gctload t3 LOCAL 0x10: 5 messages queued. LOCAL 0x20: 0 messages queued. Alternatively the function GCT_pending_msgs can be used to programmatically return the number of messages currently queued on a single named local message queue. The function prototype is: int GCT_pending_msgs(unsigned int module_id) The function returns a positive integer indicating the number of messages currently queued on message queue, module_id or a negative integer on error.
40
Release 6.2.3
2.5
RSI Link Statistics

This release adds the ability to read back measurements from the RSI module on a per link basis. It is necessary to run the new RSI and RSI_LNK binaries to support this functionality. A new message RSI_MSG_R_LNK_STATS (0x6f87) has been defined for this purpose. Full details are available on request. The measurements can also be read using the updated version of the dsistat command line management utility using the following command syntax: dsistat RSIL STATS 0 For full command syntax run dsistat with the h option.
3 Other Changes
3.1 Trial Mode
The period for which licensed binaries can be run without a license in trial mode is set to one hour after which the binary will terminate.
3.2
SS7MD driver (IPY00091590)

This release corrects an issue within the SS7MD device driver which could result in the board spontaneously shutting down, potentially causing an operating system Dazed and Confused message, typically soon after startup. Users should also ensure that the latest *.dc6 code file is used.
3.3
GCTLOAD - Host Verification

To prevent run-time errors due to incorrectly configured systems GCTLOAD has been updated to always verify that the host operating system has sufficient system resources to support the DSI environment specified in system.txt. GCTLOAD will terminate if the system resource verification fails. Previously GCTLOAD only verified the host operating system's system resources if the 'VERIFY' command was present in system.txt.
3.4
SCCP - User generation of SCCP UDTS/XUDTS

In most situations where a UDTS/XUDTS message is required to be sent, it is automatically generated by the SCCP module. In some situations it may be desirable for a received UDTS/XUDTS to be passed up to the user in a Notice indication and for this to be used to generate an onward UDTS/XUDTS to a further node. In order for a user to do this the SCCP module now supports generation of UDTS and XUDTS messages on demand. A new primitive type octet is added for this purpose. For further information refer to the SCCP Programmer's Manual.
41
Release 6.2.3
3.5
TCAP - Configurable trace module id

A Trace Module ID can now be defined in the TCAP Module Configuration message (TCP_MSG_CONFIG). The new trace_id field uses a previously reserved field in the message. If trace_id is defined as non-zero, then all trace messages are sent to that module id. If trace_id is set to zero, trace messages are sent to the Management Module ID (mngt_id) as for previous releases. For further information refer to the TCAP Programmer's Manual.
3.6
MAP - Message generation after MAP-NOTICE-IND and/or TC-U-REJECT

For previous releases, MAP was not correctly handling some situations that required MAP-NOTICE-IND messages to be sent to the user and/or U-REJECT to be sent to TCAP and the dialog was left in an inappropriate state. MAP should either close the dialog and send a MAP-CLOSE-IND message or move to a next state and send the user a MAP-DELIMITER-IND message. This release ensures that it is correctly handled. In order to prevent unexpected behaviour in some MAP applications this change can be disabled using a MAP configuration option. It is recommended that this option should only be set when the messages now being generated cause problems for the MAP application. Otherwise the flag should be set to 0. For further information refer to MAP Programmer's Manual.
3.7
SCTP - Bundled chunks (IPY00091767)

This release corrects the handling of multiple SCTP chunks in a single message to ensure that all chunks are correctly delivered to the user. Previously if more than ten chunks were received bundled in a single SCTP message, delivery to the user was not guaranteed.
3.8
SCTPN - Preferred Path Selection

A new configuration option has been added to SCTPN to cause automatic selection of the preferred path for routing whenever that path is available. This means that in the event of recovery of the preferred path, traffic will automatically revert back to the preferred path rather than continue using the alternative path. This first host IP address configured for the association is designated as the preferred path. The functionality is activated by setting bit 5 in the options field of the SCTP configuration message (SCTP_MSG_CONFIG). This can be achieved in config.txt using the following command: CNOPS:MODULE=SCTP,OPTIONS=0x0020;
3.9
SCTPN - Recovery from Congestion

Previously a problem within SCTPN resulted in a failure to recover correctly from software environment congestion. Consequently SCTPN associations would fail. This issue, which was introduced in the Development Package for Linux 6.3.0, has been corrected.
42
Release 6.2.3
3.10
SCTPN Message discard during congestion

Previously when an association was configured as the server end, if the remote end of an SCTP association became congested new outgoing messages were buffered instead of being discarded. This has been corrected to prevent exhaustion of messages within the software environment.
3.11
M2PA Throughput Licensing

Prior to this release the M2PA throughput licensing mechanism incorrectly calculated the number of received octets. This has been corrected.
3.12
M3UA - Heartbeat
M3UA now supports the ability to turn on heartbeats at the M3UA level. This capability is not usually required as the underlying SCTP protocol has its own heartbeat mechanism. For further information refer to the M3UA Programmer's Manual.
3.13
MST - Virtual packets for an invalid port

In the previous release an IP Message (MST_MSG_IP_MSG) received for an invalid port (out of range or not configured) was not handled correctly. In this release the IP message will be discarded correctly.
3.14
MST - Port device names

The Configure MST Port message (MST_MSG_CFG_PORT) in the previous release would reject an empty device name for ports of port type virtual. This is now accepted. Empty device names for ports of port type Ethernet will still be rejected.
3.15
MST - Traffic Filtering

The TAP configuration message (MST_MSG_CFG_TAP) has been updated to allow monitored traffic to be filtered according to the SS7 event mask (ss7_mask) and SIGTRAN event mask (stn_mask) parameters. The MGT_MSG_CFG_TAP options parameter settings are: Bit 0 When set traffic will be monitored if it meets selection criteria within both the SS7 event mask and the SIGTRAN event mask. When bit 0 is not set traffic will be monitored if it meet at least one selection in one of the masks. Bits 1-31 Reserved for future use and should be set to zero.
3.16
s7_mgt - LIU_CONFIG <options>

The LIU_CONFIG command now supports an <options> parameter which is used to further select advanced clocking options for certain board types (eg. SS7MD). The full syntax of the command is: LIU_CONFIG <board_id> <liu_id> <liu_type> <line_code> <frame_format> <crc_mode> [<build_out> <options> ] Use of the <options> parameter is detailed in the per-board user documentation.
43
Release 6.2.3
Note: When not required the <build_out> parameter should be set to zero.
3.17
s7_mgt SCTP Retransmission Counts

s7_mgt now allows the user to modify various SCTP retransmission limits at configuration time using the SNSLI command in config.txt. Three new parameters are added: RTXI (max_retx_init), RTXD (max_retx_data) and RTXB (max_retx_heartbeat). The values can be set in the range 1 .. 20. If omitted the parameter is set by s7_mgt to 2. SNSLI:SNLINK=,IPADDR=,[SG=,][SS7MD=,][IPADDR2=,][IPADDR3=,] [IPADDR4=,] [HIPADDR=,][HIPADDR1=,][HIPADDR2=,][HIPADDR3=,] [HIPADDR4=,][HPORT=,][PPORT=,][SNEND=,][SNTYPE=,] [M2PA=,][M2PA_VER=,][HPORT=,][PPORT=,][RTXI=,][RTXD=,][RTXB=];
3.18
ssdm CRC4 Status

When operating in CRC4 mode the previous release incorrectly indicated IN SYNC prior to establishing full CRC4 multi-frame synchronization. This has been corrected so that the IN SYNC indication now implies that full CRC4 synchronization has been established.
3.19
ssdm Reading Statistics

This release corrects an issue which could cause ssdm to fail when handling various status and statistics requests for the board.
3.20
GCTLIB Segmentation Fault (IPY00092143)

This release corrects an issue that could potentially result in a segmentation fault when executing GCT_xxx() functions when using GCT_link() and GCT_unlink() to dynamically attach and detach from the DSI environment. Typically only specialized applications make use of GCT_link()/GCT_unlink() so the majority of deployments are unaffected by this issue. Dialogic 22- Dec-10
44
Release Notes for V6.10
Release Notes for V6.10 1 Overview

This is the first release of the Linux Development Pack since V6.04. The release introduces three new command line management utilities to simplify control of, and status gathering from, protocol modules and activation of trace masks It includes enhancements to s7_mgt for configuration of the latest M3UA release and a TXA binary to allow Dialogic DSI User Part software to be used in conjunction with Dialogic TX Series SS7 Boards. This release includes further enhancements as detailed below including the ability for s7_log to create multiple rolling log files when configured to create PCAP format logs. The release is fully backwards compatible with the previous release.
1.1 1.2
Applicability
This release is of particular use for M3UA users.

Updates to resolve the following customer issues are included in this release: IPY00081954 and IPY00081819.
2 New Functionality
2.1 s7_mgt - M3UA Configuration - Default Routes
The SNRTI command which is used to configure SIGTRAN routes now has a new optional OPTIONS parameter to allow existing and future per-route options to be selected within config.txt at run-time. The content of the OPTIONS parameter is used to populate the <options> field in the M3UA Route Configuration message M3U_MSG_CNF_ROUTE. Initially the main use of this parameter is to designate the route as a Default Route. Bit 0 1 2 Mnemonic M3UOP_ROUTE_ASSUME_AVAIL M3UOP_ROUTE_LOADSHARE M3UOP_ROUTE_DEFAULT Meaning Assume route always available Loadshare across all servers in the route Default Route
If the OPTIONS parameter is omitted then s7_mgt will default to using the value 0x0002 to provide full backwards compatibility with the previous release.
45
Example usage of the new parameter is as follows: SNRTI:SNRT=1,DPC=200,OPTIONS=0x0004;
2.2
Management Utilities dsictrl, dsistat and dsitrace

This release includes three new management utilities (dsictrl, dsistat & dsitrace) to assist the user when performing management functions from the command line. dsictrl allows control of MTP links, Sigtran links, LIUs and ISUP circuit groups using a command line interface. dsistat allows status and measurements to be easily extracted from individual protocol modules using a command line interface. dsitrace allows trace masks for individual protocol modules to be conveniently set using a command line interface. For a full syntax listing run the tool with the h option.
2.3
TXA binary to run DSI User Parts above TX Series Boards

This release includes a binary TXA which allows host-based Dialogic DSI User Part protocols to be run above the Dialogic TX Series SS7 Boards. This is of particular use for existing users of deployed TX Series boards that may wish to run MAP, INAP or IS41 protocols in conjunction with host-based TCAP and SCCP above MTP3 running on the TX Series board. Refer to User Guide: Running DSI User Parts Over Dialogic TX Series SS7 for full information.
2.4
s7_log - Rolling PCAP Log files

The ability for s7_log to generate capacity limited rolling log files has been extended to include PCAP format log files. When generation of PCAP log files is activated using the p option, whenever either of the two options s or n are activated the PCAP log file will automatically be in the form of multiple, capacity constrained files with a numeric suffix.
2.5
s7_mgt - SIGTRAN Link Auto-Activation

s7_mgt has been updated to allow automatic activation of Sigtran associations to be disabled by the user if not required. The new optional AUTOACT parameter of the CNSYS command should be set to N to disable auto-activation of Sigtran associations. For example: CNSYS:IPADDR=192.168.1.20,AUTOACT=N;
46
3 Other Changes
3.1 s7_log Preservation of previous log file
s7_log has been updated to create a backup of the existing log file, if one exists, with the filename <logfile_name>.old. For example, if s7_log is configured to capture its output to the log file, 'log.txt' and it detects an existing copy of 'log.txt' then 'log.txt' will be renamed 'log.txt.old' and a new 'log.txt' file will be created. NOTE: This functionality is applicable only when s7_log is configured to use a single log file and does not apply when either the s or n options are used to create multiple rolling log files.
3.2
s7_mgt GTT Configuration (IPY00081954)

In previous versions, when configuring an ITU Global Title Translation with the Global Title Indicator set to 0100, on occasions bit 8 of Octet 3 of the Global Title was incorrectly set to 1. This bit will now always be set to 0.
3.3
GCTLIB - Thread Initialisation (IPY00081819)

In previous releases an error could occur if multiple threads of an application tried to initialise the GCT environment at the same time. This has been corrected.
3.4
SCTPN - Association Reconfiguration Failure

Attempts to activate a reconfigured Server SCTP association could result in the SCTPN binary failing. This has been corrected.
3.5
SS7HD Device Driver with Fedora Core 10

In previous releases the SS7HD device driver failed to build (compile) with the RedHat Fedora Core 10 kernel. This has been corrected. Dialogic 03-Feb-10
47

This release contains enhancements to the inter-process communication mechanism which significantly increase system throughput in both single and multi-core processor deployments. The release also includes enhancements or corrections to SCTP and the utilities s7_log and s7_mgt as detailed below. This release is fully backwards compatible with the previous release.
1.1
Applicability
All users should upgrade to this version of the Development Package to gain significant improvements in performance.
1.2

Updates to resolve the following customer issues are included in this release: IPY00080214, IPY00081007 and IPY00081077.
2 New Functionality
2.1 Performance enhancements for Multi-Core Processors
The underlying inter-process communication mechanism has been enhanced to have less dependency on global system-wide resources in order to better exploit the capabilities of multi-core processor architectures. As a result, significant performance gains in terms of system throughput are achieved. Systems based on multi-core processors are able to fully utilise the additional cores whilst even single core processors achieve increased throughput. The Multi-Core Optimisations require the use of gctload and gctlib from this Development Package. They are fully compatible with all current versions of Dialogic DSI Protocol Stacks for Linux achieving performance gains without the need to upgrade protocol versions. Note: The Multi-Core Optimisations utilise processor instruction sets found in Intel 80486 and later processors. In the unlikely event that an older processor type is in use, this development package can still be used but users should first contact Dialogic for additional configuration requirements.
48
3 Other Changes
3.1 SCTP Congestion Control
The congestion control mechanism in previous releases of the SCTP binary (but not the SCTPN binary) limited maximum throughput to 1,800 messages/s per association. This restriction no longer exists.
3.2
SCTPN - Association Reconfiguration (IPY00081007)

It is possible to dynamically reconfigure SCTP association to add and remove addresses. The association being modified should first be deactivated and then reconfigured before being activated again. A potential problem causing excess CPU utilization and association failure as a result of dynamic reconfiguration has been corrected.
3.3
s7_log PCAP Corruption (IPY00081077)

Previous releases of s7_log created corrupt PCAP log files when capturing trace event messages (SS7_MSG_RX_IND, API_MSG_TX_REQ and API_MSG_RX_IND) from a module. This resulted in WireShark displaying corrupt packages and has now been corrected.
3.4
s7_mgt Global Title Address Limitations

Previous releases of s7_mgt limited global title addresses to 8 octets or less. This has been corrected.
3.5
s7_mgt SCCP and TCAP Trace Module Id

This release supports setting the trace_id for SCCP and TCAP to the value specified in the TRACE_MOD_ID command (subject to using a version of SCCP and TCAP that supports the configurable trace_id). In previous releases this command was not supported for SCCP or TCAP protocols so the default value of 0xef was used. Dialogic 26-Sep-09
49

This release of the Dialogic SS7 Development Package for Linux includes updated support for the Dialogic DSI SS7MD Network Interface Board to allow termination of ATM Q.SAAL links. This release also includes enhancements to the inter-process message passing mechanism to allow 64 bit applications to co-exist with the 32 bit Dialogic DSI Host Protocol Software. This is the first release since V6.01 and is backwards compatible with that release although all users will need to adjust the kernel settings as detailed in section 2.1 to provision additional capacity within internal message queues. NOTE: This applies to all users, irrespective of the functionality being used. Users should note that this release is no longer compatible with old style statically linked Host Protocol binaries or with the host utilities provided with Development Package V4.01 or earlier.
1.1

Updates to resolve the following customer issues are included in this release: IPY00080025, IPY00080200, IPY00080425.
2 New Functionality
2.1 Adjusting kernel parameters
Due to the change made to support co-existence of 32 and 64 bit binaries in a common environment it is necessary to increase the values of certain kernel parameters. The required changes are detailed in the Dialogic Distributed Signaling Interface Components - Software Environment Programmer's Manual, U10SSS Issue 7.
2.2
SS7MD ATM Q.SAAL Link Termination

This release adds the ability to use and configure SS7 links to operate in ATM mode over a T1/E1 interface. It includes updated versions of the s7_mgt configuration utility and of the Device Driver for the SS7MD board. Operation and configuration of terminated ATM links are detailed in the Dialogic DSI SS7MD Network Interface Boards Programmers Manual, Issue 3. In order to use this functionality it is necessary to use ss7.dc6 or ima.dc6 code files V1.08 or later.
2.3
Support for 64 bit Applications

The Development Package now includes both 32 bit and 64 bit GCTLIB shared object shared libraries, allowing 64 bit applications to co-exist with 32 bit DSI software. For full details refer to the Dialogic Distributed Signaling Interface Components - Software Environment Programmer's Manual, Issue 7.
50
2.4
s7_mgt SLS Rotation for M3UA

s7_mgt is capable of activating SLS rotation in accordance with T1.111.5 within M3UA. To achieve this, the ROTATION attribute must be set for the appropriate network context as shown below: CNNCI:SS7MD=ANSI,ROTATION=Y;
3 Other Changes
3.1 MBM End Resources
Previous releases of MBM did not generate a confirmation message for the MBM_END_RSP and MBM_MSG_END_AS messages. This fault has been corrected.
3.2
s7_mgt M3UA Service Indicators

Previous releases of s7_mgt use a fixed configuration for M3UA Service Indicators such that ISUP (SI=5) and SCCP (SI=3) were always configured. This could cause problems if all the module message queues were not processed. s7_mgt now configures an Adjacent Application Server or Signaling Gateway in M3UA (M3U_MSG_CNF_SERVER), using only the Service Indicators and Module IDs for the protocols present in the config.txt configuration file. If the M3UA-user protocols are to be configured later using messages then the MTP_USER_PART command should be used to configure the service indicator and module ID of that protocol.
3.3
s7_mgt Monitor Links (IPY00080425)

Previous release of s7_mgt would not correctly configure monitoring links if the MONITOR_LINK command occurred before the MTP_LINK command in config.txt. This restriction has been removed.
3.4
s7_mgt 32 bit Network Appearances

Previous releases of s7_mgt would reject a Network Appearance value where the most significant bit (bit 31) was set. This has been corrected allowing any 32bit value to be used.
3.5
s7_mgt More than 16 TCAP instances

Previous releases of s7_mgt always configured TCAP to use 4 bits in the transaction_id to identify the TCAP instance. This prevented use of more than 16 TCAP instances in a single system. This release adds a new optional parameter to the TCAP_CONFIG command which identifies the maximum instance value to be used. If <max_instance> is 16 or greater TCAP is configured to use 8 bits for instance information otherwise it is configures to use 4 bits.
51
The updated TCAP_CONFIG command is: TCAP_CONFIG <base_ogdlg_id> <nog_dialogues> <base_icdlg_id> <nic_dialogues> <options> <dlg_hunt>[ [<addr_format>] <partner_id> <tcap_inst> [<max_instance>]]
3.6
s7_mgt DTC Destination Module Id (IPY00080200)

Previously s7_mgt configured DTC to route messages directly to the SCCP module Id rather via the DTS module Id. s7_mgt will now correctly configure DTC to route messages via DTS.
3.7
s7_play Response Messages Not Released (IPY00080025)

The previous release of s7_play did not release response messages requested by the Wait for response playback command. This has been corrected. Dialogic 16-Jul-09
52

This release of the Dialogic SS7 Development Package for Linux adds support for the Dialogic DSI SS7MD Network Interface Board. This board is a low profile PCI Express form factor with 4 T1/E1/J1 interfaces and support for up to 124 SS7 low speed links or four HSL (High Speed Links). It uses the same API as other Dialogic DSI Network Interface Boards. The release also adds support for a new config.txt command STREAM_XCON, which simplifies routing between LIUs on the board products, and enhanced SS7HD error code reporting. This is the first release since V5.11 and is fully backwards compatible with that release.
2 New Functionality
2.1 Support for Dialogic DSI SS7MDL4
This release includes support for the DSI SS7MDL4 Network Interface Board. Full details of the operation of the DSI SS7MDL4 Board are provided in the Dialogic DSI SS7MD Network Interface Boards Programmers Manual.
2.2
STREAM_XCON Command
The STREAM_XCON command permits the cross-connection of timeslots between two Line Interface Units (LIU) on each signaling board and (for certain board types) also allows a fixed pattern to be generated on specified timeslots. Full details on this configuration command can be found in the appropriate boards Programmers Manual.
2.3
SS7HD board failure diagnostics

The SSDH module has been extended to provide additional diagnostic information upon the detection of a SS7HD board failure. The SSD_MSG_STATE_IND message has been extended by the addition of two fields in the parameter area. Full details are provided in the Dialogic DSI SS7HD Network Interface Boards Programmers Manual, Issue 10. Dialogic 21-Apr-09
53

This is a maintenance release including several small changes and enhancements including config.txt configuration of SCCP and TCAP in dual chassis deployments and increased message-length support for SCTP. Full details of all the changes are detailed below. This is the first full release since V5.09 it is fully backwards compatible with the previous release.
2 New Functionality
2.1 config.txt configuration of dual chassis SCCP and TCAP
The ability to distribute the protocol stack over two separate chassis allows users to realise systems that appear to the network as a single point code whilst achieving fault tolerance in the event of a chassis failing. See the Application Note: Enabling Dual Chassis Fault Tolerance with Dialogic Signaling Boards for a description of how such a configuration can be used. This release adds the ability to configure SCCP and TCAP in such configurations by extending the SCCP_CONFIG and TCAP_CONFIG commands. The full syntax of these commands is described in the SS7HD Programmers Manual. The modifications to these commands are detailed below: SCCP_CONFIG <local_spc> <ssf> <options> [<management_options> [<partner_id> <instance>]] <partner_id> <instance> specifies the module_id of the partner SCCP module. [range 0 - 15] which specifies the instance of SCCP running on this system.
Note: In order to use the <partner_id> and <instance> parameters the user must also provide the <management_options> parameter. TCAP_CONFIG <base_ogdlg_id> <nog_dialogues> <base_icdlg_id> <nic_dialogues> <options> <dlg_hunt> [ [<addr_format>] <partner_id> <tcap_inst> ] The new parameters <partner_id> and <tcap_inst> are used as follows: <partner_id> <tcap_inst> specifies the module_id of the partner TCAP module. [range 0 - 15] which specifies the instance of TCAP running on this system.
54
2.2
Increased message-length support for SCTP

In this release the SCTP module has been enhanced to offer support for longer payload messages that exceed the normal MTP2 limit of 272 octets. SCTP is now capable of sending and receiving payload messages with up to 4200 bytes in the parameter area of the message. Use of this feature requires that the software environment is appropriately configured so as to have a pool of Long Messages using the NUM_LMSGS command in sxstem.txt. For full details relating to the capabilities and usage of Long Messages refer to the release notes for V5.00. If for any reason (e.g. exhaustion of the Long Message pool) the SCTP module is unable to allocate a message with sufficient capacity to store the received message then a management event indication MGT_MSG_EVENT_IND (0x0008) with status set to SCTP_RX_DISCARD (0xf0) is sent to the SCTP modules management module. From this release, the s7_mgt module configures the SCTP modules management module to be the value specified in the MGMT_MOD_ID command with a default value of 0xef. Check the release documentation to determine whether the SCTP user module (e.g. M2PA, M3UA or SUA) supports Long Messages. The per-association statistics message (SCTP_MSG_R_STATS) has been extended by the addition of an rx_discard field to count any discarded incoming messages. The new field rx_discard is offset 49, size 4 in the parameter area of the message. The new message length is 53 bytes.
2.3
GCTLOAD Verification
GCTLOAD has been updated to support a new, optional, system.txt command, VERIFY. Inclusion of VERIFY in system.txt will cause GCTLOAD to verify that the host operating system has been correctly configured to create the message queues and messages defined in the system.txt file. Full details of this command are provided in the Dialogic Distributed Signaling Interface Components - Software Environment Programmer's Manual, U10SSS Issue 7.
2.4
GEN_MSG_MOD_IDENT for SSDS and DTC

The GEN_MSG_MOD_IDENT message may be used to request a Revision Identifier for a module. Support for this message has been added to the SSDS and DTC modules. NOTE: The Core Revision Identifier is returned by this message. This is not the same as the Binary version that is reported, for example, by the ssds v command line parameter.
2.5
Configuration of Sigtran Links by s7_mgt

The s7_mgt module passes dimensioning parameters to the M2PA and M3UA modules in the appropriate configuration message. In previous releases fixed values were used for these dimensioning parameters.
55
From this release the values are set according to the number of links that have been configured. The maximum number of links that s7_mgt is capable of configuring has also been increased, as shown in the table below:
Dimensioning parameter Sigtran Links M3UA Local servers M3UA Remote Application Server Lists M3UA Bindings M3UA Routes from M2PA Links
Previous Value
32 32 32 32 32 8
Revised Maximum
64 64 64 64 64 64
2.6
SSD Congestion Handling

Previous releases required the SSD module to be configured as the GCT congestion module, using either the GCTLOAD command line option -Ci, or the system.txt command, CONG_MSG. From this release SSD detects congestion without requiring these notifications so it is no longer necessary to set SSD as the congestion module.
2.7
Configuration of SCTP management and maintenance module ids

The support for the Configuration of management and maintenance module ids as described in Release notes for V5.09, has been extended to the SCTP and SCTPD modules.
2.8
ISUP - maximum SIF length

A parameter has been added to the ISUP_CONFIG command which allows the user to specify the maximum SIF length to be used when sending messages to MTP3 or M3UA. The revised syntax for the command is: ISUP_CONFIG <res1> <res2> <user_id> <options> <num_grps> <num_ccts> [<partner_id> [<max_sif>]] If this parameter is not set the default value of 272 will be used. When setting this parameter the <partner_id> must also be present or set to zero.
2.9
<options> parameter for SNRLI command

A new optional parameter <options> has been added to the SNRLI command within the s7_mgt module allowing for run-time options to be added in the future without the need to further modify the command syntax. The <options> parameter is a 32 bit field and defaults to zero if not specified. The contents of this parameter are passed to the M3UA module at run-time. The full syntax of the SNRLI command is as follows: SNRLI:SNRL=,SNRT=,SG=,[OPTIONS=];
56
3 Other Changes
3.1 SSDH Hot Swap Support
In earlier releases of the Development Package, Hot swap settings were not supported. This support has now been added and a single board maybe hot swapped at a time.
3.2
SPCI Support for 64bit Kernels

The SPCI Linux Device Driver has been updated to support 64bit kernels. The SPCI Device Drivers build and installation instructions are described in the Dialogic DSI SPCI Network Interface Boards Programmer's Manual.
3.3
ANSI SUA support

s7_mgt now allows SUA to optionally be configured to support ANSI mode of operation.
3.4
Support for mixed M3UA Link Types

In previous releases support for Remote Application Server (RAS) and Signaling Gateway (SG) links was only possible if unique Identifiers were used for the RAS and SG parameters. This has been resolved.
3.5
Parameter format restrictions in MMI commands

In earlier releases, the s7_mgt module could give unexpected results if spaces were used in numeric parameters (e.g. 0x7fff ffff). Configuration commands with spaces in the middle of strings are now rejected.
3.6
MBM Reliability Improved

In earlier releases the MBM module could occasionally, in certain configurations, fail to initialise correctly. This problem has been resolved.
3.7
PCAP Support for MTP3 running on-board

The PCAP logging functionality provided by the s7_log module has been extended to support configurations where the MTP3 module is running on the board.
3.8
Monitoring 56/48kb/s links on SS7HD Boards

A correction has been made within the s7_mgt module to ensure that monitoring of 56kb/s and 48kb/s links is correctly set up on SS7HD boards.
3.9
Restriction on IPSP Links removed

In the previous release of the s7_mgt module only 4 M3UA links could be configured. This restriction has now been removed and it is possible to configure up to 64 links.
57
3.10
AMI with Zero Code Suppression

In previous releases configuration of a T1 interface using AMI with Zero Code Suppression (ZCS) line coding did not maintain transparency of the timeslot for SS7 signaling links. ZCS is now disabled by s7_mgt for any timeslots containing SS7 signaling links.
3.11
File permissions for log files

In earlier releases, log files created by the s7_log module could only be read by the user that created the file. In this release any user can read them (subject to appropriate setting of the system umask).
3.12
SS7HD Board Information

Previous releases could report out of date board information in multi-board configurations using hot swap functionality. This problem has now been resolved.
3.13
SCTP corrections within SCTPN

A number of protocol corrections have been implemented within the SCTPN module as follows: Validation of remote address information when a connection is received from a client application has been corrected to prevent unconfigured remote hosts from connecting and to prevent two associations using the same host port. Receipt of an ABORT primitive is now handled correctly.
A problem when running on a multi-core / multi-processor system, where SCTP would begin, after about five minutes, to send an invalid sequence of messages if no peer SCTP socket were listening has been corrected. A problem related to receipt of a "configure association request" on an active association has been corrected.
3.14
Unwanted MGT_MSG_NTP_SYNC messages

Previous releases of the s7_mgt module would send an MGT_MSG_NTP_CONFIG message to each SS7HD Signaling Processor irrespective of whether MONITOR_LINKS are configured to use time stamping. From this release the message is only sent to a Signaling Processor if monitor links are configured to use time stamping.
3.15
MBM not waiting for ASP_UP response

Previous releases of the MBM module would send an AS_ACT_REQ message if no response were received to an ASP_UP request before it's guard timer expires. From this release it generates another ASP_UP request.
58
3.16
SCTP INIT_REQ streams requested

In earlier releases of the SCTP module, if an invalid INIT-ACK primitive were received which specifies more streams than were requested in the original INIT-REQ primitive then the invalid value would be passed up to the application. From this release the value in the original INIT-REQ primitive will be passed. Dialogic 05-Dec-08 Revised 30-Oct-09
59

This is the first full release of the Dialogic SS7 Development Package for Linux since V5.06. Except for some minor changes to configuration messages outlined below, the release is fully backwards compatible with the previous release. This release adds support for the Dialogic SS7HDE High Density PCI Express Signaling Board. It also adds support for user creation of RPM packages which can be used to install the contents of the Development Package. The s7_mgt module has been extended to support the configuration of the SUA module. Support for native kernel implementations of the SCTP protocol has been added. A new command has been introduced to allow users to specify the period of certain Sigtran timers. The s7_log module has been extended to output a PCAP-formatted log file. This will allow a third party application to analyse packets. The license terms for the board drivers which are included in this Development Package have been updated to follow common best practice for Linux Drivers. Other improvements are included in this release, as described below.
2 New Functionality
2.1 Support for SS7HDE Signaling Board
This release includes support for the SS7HDE Signaling Board. Full details of the operation of the SS7HDE Board are provided in the Dialogic SS7HD Programmers Manual, Issue 8.
2.2
s7_mgt support for SUA

Support for the Dialogic SUA module has been added to the s7_mgt utility. See the Dialogic SS7 Protocols SUA Programmer's Manual for full details. The sua_inc.h header file has been added to the package.
2.3
Native SCTP
A new module, SCTPN, has been introduced that allows users to make use of kernel implementations of the SCTP protocol that are available under some version of Linux. Refer to Dialogic SS7 Protocols Programmer's Manual for SIGTRAN Host Software, Issue 8 for details.
2.4
PCAP output for s7_log

To invoke this new functionality the new p command line parameter should be used to specify the filename of the log file. Full details are provided in the Dialogic Distributed Signaling Interface Components - Software Environment Programmer's Manual Issue 7.
60
2.5
Support for RPM

This release includes support to generate RPM (RedHat Package Management) packages from the SS7 Development Package for Linux distribution. The creation of RPM packages is supported for Linux Kernels from V2.6. Refer to appropriate board Programmers Manual for details.
2.6
Sigtran timer configuration

A new command, CNTOS, has been added to the set supported by the s7_mgt utility. This allows the user to set the values of timers to be used in the SCTP and M2PA protocols. Refer to Dialogic SS7 Protocols Programmer's Manual for SIGTRAN Host Software for details.
2.7
s7_play Commands
The command set supported by the s7_play module has been extended. Commands may now be issued that require the module to pause until a specified message or response is received. Full details are provided in the Dialogic Distributed Signaling Interface Components - Software Environment Programmer's Manual Issue 7.
2.8
Configuration of management and maintenance module ids

The values specified in the configuration commands that the s7_mgt utility sends to the Host Protocol modules are not always convenient. These have been revised in this release. Full details are provided in the Dialogic SS7HD Programmers Manual, Issue 10.
2.9
GEN_MSG_MOD_IDENT support in SCTP

The GEN_MSG_MOD_IDENT message may be used to request a Revision Identifier for a module. Support for this message has been added to the SCTP module. NOTE: The Core Revision Identifier is returned by this function. This is not the same as the Binary version that is reported, for example, by the sctp v command line parameter.
2.10
s7_mgt - Number of SCCP SSRs

The number of SCCP sub-system resource commands that the s7_mgt utility supports has been increased from 16 to 512.
2.11
s7_mgt -Number of routes

The number of MTP_ROUTE commands supported by the s7_mgt utility has been increased from 128 to 4096.
61
2.12
s7_mgt - Non-consecutive links

In earlier releases of the Development Package, if the config.txt file contained MTP_LINK commands with non-consecutive link reference numbers, the configuration commands generated by the s7_mgt utility would be rejected by the MTP3 module. In this release the commands are not rejected
2.13
Drivers report source code version

The drivers included in this release of the Development Package have been extended to additionally report the Source code version in the message sent to the kernel ring buffer eg. Dialogic SS7HD Device Driver V100.00 (Source V1.20)
2.14
Notify message for void config.txt message

If configured, the s7_mgt utility now generates a Notify message even if the config.txt file does not contain any configuration commands.
3 Other Changes
3.1 Updated License Terms
The license terms for the board drivers which are included in this Development Package have been updated to more closely follow the common practice for Linux Drivers. Details are given in the license agreement which accompanies this Development Package and the full license agreements are included in each impacted subdirectory. The set of pre-compiled drivers is no longer delivered with the Development Package.
3.2
Correction to Device Driver Installation

Previous releases of the Development Package contained a problem in the device driver installation scripts which could prevent more than two signaling boards from being correctly configured. This problem affected the SPCI, SS7HD and SS7AM1 signaling boards and has now been resolved.
3.3
Install problems for SS7AM driver

The SS7AM driver was failing to compile correctly on some versions of the gcc compiler. This would result in a Kernel panic when the user attempted to load the driver. This problem has been resolved in this release of the Development Package.
3.4
Comments in MMI commands

In earlier releases MMI style commands containing comments were rejected by the s7_mgt utility. In this release these commands are processed normally.
62
3.5
SSDH crash with Invalid switch setting

In earlier releases of the Development Package, certain invalid geographic addressing switch settings were causing a SSDH crash. This problem has now been resolved and the invalid setting are rejected normally.
3.6
Number of streams configured for M2PA

In previous releases of the s7_mgt utility, the command used to configure SCTP associations for M2PA links specified that 32 streams should be used. In this release only two streams are configured.
3.7
Use of SCPF_SMB flag in SCCP_MSG_CONFIG message

In previous releases of the s7_mgt utility, the SCPF_SMB flag was being set although SMB operation is not currently supported by the s7_mgt utility. In this release this flag is no longer set.
3.8
SCTP Init chunk with variable parameters

In previous releases of the SCTP module, receipt of an INIT chunk with variable parameters (which are not listed in Section 3.3.2 of RFC 2960) resulted in failure of the SCTP module. In this release they are correctly handled. Dialogic 11-Mar-08
63

Dialogic DSI Development Package For Linux Release Notes: Document Reference: RN003DPK Publication Date: March 2013

Uploaded by

Copyright:

Available Formats

Dialogic DSI Development Package For Linux Release Notes: Document Reference: RN003DPK Publication Date: March 2013

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dialogic DSI Development Package For Linux Release Notes: Document Reference: RN003DPK Publication Date: March 2013

Uploaded by

Copyright:

Available Formats

Dialogic DSI Development Package for Linux - Release Notes