SIP container settings
Use this page to configure the SIP container settings for Session Initiation Protocol (SIP).
To view this admin console page, click Application servers > serverName > SIP container settings > SIP container.
- Use SIP proxy for external domains
Specifies that, when true, the SIP container assumes the existence of the SIP Proxy running on another server process and therefore, delegates routing outbound traffic to that component.
Data type Boolean Default True
- Maximum application sessions
Maximum number of SIP application sessions that the container manages. When the maximum is reached, no new SIP conversations are started. When the maximum is exceeded in a clustered environment, the server does not forward new dialogs until the number of application sessions no longer exceeds the maximum.
Application sessions are typically created by new incoming calls, but can also be created by other events. The application session count does not impact failover, but applies only to new sessions that are created as a result of incoming calls.
When application sessions are transferred from one appserver to another due to failover, the active appserver inherits the sessions created on the failed server. In addition, the servlet might create a new application session in the SIP container by calling SipFactory.createApplicationSession().
New application sessions created for events other than starting SIP conversations are not controlled by this setting. But all new application sessions are included when computing the maximum number of application sessions allowed. Thus, all active application sessions, including those not related to starting SIP conversations, can cause the maximum to be exceeded.
Data type Integer Default 120000 (recommended) Range 1 <= n <= java.lang.Integer.MAX_VALUE
- Maximum messages per averaging period
Maximum amount of SIP messages processed per averaging period. The averaging period is the period of time during which the average number of messages received by the container is calculated.
This average is used to determine the load for the container and to determine if the number of messages is approaching the maximum. When the maximum is exceeded, the stand-alone server or the proxy server continues to handle all in-dialog messages. Other non-dialog requests are rejected. When a container is in an overloaded state, the proxy server returns a 503 error.
Data type Integer Default 5000 (recommended) Range 1 <= n <= java.lang.Integer.MAX_VALUE
- Maximum dispatch queue size
Size of the internal dispatch queue. When the maximum queue size threshold is reached, the container queue becomes overloaded and begins to drop requests for new sessions. In this case, the container does not report its overloaded state to the proxy server.
Set the system to limit the queue size to prevent the queue from reaching this threshold. If the internal queue reaches the overloaded state, incoming UDP packets are dropped until the queue is no longer in an overloaded state. Limiting the queue size enables better recovery if the CPU is used by other processes or threads and prevents the container from reaching out-of-memory conditions. When the value is set to 0, the queue size is unlimited.
Data type Integer Default 5000 (recommended) Range 0 <= n <= java.lang.Integer.MAX_VALUE
- Maximum response time
Maximum response time, in milliseconds, for an application. When the amount of time is exceeded, the container notifies the clustering framework that it is unavailable. We can disable this feature in the admin console by deselecting the check box and specifying a value of 0.
Use the maximum SIP response time setting cautiously because the calculated response time does not match the behavior of all applications. For requests, such as INVITE requests, where the responses are generated as a result of a user interaction, the calculated response time is extensive. However, the extensive response time is not caused by a delay in the SIP container. Therefore, you should not calculate the response time as a load factor. The recommended applications for effective calculation of response time are applications that respond immediately without a user interaction. The subscribe and register applications are relevant examples.
Data type Integer Default 0 Range 1 <= n <= java.lang.Integer.MAX_VALUE
- Averaging period in milliseconds
Amount of time, in milliseconds, to use for calculating the maximum messages per averaging period. This setting is the sliding window during which the SIP container counts the number of messages sent to the container.
Data type Integer Default 1000 (recommended) Range 1000 <= n <= java.lang.Integer.MAX_VALUE
- Statistic update rate
Specifies control over the interval for which the container calculates averages and publishes statistics to Performance Monitoring Infrastructure.
Data type Integer Default 1000 (recommended) Range 1000 <= n <= java.lang.Integer.MAX_VALUE
- Locating SIP servers using DNS
Whether to enable locating SIP servers using DNS (Directory Name Service).
A SIP URI can be resolved through DNS into the Internet Protocol (IP) address, port, and transport protocol of the next hop.
The value for the Primary DNS server name or Secondary DNS server name fields is a string containing one address and port tuple.
The following examples specify an address and port tuple.
The container contacts the primary DNS server first; however, if the primary DNS server is unavailable, then the container contacts the secondary DNS server.
If the secondary DNS server remains responsive, the container does not attempt to contact the primary DNS server.
- dottedDecimalAddress@.port
- hostname.domain@port
- IPV6address@port
Data type Boolean Default False
- Primary DNS server name
- Specifies an IP address and port tuple for the primary DNS server. If this server is not available, then the container sends a response to the secondary DNS server.
Data type String Default empty string.
- Secondary DNS server name
- Specifies an IP address and port tuple for the secondary DNS server.
Data type String Default empty string.
- Thread pool
Available thread pools that we can select from the drop-down list for the SIP container to use when dispatching work. If we do not select a thread pool from the drop-down list, a default thread pool, which is automatically created by the container, is used.
IBM recommends created a dedicated WebSphere thread pool for SIP applications. For general usage, this is a minimum of 15 threads and a maximum of 30 threads (with one thread per queue). This becomes convenient when combined with WebSphere hung thread detection. A hung thread can block many SIP messages, so it is important it be detected as soon as possible. However, the default hung thread detection threshold is too long for most SIP scenarios, so it is recommended you change it to 30 seconds. See the "Configuring the hang detection policy" topic (linked below) for the exact property names.
Data type menu list Default None
Related tasks
Set the hang detection policy
Set the SIP container
Related information
Server collection