SIS supports both SIP and IN network interface types. Each type of network interface supports a number of mandatory and optional configuration properties. Below are the configuration parameters for SIP and IN network interface definitions.

SIP network interface definition parameters

Parameter Description Default

IP address
IPAddress

The IP address or hostname for the SIS. The SIS will listen on this address. The address AUTO will automatically select the node’s primary IP address, for convenience and use in a cluster, where each node has its own IP address.

An IP address range may also be used, using address/mask notation; for example, 192.168.0.0/24. This will select the matching IP address on the node, if one exists. This may be useful in a cluster where nodes have IP addresses on the same subnet.

Example: sis.mydomain.com
Example: 192.168.5.0/24

none

Virtual addresses
VirtualAddresses

Optional comma-separated list of alternative addresses that the SIS is known by, such as virtual addresses provided by an external load balancer. DNS NAPTR or SRV names for the SIS should also be specified here. The SIS treats requests that are routed to these addresses as destined for the SIS; they must be processed by the SIS before forwarding.

Addresses may also include a port number, which would specify the load balancer port, if an external load balancer provides the virtual address on a different port to the SIS. If no port is specified then the SIS will match the virtual address on any port. If the literal string <local-port> is used instead of a port number, an address will match if its port matches the SIS’s port.

If this property is set, and the UseVirtualAddressInURIs property is set to true, the first name in the list will be used in SIP URIs generated by the SIS, so that mid-dialog requests are routed back to the virtual address, not a specific node. The first name should be the fully-qualified hostname that corresponds to the virtual address.

Example: sis1.mydomain.com, sis2.mydomain.com:5090
Example: tas.home1.net:<local-port>

an empty list

Dynamic SRV name format
DynamicSRVNameFormat

Format for generating a DNS SRV name from either the interface’s IP address ${IP} or the environment variable SRV_INSTANCE_ID which is set in a startup script, .bashrc, etc.

If the format string is 'mmtel-${IP}.home1.net' then this will generate names like 'mmtel-10-0-0-1.home1.net'.

If the format string is 'mmtel-${SRV_INSTANCE_ID}.home1.net', and the environment variable SRV_INSTANCE_ID has been set to node101 then this will generate the name 'mmtel-node101.home1.net'. If the SRV_INSTANCE_ID value is not a valid FQDN label then a RA configuration alarm will be raised, and the network interface will not enter active state.

If defined, the SIS will use the generated SRV name in its own Contact and Record-Route headers. Corresponding SRV records must be provisioned in the DNS, which favour the given node’s IP address, but allow failover to backup addresses if the primary address fails.

Either ${IP} or ${SRV_INSTANCE_ID} can be used in the format string, not both.

Default: none (no SRV name will be generated).

Example: , mmtel-${IP}.home1.net generates names like mmtel-10-0-0-1.home1.net.

none

Use virtual address in URIs
UseVirtualAddressInURIs

If true, the first virtual address (if defined) is used in SIP URIs.

 false

Port
Port

Port that will be used for unencrypted SIP transports (UDP, TCP).

 5060

Secure port
SecurePort

Port that will be used for encrypted SIP transports (TLS).

 5061

SIP transports
Transports

SIP transports to be supported by the SIS. This is a comma-separated list containing one or more of UDP, TCP or TLS.

 UDP
TCP

Via sent-by address
ViaSentByAddress

Specifies an IP address or hostname that will be used in the "sent-by" field of Via headers added by the SIS. If a value is not specified the SIS will use the local IP address of the node. In some scenarios it may be necessary to specify a value to use a virtual server address. Example: sis.mydomain.com

null

IN network interface definition parameters

Below are general default network interface settings, followed by those specific to the OCSS7, Signalware, and simulated TCAP stacks.

Note
Using TCAP stacks

General settings

Parameter Description Default

Local SCCP address
local-sccp-address

SCCP address assigned to the SIS instance, included in dialog open requests sent by the SIS instance to the network. See also SCCP Address Format and Administering the CGIN Resource Adaptor Entity.

Example: type=C7,ri=pcssn,pc=202,ssn=101

 _none_

Responder SCCP address
responder-sccp-address

SCCP address used by the SIS when sending responses to received dialog open requests. This setting is optional and only needs to be specified if an address different to that filled in by the TCAP stack when sending open responses is required. See also SCCP Address Format.

Example: type=C7,ri=pcssn,pc=202,ssn=101

auto

Default TCAP invoke timeout
default-invoke-timeout

The timeout period, measure in milliseconds, the SIS uses whenever it needs to send non-service-specified invoke requests to the network.

 5000

Default dialog activity timeout
default-activity-timeout

The default timeout period, measured in milliseconds, for dialogs with no activity before they are terminated.

 1800000

TCAP fibers maximum pool size
tcap-fibers.max-pool-size

