Dialogic Service Center

Service Contracts

Technical Helpweb

Downloads

Contact Support

Developer Forums

Training

Service Center Logon

Downloads

Product pages

For Developers

Resources

Contact Dialogic Support

Other downloads

Useful links

 

Technical Helpweb

Dialogic® Distributed Signaling Interface (DSI) - Signaling and SS7 Products

Guide to running the Dialogic® Signaling Short Message Service (SMS) Sample Software Application


The note provides a guide to configuring and running the Dialogic® Signaling Short Message Service (SMS) Sample Software application.

The Signaling Short Message Service (SMS) sample software, MTU / MTR, can require a bit of effort to get running in some environments. The goal of this note is to provide a quick reference covering configuration and command line parameters needed to successfully run the SMS demo. In addition, common errors encountered due to configuration will be included. The MTU and MTR applications are contained in the development kit and are installed under the upd src directory . Note: The exact directory structure varies by operating system but the same applications run across all three platforms hence the format of the directory reference.

All configuration files used for this sample are located in the root directory selected when installing the Dialogic Signaling Software. The System.txt config file is used for a number of purposes, two of which are to identify the signaling protocols that run on the host and to spawn the host based processes. Unless the host system used to run the SMS sample is licensed, some of the protocol processes spawned via the System.txt file will need to be run in trial mode. Trial mode means that the host protocol can run for 10 hours and is specified via a ‘-t’ after the protocol name. Not specifying trial mode will cause the needed protocols to not load and the SMS sample to fail. For example, “FORK_PROCESS m2pa_nt.exe –t”. The following host processes need to be run in trial mode:

m2pa_nt.exe
mtp_nt.exe
sccp_nt.exe
tcp_nt.exe
map_nt.exe

The above list of host protocols is specific to the Windows® operating system implementation. For Linux deployments the _nt is replaced with _lnx and for Solaris deployments, _sol is used.

Next, configuration.txt contains a number of parameters and values that must be set to the test environment. First, the line “CNSYS:IPADDR=192.168.0.10,PER=0;” should be modified to contain the IP address of the computer currently being configured regardless of whether that computer will be the mtu or the mtr. The IP address on the “SNSLI:SNLINK=1,IPADDR=192.168.0.11,SNEND=S,SNTYPE=M2PA,M2PA=1,PPORT=3565;” should be contain the address of the other computer used in for the demo. Additionally, the SNEND should be set to ‘S’ on the computer providing the MTR function and ‘C’ on the computer providing the MTU function. Incorrectly setting this value will yield timeout errors when the SMS sample is run.

The “MTP_LINKSET 0 1 1 0x0000 2 0x08” entry must also be configured correctly to avoid timeout errors. Adjacent spc, or the second parameter must be set to the point code of the other computer used in this demo. The 5th parameter local spc must identify the local point code of the machine currently being configured. For simplicity, use a local point code of 2 for the mtr computer and 1 for the mtu computer.

The “MTP_ROUTE 1 0 0x0008” entry is used to direct SS7 packets to a destination point code. Destination point code is the first parameter on the line and should bet set to the point code of the remote computer. Next, “SCCP_CONFIG 2 0x08 0x0102 0x00000001” should have parameter 1 set to the local point code defined in the MTP_LINKSET command line. The last mask value, 0x00000001, is used to bring the SCCP protocol into a running state.

The “SCCP_SSR 1 RSP 1 0 0x0000” and “SCCP_SSR 3 RSS 1 0x08 0” entries must have parameter 3 set to the remote point code for the other computer used in the demo. Incorrectly setting parameter 3 to the local point code will result in “unexpected message” error messages appearing when the demo is run.

After making the configuration changes above, the demo application is ready to be run. The computer running the mtr portion of the demo will receive the SMS message and is run from a command console window with the following command “mtr –m0x2d”. The –m0x2d parameter is used to identify the module id. On the mtu computer, the following command is used to send an SMS message, “mtu –m0x2d –g43010008 –a43020008 –i987654321 –s”Hello world”. Like the mtr component, the –m0x2d parameter identifies the module id. The parameters starting with –g and –a are the Q713 specified endpoint addresses. Each of these values can be simplified as 43 plus the point code plus 0008 where the –g value contains the local point code and –a contains the remote point code.





Feedback

Please rate the usefulness of this page:  
0 - not useful at all
1 - potentially useful
2 - quite useful
3 - very useful
4 - exactly the information I needed     

Please enter a comment about this page: