Friday 26 April 2013

SIP (Session Initiation Protocol)

The Session Initiation Protocol (SIP) allows phone calls and similar communication sessions to be made over the Internet, private data networks, or cellular networks. It defines the messages that are sent between parties (signaling) which govern establishment, termination, and other essential elements of a call (or, more generally, a session, hence the name).

SIP is an IETF-defined signaling protocol and is widely used for controlling communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. Sessions may consist of one or several media streams, such as voice or video data.

Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer and online games.

SIP is an application layer protocol designed to be independent of the underlying transport layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP). It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).

Monday 25 March 2013

networking commands in linux/unix

Networking Commands Example in Unix and Linux

These are most useful commands in my list while working on Linux server , this enables you to quickly troubleshoot connection issues e.g. whether other system is connected or not , whether other host is responding or not and while working for FIX connectivity for advanced trading system this tools saves quite a lot of time .

• finding host/domain name and IP address - hostname
• test network connection – ping
• getting network configuration – ifconfig
• Network connections, routing tables, interface statistics – netstat
• query DNS lookup name – nslookup
• communicate with other hostname – telnet
• outing steps that packets take to get to network host – traceroute
• view user information – finger
• checking status of destination host - telnet

Example of Networking commands in Unix

let's see some example of various networking command in Unix and Linux. Some of them are quite basic e.g. ping and telnet and some are more powerful e.g. nslookup and netstat. When you used these commands in combination of find and grep you can get anything you are looking for e.g. hostname, connection end points, connection status etc.

hostname

hostname with no options displays the machines host name
hostname –d displays the domain name the machine belongs to
hostname –f displays the fully qualified host and domain name
hostname –i displays the IP address for the current machine

ping
It sends packets of information to the user-defined source. If the packets are received, the destination device sends packets back. Ping can be used for two purposes

1. To ensure that a network connection can be established.
2. Timing information as to the speed of the connection.

If you do ping www.yahoo.com it will display its IP address. Use ctrl+C to stop the test.

ifconfig
View network configuration, it displays the current network adapter configuration. It is handy to determine if you are getting transmit (TX) or receive (RX) errors.

netstat
Most useful and very versatile for finding connection to and from the host. You can find out all the multicast groups (network) subscribed by this host by issuing "netstat -g"

netstat -nap | grep port will display process id of application which is using that port
netstat -a or netstat –all will display all connections including TCP and UDP
netstat --tcp or netstat –t will display only TCP connection
netstat --udp or netstat –u will display only UDP connection
netstat -g will display all multicast network subscribed by this host.

nslookup
If you know the IP address it will display hostname. To find all the IP addresses for a given domain name, the command nslookup is used. You must have a connection to the internet for this utility to be useful.
E.g. nslookup blogger.com

You can also use nslookup to convert hostname to IP Address and from IP Address from hostname.

traceroute
A handy utility to view the number of hops and response time to get to a remote system or web site is traceroute. Again you need an internet connection to make use of this tool.

finger
View user information, displays a user’s login name, real name, terminal name and write status. this is pretty old unix command and rarely used now days.

telnet
Connects destination host via telnet protocol, if telnet connection establish on any port means connectivity between two hosts is working fine.
telnet hostname port will telnet hostname with the port specified. Normally it is used to see whether host is alive and network connection is fine or not.

whois

This command allows you to check the Internic database for proper hostnames. This is very handy when you are trying to trace back an IP address to a specific hostname, or the reverse. I often use it when troubleshooting connectivity between hosts and checking whether the problem is a host configuration error or an actual physical connectivity error. The most commonly used version of the command is:

whois -f 10.1.1.1
(replace the 10.1.1.1 with a specific server IP)

The -f option forces the command to skip any cache that may have stored the host state, and instead goes to the actual server to perform a lookup and verify its hostname.
Another useful variation of the command, especially for trying to identify port problems is:

whois --port=8102 10.1.1.1
This command forces a test on the specific host's port 8102. You can benefit from force checking specific ports in many ways, and I highly recommend testing ports with this technique.

findsmb