The maximum number of threads in the TCAP layer fiber pool. If zero, then a pool is not used: work is done directly in the I/O thread.

 4

TCAP fibers queue size
tcap-fibers.queue-size

The maximum number of waiting fibers in the TCAP layer fiber pool.

If the queue becomes full and there are less than the maximum number of worker threads, a new thread is started. If the queue is full and no more threads are permitted, then subsequent fiber tasks are executed directly by the calling thread (usually the I/O thread).

A zero-sized queue is possible and implies that work is either immediately assigned an idle thread, or the work is done by the calling thread.

 250

Inbound ACN aliases
acn-inbound-aliases

Comma-separated list of values in <external OID>:<internal ASN.1> format. It allows the SIS to be configured to accept the external application context name as a synonym for the internal application context name. An external ACN can be mapped to only one internal ACN. Several external ACNs can be mapped to the same internal ACN. The right-hand-side of each mapping can either name an application context value (eg. etsi_inap_cs1.core-INAP-CS1-SSP-to-SCP-AC), or it can name the interceptor to use to determine the AC to use (eg. map.phase-1).

 _none_

Outbound ACN mappings
acn-outbound-mappings

Comma-separated list of values in <internal ASN.1>:<external OID> format. It allows the SIS to be configured to write the external application context name in place of the internal application context name. An internal ACN can be mapped to only one external ACN. Multiple internal ACNs can be mapped to the same external ACN.

 _none_

Relaxed BER decoding rules
relaxed-decoding

Specifies whether or not to relax the BER decoding rules to allow certain types of malformed data. If true, then some malformed BER encodings in protocol data will be accepted:

  1. Needlessly long encoding of INTEGER or ENUMERATED (more that 9 leading '0' or '1' bits).

  2. Primitive encoding of a BIT STRING with a length of zero.

  3. Encoding of an OID with a length of zero.

  4. Non-innermost TL pair in the encoding of NULL, BOOLEAN, INTEGER or ENUMERATED indicates indefinite length form of encoding but the tag lacks the"constructed" bit set.

  5. Needlessly long encoding of an exponent.

If false, then the BER rules are strictly enforced and malformed data will be rejected.

This property applies to the decoding of application protocol data contained within operations, errors, and user information. It does not apply to the decoding of the surrounding TCAP data; TCAP data is always strictly decoded.

 false

TCAP stack
stack

Name of the TCAP stack for the SIS to use. Three stacks are currently supported:

  • ocss7, a TCAP stack that connects to one or more TCAP Manager (SGC) processes;

  • signalware, a TCAP stack that connects to one or more backend processes running on Mavenir Signalware;

  • tcapsim, a simulated TCAP stack that does not require any specific hardware.

Example: ocss7

 _none_

Network interface definition parameters specific to the OCSS7 stack

Warning These parameters only need valid values if using the OCSS7 TCAP stack.
Parameter Description Default

SGCs
ocss7.sgcs

Comma-separated list of host:port pairs.
Example: ocss71:9703,ocss72:9703

The SIS will attempt to establish a connection to all of the configured host:port pairs.

 localhost:12201

URL List
ocss7.urlList

Comma-separated list of host:port locations where the SIS instance can expect to find OC SS7 SGC TCAP Manager processes running and listening for connections from the SLEE. Example: ocss71:8080,ocss72:8080

This parameter cannot be used with ocss7.sgcs. Use of ocss7.sgcs is recommended in preference to this parameter, see TCAP Stack and SGC Stack cooperation

 _none_

URL List Retry Interval
ocss7.urlList.retrySleep

The wait interval in milliseconds between subsequent connection attempts to the TCAP Managers. The value applies to all manager connections.

 1000

Local SSN
ocss7.local-ssn

The subsystem number used when the local-sccp-address property does not provide one, for example in the case when it is set to auto. Valid range: 2-255 (Only checked if actually needed)

 -1

Open Transactions Capacity
ocss7.trdpCapacity

The maximum number of open transactions (dialogs) at any moment in time. Valid range: 1000-2000000

 1000000

Max Scheduler Threads
ocss7.schThreads

The maximum number of threads used by the scheduler. Valid range: 1-100.

 10

Scheduler Node List Size
ocss7.schNodeListSize

The number of events that may be scheduled on a single scheduler thread. This value multiplied with the value for Max Scheduler Threads should be directly proportional to Open Transactions Capacity. Valid range: 0 (autosize) or 1000-2000000.

 0

Waiting Tasks Capacity
ocss7.taskdpCapacity

The maximum number of inbound messages and timeout events that may be waiting to be processed at any moment in time. This value should be directly proportional to Open Transactions Capacity. Valid range: 0 (autosize) or 1000-2000000.

 0

Worker Group Queues
ocss7.wgQueues

The number of threads used by the worker group to process timeout events and inbound messages. Valid range: 1-100.

 100

