Use this page to configure the SIP container settings for Session Initiation Protocol (SIP).
To view this administrative console page, click
.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 |
Specifies the 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 application server to another due to failover, the active application server 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 |
Specifies the 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 |
Specifies the 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.
Configure your 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 |
Specifies the 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. You can disable this feature in the administrative 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 |
Specifies the 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 |
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 |
Specifies whether to enable locating SIP servers using DNS (Directory Name Service).
A SIP Uniform Resource Identifier (URI) can be resolved through DNS into the Internet Protocol (IP) address, port, and transport protocol of the next hop.
Data type | Boolean |
Default | False |
Data type | String |
Default | empty string. |
Data type | String |
Default | empty string. |
Specifies the available thread pools that you can select from the drop-down list for the SIP container to use when dispatching work. If you do not select a thread pool from the drop-down list, a default thread pool, which is automatically created by the container, is used.
It is recommended that you create 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 |