findsmb is used to list info about machines that respond to SMB name queries (for example windows based machines sharing their hard disk's).

Command syntax:

 findsmb

This would find all machines possible, you may need to specify a particular subnet to query those machines only...

I. How Routing is Done?

Route command is used to show/manipulate the IP routing table. It is primarily used to setup static routes to specific host or networks via an interface.

In this article we will see how to manipulate the routing tables in Linux using route command.
We’ll first explain how routing is done with some basic route command examples, and then we’ll explain using a sample network architecture about how to setup routes in your network.

I. How Routing is Done?

1. Display Existing Routes

route command by default will show the details of the kernel routing table entries. In this example, the ip-address of the system where the route command is being executed is 192.168.1.157

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

The above command shows that if the destination is within the network range 192.168.1.0 – 192.168.1.255, then the gateway is *, which is 0.0.0.0.
When packets are sent within this IP range, then the MAC address of the destination is found through ARP Protocol and the packet will be sent to the MAC address.

If you don’t know what ARP is, you should first understand how ARP protocol works.
In order to send packets to destination which is not within this ip range, the packets will be forwarded to a default gateway, which decides further routing for that packet. We will see this shortly.
By default route command displays the host name in its output. We can request it to display the numerical IP address using -n option as shown below.

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.10    0.0.0.0         UG    0      0        0 eth0

2. Adding a Default Gateway

We can specify that the packets that are not within the network has to be forwarded to a Gateway address.
The following route add command will set the default gateway as 192.168.1.10.

$ route add default gw 192.168.1.10

Now the route command will display the following entries.

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         gateway.co.in   0.0.0.0         UG    0      0        0 eth0

Now we have just added a default gateway to our machine. To verify whether it is working properly, ping some external host (for example, google.com) to send ICMP packet.

$ ping www.google.com

The following is the sequences of evets that happens when the above ping command is executed.

First it will query the DNS server to obtain the ip-address of google.com ( for example: 74.125.236.34 )
The destination address ( 74.125.236.34 ) is not within the network range.
So, in Layer-3 (IP header) the DESTINATION IP will be set as “74.125.236.34″.
In Layer-2, the DESTINATION MAC address will be the filled in as the MAC address of the default gateway ( 192.168.1.10′s MAC ). The MAC will be found by using ARP as described earlier.
When the packet is sent out, the network switch ( which works on Layer-2 ), send the packet to the default gateway since the destination MAC is that of the gateway.
Once the gateway receives the packet, based on its routing table, it will forward the packets further.

The above 2 examples would have given a good idea about how routing is done within a network. Now we will see other command line options available with route command.

3. List Kernel’s Routing Cache Information

Kernel maintains the routing cache information to route the packets faster. We can list the kernel’s routing cache information by using the -C flag.

$ route -Cn
Kernel IP routing cache
Source          Destination     Gateway         Flags Metric Ref    Use Iface
192.168.1.157   192.168.1.51    192.168.1.51          0      0        1 eth0
192.168.1.157   74.125.236.69   192.168.1.10          0      0        0 eth0
.
.
.

4. Reject Routing to a Particular Host or Network

Sometimes we may want to reject routing the packets to a particular host/network. To do that, add the following entry.

$ route add -host 192.168.1.51 reject

As you see below, we cannot access that particular host (i.e .51 host that we just rejected).

$ ping 192.168.1.51
connect: Network is unreachable

However we can still access other hosts in the network (for example, .52 host is still accessible).

$ ping 192.168.1.53
PING 192.168.1.53 (192.168.1.53) 56(84) bytes of data.
64 bytes from 192.168.1.53: icmp_seq=1 ttl=64 time=7.77 ms

If you want to reject an entire network ( 192.168.1.1 – 192.168.1.255 ), then add the following entry.

$ route add -net 192.168.1.0 netmask 255.255.255.0 reject

Now, you cannot access any of the host in that network (for example: .51, .52, .53, etc.)

$ ping 192.168.1.51
connect: Network is unreachable

$ ping 192.168.1.52
connect: Network is unreachable

$ ping 192.168.1.53
connect: Network is unreachable

II. A Sample Network Architecture (to understand routing)

Let us use the following sample network architecture for the rest of the examples.
In the diagram below, we have 2 individual networks ( 192.168.1.0 and 192.168.3.0, with subnet mask of 255.255.255.0 ).
We also have a “GATEWAY” machine with 3 network cards. 1st card is connected to 192.168.1.0, 2nd card is connected to 192.168.3.0, and the 3rd card is connected to the external world.

5. Make 192.168.3.* Accessible from 192.168.1.*

Now we need to add a routing entry such that we are able to ping 192.168.3. series ip-addresses from 192.168.1. series. The common point we have is the GATEWAY machine.
So, on each machine in 192.168.1.* network a default gateway will be added as shown below.

$ route add default gw 192.168.1.10

Now when 192.168.1.1 pings 192.168.3.1, it will go to the GATEWAY via 192.168.1.10.
In GATEWAY, add the following routing entry.

$ route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.3.10

Now all the packets addressed to 192.168.3.* network will be forwarded via the 192.168.3.10 interface, which then delivers the packets to the addressed machine.

6. Make 192.168.1.* Accessible from 192.168.3.*

It is very similar to what we did earlier.
So, on each machine in 192.168.3.* network a default gateway will be added as shown below.

$ route add default gw 192.168.3.10

In GATEWAY, add the following routing entry.

$ route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.10

Now 192.168.3.* machines can ping 192.168.1.* machines.

7. Allow Internet Access ( External World )

In the previous two example, we have interconnected the 2 different networks.
Now we need to access the internet from these 2 different networks. For that, we can add a default routing ( when no routing rule matches ) to the 125.250.60.59 which is connected to the external world as follows.

$ route add default gw 125.250.60.59

This is how it works:

Now when you try to access the internet (for example: ping google.com) from any of these machines (for example, from 192.168.3.2), the following is the sequence of events that happens.
Since the destination (google.com) is not within 3.* series, it will be forwarded to GATEWAY via 3.10 interface
In GATEWAY, it checks whether the destination is within 1.* range. In this example, it is not.
It then checks whether the destination is within 2.* range. IN this example, it is not
Finally, it takes the default route to forward the packets (i.e using the 125.250.60.59 interface, which is connected to the external world).

Start and Stop the Network Interface Card

The ifconfig command can be used to start and stop network interface cards:

# ifconfig eth0 up

# ifconfig eth0 down

The ifup & ifdown command can also be used to start and stop network interface cards:

# ifup eth0

# ifdown eth0

The systemctl commands can also be used to enable, start, stop, restart and check the status of the network interface services -

# systemctl enable network.service

# systemctl start network.service

# systemctl stop network.service

# systemctl restart network.service

# systemctl status network.service

Displaying and Changing your System's Hostname

The command hostname displays the current hostname of the computer, which is 'Gateway':

# hostnameGateway

You can change the hostname by giving the new name at the end of the command -

# hostname Firewall-cx

This will change to the new hostname once you have logged out and logged in again. In fact, for any change in the interfaces, the change is implemented only after the user logs in the next time after a log-out.

Thursday 21 February 2013

SIGTRAN

SIGTRAN is the name, derived from signaling transport, of the former Internet Engineering Task Force (IETF) working group that produced specifications for a family of protocols that provide reliable datagram service and user layer adaptations for Signaling System 7(SS7) and ISDN communications protocols. The SIGTRAN protocols are an extension of the SS7 protocol family. It supports the same application and call management paradigms as SS7 but uses an Internet Protocol (IP) transport called Stream Control Transmission Protocol (SCTP). Indeed, the most significant protocol defined by the SIGTRAN group is SCTP, which is used to carry PSTNsignaling over IP.

The SIGTRAN group was significantly influenced by telecommunications engineers intent on using the new protocols for adapting VoIPnetworks to the PSTN with special regard to signaling applications Recently, SCTP is finding applications beyond its original purpose wherever reliable datagram service is desired.

signaling gateway (SG), which converts Common Channel Signaling (CCS) messages from SS7 to SIGTRAN. Implemented in a variety of network elements including softswitches, the SG function can provide significant value to existing common channel signaling networks, leveraging investments associated with SS7 and delivering the cost/performance values associated with IP transport.

SIGTRAN protocols

The SIGTRAN family of protocols includes:

Stream Control Transmission Protocol (SCTP),

ISDN User Adaptation (IUA)

Message Transfer Part 2 (MTP) User Peer-to-Peer Adaptation Layer (M2PA)

Message Transfer Part 2 User Adaptation Layer (M2UA)

Message Transfer Part 3 User Adaptation Layer (M3UA)

Signalling Connection Control Part (SCCP) User Adaptation (SUA)

V5 User Adaptation (V5UA)

DPNSS/DASS2 User Adaption (DUA)

The Stream Control Transmission Protocol provides the transport protocol for SIGTRAN user adaptation layer messages across an IP network

IUA provides an SCTP adaptation layer

V5UA provides an SCTP adaptation layer for the seamless backhaul of V5.2 user messages and service interface across an IP network. It is a variation of IUA

M2PA provides an SCTP adaptation layer for providing an SS7 MTP signaling link over an IP network. It

M2UA provides an SCTP adaptation layer for the seamless backhaul of MTP Level 2 user messages and service interface across an IP network.

M3UA provides an SCTP adaptation layer for the seamless backhaul or peering of MTP Level 3 user messages and service interface across an IP network

SUA provides an SCTP adaptation layer for the seamless backhaul or peering of Signalling Connection Control Part user messages and service interface across an IP network

SIGTRAN configuration overview

NaturalAccess™ Signaling Software uses the signaling transport (SIGTRAN) protocol to transport upper layer SS7 signaling packets over the IP network.
The Dialogic® NaturalAccess™ SIGTRAN stack consists of the following protocols:

Protocol	Description
M3UA (MTP3 User Adaptation Layer)	M3UA is an adaptation layer protocol that replaces the traditional SS7 MTP 3 layer in an IP network. It supports the transport of SS7 MTP 3 user signaling messages (such as ISUP and SCCP) over IP, using the services of SCTP. M3UA is used for communication between an application server process (ASP) and a signaling gateway process (SGP), or between two IP server processes (IPSPs). An ASP can serve as a media gateway controller (MGC) or IP-resident database. The M3UA implementation includes a data transfer or service API and a management API (MAPI). Host applications can use the service functions to transfer data, control flow, and obtain API statistics. They can use the management functions to configure and control M3UA entities, and to obtain status and statistical information from the M3UA layer. Refer to Creating the M3UA configuration for more information.
SCTP (Stream Control Transmission Protocol)	SCTP is a reliable transport protocol that replaces the traditional SS7 MTP 2 layer in an IP network. It transports M3UA and higher layer SS7 signaling messages over IP networks. The SCTP implementation includes a management API (MAPI) that host applications can use to configure and control SCTP entities and to obtain SCTP status and statistical information from the SCTP layer. Refer to Creating the SCTP configuration for more information.

SIGTRAN architecture

The following illustration shows the SIGTRAN high-level architecture:

Two endpoints in a SIGTRAN network can be logically connected as:

Nodes in a client-server relationship, where one node is an application server process (ASP) and the other is a signaling gateway process (SGP).
Peer IP-only nodes, where each node is an IP server process (IPSP).

M3UA represents the connection between two endpoints as an SCTP association. The following illustration shows an association example:

Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for more information.
The following illustration shows the relationship among NSAPs, peer servers, routes, and peer signaling processes:

The following illustration shows three NSAPs defined for M3UA:

If multiple protocol variants are configured on the same M3UA instance (same board), two NSAPs are required: one for each protocol variant. A single application can associate itself with both NSAPs for that service, or separate applications can be used for each protocol variant.

Creating the M3UA configuration

M3UA has three primary functions:

Provides an interface between the higher SS7 layers (ISUP, SCCP, and TUP) and the lower SCTP layer.
Routes messages to their IP destinations. M3UA uses a flexible configuration capable of supporting a wide variety of network routing and addressing requirements.
Maintains the availability status of all destinations through all routes in the case of failure or congestion.

Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for more information.
SS7 provides the following sample files for M3UA configurations that you can modify for your specifications:

Files	Description
M3UAcp1.cfg	M3UA file for board 1.
M3UAcp2.cfg	M3UA file for board 2.

The M3UA configuration utility (m3uacfg) runs as part of the initial board download with ss7load. The utility reads the text configuration file and downloads the specified configuration to the M3UA and SCTP tasks on the TX board. You can also run the M3UA configuration utility after the initial configuration to dynamically update selected configuration parameters.
This topic presents:

Sample M3UA configuration files

The following example is the M3UA configuration file for board 1 in an IPSP-IPSP configuration:
#
# M3UA Sample Configuration File
#
# All timer values are in milliseconds
#
#------------------------------------------------
# General M3UA Parameters
#------------------------------------------------
NODE_TYPE       ASP     # Only ASP currently supported
MAX_NSAP        2       # Max number of NSAP (M3UA users/variants to support simultaneously)
MAX_NETWORK     2       # Max number of network contexts (one per network ID/variant)
MAX_ROUTE       16      # Max number of route entries including local routes
MAX_DPC         32      # Max # of DPCs supported includes configured & dynamically learned
MAX_PS          8       # Max number of peer servers including local
MAX_LPS         4       # Max number of local peer server
MAX_PSP         16      # Max number of peer server processes
MAX_MSG         128     # Max number of M3UA messages in transit
MAX_RNDRBN_LS   4       # Max number of peer servers using round robin load sharing
MAX_SLS_LS      4       # Max number of peer servers using SLS based load sharing
MAX_SLS         128     # Max number of SLS values (total number used by all PS)
QUEUE_SIZE      256     # Outgoing congestion queue size per association
CONG_LEVEL1     64      # Congestion level 1
CONG_LEVEL2     128     # Congestion level 2
CONG_LEVEL3     196     # Congestion level 3

TMR_RESTART     10000   # Restart hold-off time (not used for IPSP)
TMR_AS_PEND     5000    # Time a PS can remain in AS_PENDING state
TMR_ASP_UP1     2000    # Initial time between ASPUP retries
TMR_ASP_UP2     2000    # Steady-state time between ASPUP retries
NMB_ASP_UP1     3       # Number of initial attempts at sending ASPUP
TMR_ASPDN       2000    # Time between ASPDN retries
TMR_ASPM        2000    # Time to wait after send ASPM message (ASPAC/ASPIA) before fail
TMR_DAUD        2000    # Time between DAUD messages
TMR_DRKM        2000    # Time between DRKM messages
NMB_DRKM        3       # Number of DRKM attempts before failing
TMR_SEQ_CNTRL   1000    # Delay when diverting traffic to maintain sequencing
END

#------------------------------------------------
# Network Configuration Parameters
#------------------------------------------------
NETWORK_ID        1     # Network ID
NETWORK_APPEAR         1234 # Optional network appearance code coordinated with SGP
SSF                 NAT   # Subservice field (NAT / INTL)
DPC_LENGTH          24    # Point code Length (24 / 16 / 14)
SLS_LENGTH                      5     # SLS Length (4 / 5 / 8)
SERVICE_USER_VAR ANSI # Service user variant, ANSI, ITU, CHINA, BICI, TTC, NTT
SERVICE_USER_VAR2      ANSI # Service user variant for TCAP ANSI/ETSI/ITU
END

# -----------------------------------------------
# NSAP Configuration
#------------------------------------------------
NSAP_ID            0       # Network sap ID
NWK_ID         1       # Network ID corresponding to above section
SERVICE_TYPE      ISUP    # Service type ISUP/TUP/SCCP/BICC
END

NSAP_ID            1       # Network sap ID
NWK_ID                  1       # Network ID corresponding to above section
SERVICE_TYPE      SCCP    # Service type ISUP/TUP/SCCP/BICC
END

#------------------------------------------------
# M3UA SCT SAP Configuration
#------------------------------------------------
SCT_SAP_ID         0       # M3UA reference for SCTP SAP. Currently, This value must be 0
SRC_PORT       2905    # Source Port
SP_ID               0       # SCTP reference for SCTP SAP. Currently, This value must be 0
END

#------------------------------------------------
# Peer Signaling Process (PSP) Configuration
#-------------- ----------------------------------
PSP_ID           1           # Unique PSP ID from 1 to Max Number of PSP -1
PSP_TYPE         IPSP        # Type of Peer (SGP/IPSP)
IPSP_MODE          DE          # Used if PSP_TYPE=IPSP (SE=single ended/DE=double ended)
DRKM_ALLOWED    FALSE       # Whether this PSP can accept DRKM messages
USE_NWK_APP         FALSE       # Use network appearance in M3UA msgs? TRUE if exchanging
                               # messages from different networks over same association.
ASP_ID_MAND       NONE        # Whether AspId is mandatory to by transmitted/received in
                            # ASPUP/ASPUP-ACK msgs (NONE / RX / TX / BOTH)
NWK_ID             1     # Default network context for incoming messages

# Association parameters
PRIME_DEST_ADDR    192.168.1.2 # Primary Peer Destination Address.
DEST_PORT       2905        # Remote SCTP Port
CLIENT_SIDE    TRUE        # Whether we initiate associations if IPSP
NMB_OUT_STREAMS    2           # Number of streams supported by this association
END

#-----------------------------------------------
# Peer Server (PS) Configuration
#-----------------------------------------------

# Local PS for ISUP
PS_ID               1           # Local PS ID, does not have to be zero
NWK_ID              1           # Selects a network context for this PS
MODE                ACTSTANDBY # Active/standby
LOCAL          TRUE        # Is this a local AS? Yes
PSP                1
RTE_CTX         0xA         # Routing context
END

# Local PS for SCCP
PS_ID            2           # Local PS ID, does not have to be zero
NWK_ID            1           # Selects a network context for this PS
MODE              ACTSTANDBY # Active/standby
LOCAL               TRUE        # Is this a local AS? Yes
PSP                    1
RTE_CTX           0xB         # Routing context
END

# Remote PS for ISUP
PS_ID               3           # Remote PS ID
LOCAL                           FALSE       # Is this a local AS? No
NWK_ID                        1           # Selects a network context for this PS
MODE                            ACTSTANDBY # Peer server mode
LOAD_SHARE_TYPE   ROUND_ROBIN # Load Share type (ROUND_ROBIN / SLS )
PSP              1
RTE_CTX           0xC         # Routing context
END

# Remote PS for SCCP
PS_ID               4           # Remote PS ID
LOCAL               FALSE       # Is this a local AS? No
NWK_ID          1           # Selects a network context for this PS
MODE                ACTSTANDBY # Peer server mode
LOAD_SHARE_TYPE              ROUND_ROBIN # Load Share type (ROUND_ROBIN / SLS )
PSP                                            1
RTE_CTX             0xD         # Routing context
END

#------------------------------------------------
# Routing Entry Parameters
#------------------------------------------------
#
DPC                            1.1.1       # DPC to accept traffic for
SIO            ISUP        # SIO value ISUP/TUP/SCCP/BICC or numeric 0 - 0xF
SIO_MASK                 0xF         # Use SIO for routing
RTE_TYPE          PS          # PS
NWK_ID            1           # Selects a network context for this PS
NSAP_ID        0
RTE_PS_ID     1
END

DPC                           1.1.1       # DPC to accept traffic for
SIO            SCCP        # SIO value ISUP/TUP/SCCP/BICC or numeric 0 - 0xF
SIO_MASK               0xF         # Use SIO for routing
RTE_TYPE                PS          # PS
NWK_ID                  1           # Selects a network context for this PS
NSAP_ID                 1
RTE_PS_ID              2
END

DPC                       1.1.2       # DPC supported by the peer server
RTE_TYPE         PS          # PS
NWK_ID         1           # Selects a network context for this PS
DPC_MASK          0xFFFFFF    # Match exactly
OPC                       0           # Optional OPC - 0 if OPC route matching unused
OPC_MASK          0           # Optional OPC mask if OPC route matching used
SIO            ISUP        # SIO value ISUP/TUP/SCCP/BICC or numeric 0 - 0xF
SIO_MASK           0xF         # Option SIO mask if SIO route matching used
RTE_PS_ID           3           # Peer Server ID for this Route
END

DPC                               1.1.2       # DPC supported by the peer server
RTE_TYPE         PS          # PS
NWK_ID              1           # Selects a network context for this PS
DPC_MASK                  0xFFFFFF    # Match exactly
OPC               0           # Optional OPC - 0 if OPC route matching unused
OPC_MASK       0           # Optional OPC mask if OPC route matching used
SIO            SCCP        # SIO value ISUP/TUP/SCCP/BICC or numeric 0 - 0xF
SIO_MASK         0xF         # Option SIO mask if SIO route matching used
RTE_PS_ID        4           # Peer Server ID for this Route
END

M3UA configuration file structure

M3UA implements services through the configuration of the following entities:

Entity	Description
General M3UA	The general configuration parameters define and control the general operation of M3UA including maximum values of various layer resources, congestion levels, and protocol timers.
Network configuration	Defines the SS7 network context or appearance for potential use over multiple SS7 networks, including SSF, DPC length, and SLS length.
Network service access points (NSAPs)	Defines the upper layer SS7 applications that use M3UA. Each NSAP is associated with one application, as identified by the service indicator field of a message, and one protocol variant.
M3UA SCT SAP (service access points)	Defines the lower layer interface between M3UA and SCTP. Only one SCT SAP can be defined.
Peer signaling process (PSP)	An instance of a peer server that can either be local or remote. A peer signaling process can process signaling traffic for multiple peer servers. Note: A peer server process can be a signaling gateway process (SGP), an application server process (ASP), or an IP server process (IPSP).
Peer server (PS)	A logical entity that serves a specific routing key. For example, a peer server can be a virtual switch element that handles a signaling relation identified by DPC/OPC, or a virtual database element that handles all HLR transactions for a particular SIO/DPC/OPC combination. There is a one-to-one relationship between a peer server and a routing key. Because the application server effectively represents an MTP3 user, it has its own point code. Note: A peer server can be an application server (AS) or signaling gateway (SG).
Routing entry	Set of M3UA parameters that uniquely define the range of signaling traffic to be handled by a particular peer server.

M3UA configuration considerations

Configure M3UA as either an application server process (ASP) or an IP server process (IPSP). In the actual configuration, there is little difference. The following table shows the required differences when configuring M3UA:

Parameter name	ASP	IPSP
MODE (for remote peer servers)	Must be set to LOADSHARE	Can be set to either LOADSHARE or ACTSTANDBY
PSP_TYPE	Set to SGP	Set to IPSP

If M3UA is configured as an IPSP, the IPSP_MODE parameter must be configured as either singled-ended (SE) or double-ended (DE):

Mode	Description
Single-ended	A single exchange of the ASPAC (ASP Active) and ASPAC ACK (ASP Active Acknowledgement) messages, that initiated from either side, is sufficient to allow traffic to flow in both directions.
Double-ended	Each side must send and receive the ASPAC and ASPAC ACK messages before allowing traffic flow.

IPSP_MODE is valid only when IPSP is configured as the remote peer signaling process type.
The CLIENT_SIDE parameter is required in an IPSP configuration. This parameter tells M3UA whether or not to initiate an association to the peer. Setting the CLIENT_SIDE parameter to TRUE indicates that M3UA always initiates an association. Setting this parameter to FALSE indicates that the other side is expected to initiate the association. If configured as an ASP, M3UA always initiates the association.
The RTE_CTX parameter, in the PS configuration section of the M3UA configuration file, must match the peer side’s configuration. For example, the route context for a remote PS must match that side’s route context for a local PS, and vice versa. The route context is passed in most M3UA messages and is used to match incoming messages with their associated NSAPs and upper layers. Refer to SIGTRAN architecture for more information.

M3UA configuration reference

This topic presents the M3UA configuration file parameters. To satisfy entity dependency, configuration sections must be loaded to the M3UA task in the following order:

General M3UA configuration
Network configuration
SCT SAP configuration
NSAP configuration
Peer signaling process configuration
Peer server configuration
Routing entry configuration

It is not required that these sections appear in this order in the text file, provided that the configuration program reads and downloads the sections in the correct order, as the provided m3uacfg sample file does.

General M3UA configuration

The following table lists the configurable parameters in the M3UA general configuration section. The default values for all timers at the M3UA level are shown in milliseconds. A configuration value of zero for a timer disables that timer.

Parameter	Default	Description
NODE_TYPE	ASP	Type of M3UA node. Only application server process (ASP) is currently supported. Use this parameter for both ASP and IPSP nodes.
MAX_NSAP	2	Maximum number of NSAPs supported simultaneously.
MAX_NETWORK	2	Maximum number of network contexts supported. There is one network context per variant and network indicator.
MAX_ROUTE	16	Maximum number of route entries supported, including local routes.
MAX_DPC	32	Maximum number of destination point codes (DPC) supported, including configured and dynamically learned DPCs.
MAX_PS	8	Maximum number of peer servers supported, including both local and remote peer servers.
MAX_LPS	4	Maximum number of local peer servers.
MAX_PSP	16	Maximum number of peer signaling processes supported.
MAX_MSG	128	Number of M3UA messages in transit supported.
MAX_RNDRBN_LS	4	Maximum number of peer servers that can use round-robin load sharing.
MAX_SLS_LS	4	Maximum number of peer servers that can use SLS-based (signaling link selector) load sharing.
MAX_SLS	128	Maximum number of SLS values that can be used by all peer servers.
QUEUE_SIZE	256	Outgoing congestion queue size per association. Messages above this limit are dropped.
CONG_LEVEL1	64	Congestion level 1 in the queue; not valid in international networks.
CONG_LEVEL2	128	Congestion level 2 in the queue; not valid in international networks.
CONG_LEVEL3	196	Congestion level 3 in the queue; not valid in international networks.
TMR_RESTART	1000	Restart hold-off time. This parameter is only used in an SGP configuration.
TMR_AS_PEND	5000	Time for which a peer server can remain in an AS_PENDING state.
TMR_ASP_UP1	2000	Initial time between ASPUP (ASP Up) retries.
TMR_ASP_UP2	2000	Steady state time between ASPUP retries.
NMB_ASP_UP1	3	Number of initial attempts at sending ASPUP messages at interval TMR_ASP_UP1 before sending them at interval TMR_ASP_UP2.
TMR_ASPDN	2000	Time between ASPDN (ASP Down) retries.
TMR_ASPM	2000	Time to wait before failing, after sending ASPAC (ASP Active) or ASPIA (ASP Inactive) messages.
TMR_DAUD	2000	Time between DAUD (Destination State Audit) messages.
TMR_DRKM	2000	Time between DRKM (Dynamic Routing Key Registration Message).
NMB_DRKM	3	Number of DRKM attempts before failing.
TMR_SEQ_CNTRL	1000	Delay used when diverting traffic to maintain sequencing.
PC_FORMAT	DFLT	Point code format used for all point codes in the M3UA configuration files. DFLT = Point codes are interpreted and displayed as 24-bit 8.8.8 values. INTL = Point codes are interpreted and displayed as 14-bit 3.8.3 values. JNTT = Use for both Japan NTT and TTC networks. Point codes are interpreted and displayed as 16-bit mcode.scode.ucode values with the U-code in the most significant 7 bits, the S-code in the next 4 bits, and the M-code in the least significant 5 bits.
TRACE_DATA	FALSE	Turns data tracing on or off. Data tracing is sent to the ss7trace utility. Refer to the TX Utilities Manual for information about ss7trace. Data tracing can also be turned on or off through the m3uamgr utility. Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for information about m3uamgr.
DEBUG_LOG	FALSE	Turns debug logging on or off. Debug logging is sent to the txalarm utility. Refer to the TX Utilities Manual for information about txalarm. Debug logging can also be turned on or off through the m3uamgr utility. Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for information about m3uamgr.
END	N/A	Marks the end of this general configuration definition. This parameter is required.

Network configuration

The following table describes the M3UA network configuration parameters:

Parameter	Default	Description
NETWORK_ID	1	Network identifier. Valid range is 1 - 255.
NETWORK_APPEAR	1234	Network appearance code. Network appearance values are determined and configured by network operators on each side of an association.
SSF	NAT	Subservice field. Valid values are: INTL = International NAT = National
DPC_LENGTH	24	DPC or OPC length. Valid values are: 14 = Length for ITU networks 16 = Length for Japanese networks 24 = Length for ANSI networks and other national variants
SLS_LENGTH	5	SLS length, in bits. Valid values are: 4 = SLS length 4 bits 5 = SLS length 5 bits 8 = SLS length 8 bits
SERVICE_USER_VAR	ANS	Protocol variant of the M3UA service user, such as ISUP, SCCP, and TUP. Valid values are: ANSI = ANSI variant BICI = BICI ITU = CCITT variant China = China variant NTT = NTT Japan TTC = TTC Japan
SERVICE_USER_VAR2	ANS	Protocol variant for user of the M3UA service user, such as TCAP, which uses SCCP. Valid values are: ANSI = TCAP type ANSI ETSI = TCAP type ETSI ITU = TCAP type ITU
END	N/A	Marks the end of this network configuration definition. This parameter is required.

SCT SAP configuration

The following table describes the M3UA SCT SAP configuration parameters:

Parameter	Default	Description
SCT_SAP_ID	0	M3UA identifier for this SCT SAP. This value must be 0.
SRC_PORT	2095	Source port for the listening endpoint.
SP_ID	0	SCTP identifier for this SCT SAP. This value must be 0.
END	N/A	Marks the end of this M3UA SCT SAP definition. This parameter is required.

NSAP configuration

The following table describes the M3UA NSAP configuration parameters:

Parameter	Default	Description
NSAP_ID	0 for ISUP 1 for SCCP	Identifier for this NSAP.
NWK_ID	1	Logical network identifier for this NSAP.
SERVICE_TYPE	ISUP	Type of NSAP service user. Valid values are: ISUP = ISUP user SCCP = SCCP user TUP = TUP user BICC = BICC user
END	N/A	Marks the end of this NSAP definition. This parameter is required.

Peer signaling process configuration

The following table describes the M3UA peer signaling process configuration parameters:

Parameter	Default	Description
PSP_ID	1	Peer service process (PSP) identifier. Valid values range from 1 to the result of (Max Number of PSP -1).
PSP_TYPE	IPSP	Remote peer signaling process type. Valid values are: SGP = Signaling gateway process. IPSP = IP service process.
IPSP_MODE	DE	Valid when PSP_TYPE = IPSP. Indicates whether the IPSP mode is single-ended or double-ended. Valid values are: DE = Double-ended mode SE = Single-ended mode
DRKM_ALLOWED	FALSE	Indicates whether this peer signaling process can send and receive dynamic routing key management (DRKM) messages. Valid values are: TRUE = Peer signaling process can send and receive DRKM messages. FALSE = Peer signaling process cannot send or receive DRKM messages.
USE_NWK_APP	FALSE	Determines whether the optional network appearance parameter is included when communicating with the remote peer. Valid values are: TRUE = Include the network appearance parameter. FALSE = Do not include the network appearance parameter.
ASP_ID_MAND	NONE	Indicates whether an ASP identifier is required in sent and/or received ASPUP and ASPUP ACK (ASP Up Acknowledgement) messages. Valid values are: RX = Identifier is required in received ASPUP and ASPUP ACK messages. TX = Identifier is required in transmitted ASPUP and ASPUP ACK messages. BOTH = Identifier is required in transmitted and received ASPUP and ASPUP ACK messages. NONE= ASP ID not required in transmitted or received ASPUP and ASPUP ACK messages.
NWK_ID	1	Default network context identifier for incoming messages, if the messages do not include one.
CFG_ALL_LPS	FALSE	Whether this PSP needs to be configured for all local peer servers: TRUE = Configure all local peer servers with this PSP. FALSE indicates = Do not configure all local peer servers with this PSP.
Association parameters
PRIME_DEST_ADDR	192.168.1.2	Primary destination address of the remote peer used in outgoing association requests.
DEST_PORT	2905	Remote SCTP port.
CLIENT_SIDE	TRUE	TRUE = Associations are automatically initiated from this PSP, if PSP_TYPE = IPSP. FALSE = Associations are not initiated from this PSP, if PSP_TYPE = IPSP. The other side is expected to initiate any associations.
NMB_OUT_STREAMS	2	Number of streams supported by this association. Valid range is 1 - 255.
TOS	0	Type of Service octet sent in all outgoing packets for this association. This can be changed later using the M3UA management API. For more information, refer to Dialogic® NaturalAccess™ SIGTRAN Stack Developer’s Reference Manual.
END	N/A	Marks the end of this PSP configuration definition. This parameter is required.

Peer server configuration

The following table describes the M3UA peer server configuration parameters:

Parameter	Default	Description
PS_ID	N/A	Peer server identifier.
NWK_ID	1	Peer server network identifier.
MODE	ACTSTANDBY	Peer server availability mode. Valid values are: ACTSTANDBY LOADSHARE BROADCAST (not supported)
LOAD_SHARE_TYPE	ROUND_ROBIN	If MODE = LOADSHARE, the LOAD_SHARE_TYPE parameter selects the type of load sharing to use. Valid values are: ROUND_ROBIN SLS
LOCAL	FALSE	Indicates whether the peer server is local or remote: TRUE = Local peer server FALSE = Remote peer server
PSP	1	Ordered list of PSP identifiers configured in the system that handle the routing key associated with this PS. Preference is given to earlier entries in the list when performing fail-over or fail-back procedures. Valid values are 1 to MAX_PSP.
RTE_CTX	0	Routing context. Allowed value is any unsigned 32-bit integer.
END	N/A	Marks the end of this peer server definition. This parameter is required.

Routing entry configuration

The following table describes the M3UA routing configuration entry parameters:

Parameter	Default	Description
DPC	N/A	Destination point code associated with this route.
DPC_MASK	0xFFFFFF	Wildcard mask for the DPC. In most cases, set to all 1 bits to use the entire DPC for routing.
OPC	0	Origination point code (OPC) associated with this route, if any.
OPC_MASK	0	Wildcard mask for the OPC. In most cases, set to all 1 bits (0xFFFFFF) to use the entire OPC for routing, if OPC routing is required. Otherwise, set to 0 to indicate that OPC routing is not used.
SIO	0	Service information octet (SIO) associated with this route, if any. Valid values are ISUP, SCCP, BICC, TUP, or a numeric value between 0 and 0xF. Note: If SIO is not specified, the default is 0, which indicates that SIO is not used for routing.
SIO_MASK	0	Wildcard mask for the service information octet (SIO). If SIO is set, set SIO_MASK to 0xF to use the specified SIO value for routing. Set SIO_MASK to 0 if SIO routing is not used.
RTE_TYPE	PS	Route type. Valid value is PS.
NWK_ID	1	Network identifier. Valid range is 1 - 255.
NSAP_ID	0	NSAP identifier configured in the system with which this route is associated. Used only for local (or up) routes. Do not specify for remote routes.
RTE_PS_ID	0	Identifier of the peer server associated with this route.
END	N/A	Marks the end of this routing entry definition. This parameter is required.

Creating the SCTP configuration

NaturalAccess Signaling Software provides the following sample files for SCTP configurations that you can modify for your specifications:

Files	Description
SCTPcp1.cfg	SCTP file for board 1.
SCTPcp2.cfg	SCTP file for board 2.

The SCTP configuration utility runs as part of the initial board download with ss7load. The utility reads the text configuration file and downloads the specified configuration to the SCTP control layer (part of the SIGTRAN task) on the TX board. You can also run the SCTP configuration utility after the initial configuration to dynamically update selected configuration parameters.
This topic presents:

Sample SCTP configuration file

The following example is the SCTP configuration file for board 1:

# SCTP Sample Configuration File
#
# All timer values are in milliseconds
#
#------------------------------------------------
# General SCTP Parameters
#------------------------------------------------
MAX_ASSOC                      4       # Max SCTP associations
MAX_DEST_ADDRS      8       # Max active dest addresses in all assoc
MAX_TX_QUEUE     256     # Max datagrams that can be queued for Tx
MAX_RX_QUEUE        256     # Max datagrams that can be queued for Rx
MAX_INSTREAM            8       # Max incoming streams per assoc
MAX_OUTSTREAM       8       # Max outgoing streams per assoc
MTU_INITIAL      1400    # Initial max transmit size in bytes
MTU_MAX             1400    # Max value used in searching for optimal MTU
MTU_MIN          500     # Min value used in searching for optimal MTU
PERFORM_MTU           FALSE   # Whether or not to perform MTU discovery
HOSTNAME               myhost1 # Self-hostname
USE_HOSTNAME          FALSE   # Whether or not to send hostname in INIT/INIT-ACK
MAX_INIT_RETRY     0       # Max retries for INIT message. 0 = infinite.
MAX_ASSOC_RETRY   10      # Max datagram retries for existing association
MAX_DEST_RETRY       5       # Max datagram retries to a destination address.
ACCEPT_ALT                 FALSE   # Whether or not to accept additional lifetime param
                           # from peer to extend cookie lifetime
TMR_MD5_KEY     60000   # Lifetime of an MD5 key.  New one generated every
                         # time it expires.
RTT_ALPHA          1      # Used for RTT calculations
RTT_BETA                     1       # Used for RTT calculations
END

#------------------------------------------------
# SCT Upper SAP parameters
#------------------------------------------------
SCT_SAP_ID       0       # SAP ID used by upper layer (M3UA). Must be 0.
TMR_ACK_DELAY     200     # Max time before sending a SACK
NMB_ACK_DELAY     2       # Max number of received datagrams before sending a SACK
TMR_INIT_RTO           3000    # Initial value of the retransmission timeout
TMR_MIN_RTO         2000    # Minimum value of the retransmission timeout
TMR_MAX_RTO       10000   # Maximum value of the retransmission timeout

TMR_BUNDLE         200     # Bundle timer
TMR_COOKIE_LIFE               60000   # Base cookie life time
TMR_HB_INTERVAL              3000    # Default heartbeat interval timer
MAX_BURST        4       # Maximum burst value
MAX_HB_BURST    1       # Max heartbeats sent upon retransmission timeouts
ABORT_ON_STREAM FALSE   # Abort assoc if Rx instream count less than Tx
                                                                # outstream count
ENABLE_HEARTBEAT TRUE    # Enable / Disable heartbeat by default
FLOW_START_THR                192     # Number of messages in outgoing queues when
                         # flow control to layer 3 is invoked
FLOW_STOP_THR       64      # Number of messages in outgoing queues when
                            # flow control to layer 3 is stopped
TMR_SD_GUARD        15000   # Shutdown guard timer for graceful shutdowns.
END

#------------------------------------------------
#SCT Lower SAP (TSAP) parameters
#------------------------------------------------
TSAP_ID                      0       # SCTP reference for this SAP. Must be 0.
SAP_ID                  0       # Transport reference for this SAP. Must be 0.
MAX_BIND_RETRY    3       # Maximum number of Bind Req retries
TMR_CFM             200     # Timeout waiting for bind or status confirm from lower Layer
END

SCTP configuration file structure

The following table describes the sections of the SCTP configuration file:

Section	Description
General SCTP	General configuration parameters for SCTP.
SCT Upper SAP	SCT SAP configuration parameters.
SCT Lower SAP (TSAP)	TSAP configuration parameters.

SCTP configuration reference

This topic presents the SCTP configuration file parameters:

General SCTP
SCT Upper SAP
SCT Lower SAP (TSAP)

All timer values are in milliseconds.

General SCTP

The following table describes the SCTP general configuration parameters:

Parameter	Default	Description
MAX_ASSOC	4	Maximum number of SCTP associations the service user can open simultaneously. Valid range is 1 - 65535.
MAX_DEST_ADDRS	8	Maximum number of destination addresses that can be active simultaneously in SCTP. Valid range is 1 - 65535.
MAX_TX_QUEUE	256	Maximum number of datagrams that can be queued for sending to the peer. Valid range is 1 - the result of (2^32-1).
MAX_RX_QUEUE	256	Maximum number of datagrams received from the peer that can be queue before being sent up to the service user. Valid range is 1 - the result of (2^32-1).
MAX_INSTREAM	8	Maximum number of incoming streams per association. Valid range is 1 - 65545.
MAX_OUTSTREAM	8	Maximum number of outgoing streams per association. Valid range is 1 - 65545.
MTU_INITIAL	1400	Initial path max transmit unit (MTU) in bytes. Valid range is 1 - 1400.
MTU_MAX	1400	Maximum value in bytes to be used in searching for an optimal MTU size using the midpoint algorithm. This field is mandatory if the value of the PERFORM_MTU parameter is TRUE. Valid range is 1 - 1400.
MTU_MIN	500	Minimum value in bytes to be used in searching for an optimal MTU size using the midpoint algorithm. This field is mandatory if the value of the PERFORM_MTU parameter is TRUE. Valid range is 1 - 1400.
PERFORM_MTU	FALSE	Indicates whether or not to perform MTU discovery. Valid values are: TRUE = Perform MTU discovery. FALSE = Do not perform MTU discovery.
HOSTNAME	NULL	Self-hostname.
USE_HOSTNAME	FALSE	Whether or not to send hostname in INIT (Initiation) / INIT ACK (Initiation Acknowledgement).
MAX_INIT_RETRY	0	Maximum number of retries for INIT message to open an association. Valid range is 0 - 255. Set to 0 to retry indefinitely. When MAX_INIT_RETRY number of sends is reached, SCTP terminates the association and M3UA immediately attempts to establish another association The INIT for this new association will contain new TSN and InitTag parameters.
MAX_ASSOC_RETRY	10	Maximum retransmissions for an association. Valid range is 0 - 255.
MAX_DEST_RETRY	5	Maximum retransmissions for a destination address. Valid range is 0 - 255.
ACCEPT_ALT	FALSE	TRUE = Accepts additional lifetime parameters from the peer to extend cookie lifetime. FALSE = Does not accept additional lifetime parameters from the peer to extend cookie lifetime.
TMR_MD5_KEY	60000	Lifetime of an MD5 key. A new private key is generated every time this timer expires. Valid range is 1 - 65535.
RTT_ALPHA	12	Used for round trip time (RTT) calculations. Valid range is 0 - 65535.
RTT_BETA	25	Used for RTT calculations. Valid range is 0 - 65535.
TRACE_DATA	FALSE	Turns data tracing on or off. Data tracing is sent to the ss7trace utility. Refer to the Dialogic® TX Series SS7 Boards TX Utilities Manual for information about ss7trace. Data tracing can also be turned on or off through the sctpmgr utility. Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for information about sctpmgr.
DEBUG_LOG	FALSE	Turns debug logging on or off. Debug logging is sent to the txalarm utility. Refer to the Dialogic® TX Series SS7 Boards TX Utilities Manual for information about txalarm. Debug logging can also be turned on or off through the sctpmgr utility. Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for information about sctpmgr.
END	N/A	Marks the end of this general SCTP definition. This parameter is required.

SCT Upper SAP

The following table describes the SCT upper SAP configuration parameters:

Parameter	Default	Description
SCT_SAP_ID	0	SAP ID used by the upper layer (M3UA). This identifier must be specified and must be 0.
TMR_ACK_DELAY	200	Maximum time to wait before the SCTP layer must send a SACK (Selective Acknowledgement) message. Valid range is 1 -165535.
NMB_ACK_DELAY	2	Maximum number of messages to receive before the SCTP layer must send a SACK message. Valid range is 1 - 165535.
TMR_INIT_RTO	3000	Initial value of the retransmission timeout (RTO). The SCTP layer retransmits data after waiting for feedback during this time period. Valid range is 1 - 65535.
TMR_MIN_RTO	1000	Minimum value used for the RTO. If the computed value of RTO is less than TMR_MIN_RTO, the computed value is rounded up to this value. Valid range is 1 - 65535.
TMR_MAX_RTO	10000	Maximum value used for RTO. If the computed value of RTO is greater than TMR_MAX_RTO, the computed value is rounded down to this value. Valid range is 1 - 65535.
TMR_COOKIE_LIFE	60000	Base cookie lifetime for the cookie in the INIT ACK (Initiation Acknowledgement) message. Valid range is 1 - 65535.
TMR_HB_INTERVAL	3000	Default heartbeat interval timer. Valid range is 1 - 65535.
MAX_BURST	4	Maximum burst value. Valid range is 1 - 65535.
MAX_HB_BURST	1	Maximum number of heartbeats sent at each retransmission timeout (RTO). Valid range is 1 - 65535.
ABORT_ON_STREAM	FALSE	Action to take when the receiver's number of incoming streams is less than the sender's number of outgoing streams. Valid values are: TRUE = Accept incoming stream and continue association. FALSE = Abort the association.
ENABLE_HEARTBEAT	TRUE	Whether to enable or disable heartbeat by default. Valid values are: TRUE = Enable heartbeat (recommended for allowing earlier detection of loss of associations). FALSE = Disable heartbeat.
FLOW_START_THR	192	Number of messages waiting in queue, when flow control indication is sent to the service user (M3UA) to inform it that the queue is nearly full. Valid range is FLOW_STOP_THR to MAX_TX_QUEUE.
FLOW_STOP_THR	64	Number of messages waiting in queue, when flow control indication is sent to the service user (M3UA) to inform it that the queue is almost empty. Valid range is 0 to FLOW_START_THR.
TMR_SD_GUARD	15000	Shutdown guard timer for graceful shutdowns. Valid range is 1 - 65535.
END	N/A	Marks the end of this SCT upper SAP definition. This parameter is required.

SCT Lower SAP (TSAP)

The following table describes the SCT lower SAP (TSAP) parameters:

Parameter	Default	Description
TSAP_ID	0	Service user ID for the TSAP being configured. This must be 0.
SAP_ID	0	Service provider ID of the TSAP to which this TSAP binds. This must be 0.
MAX_BIND_RETRY	3	Maximum number of bind request retries allowed.
TMR_CFM	200	Time interval for which the SCTP layer waits for bind or status confirmations from the lower layer.
END	N/A	Marks the end of this SCT lower SAP (TSAP) definition. This parameter is required.