Worker Queue Size
ocss7.wgQueuesSize

The maximum number of tasks in one worker queue. This value multiplied with the value for Worker Group Queues should be directly proportional to (2 * Waiting Tasks Capacity). Valid range: 0 (autosize) or 1000-2000000.

 0

Sender Queue Size
ocss7.senderQueueSize

The maximum number of outbound messages in the sender queue. This value is directly proportional to Open Transactions Capacity. Valid range: 0 (autosize) or 1000-2000000.

 0

Heartbeat Enabled
ocss7.heartbeatEnabled

This property only affects operation when connecting to SGC versions 1.0.1 and older. Heartbeat is always enabled when connecting to SGCs 1.1.0 and newer. Enables or disables the heartbeat between the TCAP stack and the SGC. Also enables the heartbeat timeout detection mechanism. N.B. If the heartbeat is enabled on the SGC it must also be enabled here. Valid values: true or false

 true

Heartbeat Period
ocss7.heartbeatPeriod

The period between heartbeat sends in seconds. Heartbeat timeout is also a function of this value (twice this value). When connecting to SGC version 1.0.1 and older the value configured here must match that configured on the SGC. When connecting to SGC version 1.1.0 and newer, this value is communicated to the SGC during handshake negotation. It is not necessary to separately configure the SGC’s heartbeat. Valid range: 1+

 5

Network interface definition parameters specific to the Signalware stack

Warning These parameters only need valid values if using the signalware TCAP stack.
Parameter Description Default

Backends
signalware.backends

Comma-separated list of host:port locations where the SIS instance can expect to find Signalware backend processes running and listening for connections from the SLEE.

Example: signalware1:10001,signalware2:10001

none

Base weight
signalware.base-weight

Base incoming traffic weight advertised to backends.

This property is a comma-separated list that must include at least one numeric item — the weight value used by any node that does not explicitly specify a weight. Additional items may specify weights for particular nodes, using the form
{nodeid,nodeid,…​}weight.

For example, the value 100,{101}50,{102,103}75 specifies a weight of 50 for node 101, a weight of 75 for nodes 102 and 103, and a default weight of 100 for all other nodes.

Each weight is a positive integer used to balance load between nodes. The values have no particular unit other than relative to each other. A node will receive new dialogs in proportion to its weight; for example, two nodes with weights of 10 will receive about the same number of dialogs each, and a node with a weight of 20 will receive twice as many as a node with a weight of 10.

Tip One approach is to treat them as percentages and assign 100 to the busiest node, with smaller values for nodes that take less load.

The actual weight used for a particular node is the base weight specified here, modified by the function defined by weight function below, based on the amount of traffic that node has processed.

 100

Weight function
signalware.weight-function

Definition of the weight function applied to "full-rate" weights to find the actual rate to use. This is used to gradually increase load on a newly-joined cluster node, so as not to immediately swamp it with traffic.

The function is specified as a series of comma-separated values S(1),T(1),S(2),T(2),…​,S(N-1),T(N-1),S(N) where:

  • S(i) is the multiplier (in the range [0.0 .. 1.0]) of the "full-rate" weight to use in state (i)

  • T(i) is the total number of dialogs that must be received on a particular node before moving to state (i+1).

 0.01,10,0.10,1000,
0.50,5000,1.00

Fiber map size
signalware.fiber-map-size

The number of fibers in the fixed-size fiber map used to process incoming traffic. This value must be at least as large as the value of the TCAP Fibers Queue Size property.

 256

Dialog allocation timeout
signalware.dialog-allocation-timeout

The maximum time, in milliseconds, to block while waiting to allocate a new dialog before returning an error to the calling service code.

 5000

Dialog pool size
signalware.dialog-pool-size

The size of the pre-allocation pool for outgoing dialogs. This pool is used to satisfy requests for new outgoing dialogs, and is refilled asynchronously. If the pool becomes empty due to a high rate of dialog creation, outgoing dialogs must wait for the backend to allocate a new dialog, increasing latency.

One pool is maintained per backend connection.

 100

Network interface definition parameters specific to the simulated TCAP stack

Warning These parameters only need valid values if using the simulated TCAP stack.
Parameter Description Default

Listen addresses
tcapsim.listen-addresses

Comma-separated list of host:port[:nodeID] addresses to listen on for incoming connections from other tcapsim TCAP stacks. Example: localhost:10100

none

Maximum dialogs
tcapsim.max-dialogs

Maximum number of concurrent dialogs to support.

 10000

Routing table
tcapsim.routing-table

Path to the file containing the routing table description.

 ${rhino.dir.home}
${/}config${/}
tcapsim-routing-table.txt

Global title translation table
tcapsim.gt-table

Path to the file containing the global translation table description

 ${rhino.dir.home}${/}
config${/}
tcapsim-gt-table.txt
Previous page Next page
SIS Version 3.2