Enhanced handling of XS requests
SIP Server will be enabled to handle different HTTP error responses from Feature Server for Dial Plan requests, in appropriate way to notify the origination.
Also, any extended service (XS) request will get timed out after a set timeout value and the request will be rejected by SIP Server.
Switchover SIP Server to backup mode, when there is no active connection to any of the configured Feature Server URLs.
When XS request post timeout ("xs-post-timeout") happens or any error response is received then SIPS will select alternate active FS URL and retry the request. Retry will be done only once. When one FS URL becomes OOS, subsequent requests should not be sent to that, until it becomes in-service, which will be done using heartbeat. Introduce "xs-request-timeout", timer which controls how long XS request will be alive before considering as failed. When FS VOIP Service DN is OOS, beacause none of the FS URLs are active, SIPS will not queue the request rather it will start rejecting the call request with 503 response. On receiving error codes "400, 404, 501, 503" or number of request retries exceeded, SIP Server responds with '503' response without any retry. The FS URL should be marked offline on receiving '503' or after exceeding heartbeat failure threshold. When a SIP Server running in Primary mode, does not have any active connection to any configured Feature Server URL, it should be moved to Backup mode --- Once a XS request is sent to one of the Feature Server (FS) URLs, the timer of value set by "xs-post-timeout" get started and waits for response. On timeout, the request will be retried with next available FS URL to process it. Same way, the request will be tried again if any error response is received from FS. This means that, the error is recoverable and might get success response from another FS URL. A FS URL will be marked as Offline, if number of failed heartbeat requests exceed the set threshold (xs-missed-heartbeat-threshold), and such an URL will not be selected for further request processing, until it responds with "200" for a heartbeat request.
The retry of the same request will be done only once in any case and after that the request will be rejected.
Below are the new way of SIP Server handling certain error responses from FS instance. A new hidden option "xs-reject-responses" can be used to provide the responses to be rejected by SIP Server without retry. [TABLE] ---
If none of the FS URLs are available and marked Offline, any request for dial plan will be rejected with "503 Service Unavailable" by SIP Server. If the option "switchover-on-xs-oos" is set true, then instead of rejecting the requests, SIP Server will send SERVICE_UNAVAILABLE to SCS, so that it will move to backup mode. This behavior is to make sure dial plan resolution is available all the time and not affected by network disruptions.
SIP Server will start the switchover process after the timeout defined by "time-before-switchover-on-xs-oos". This timeout in seconds, is used to avoid switchover on short disconnection of FS URL.
Once a XS request for dial plan is created, a timer will be started with value set by option "xs-request-timeout". If no response is received within this timeout, the request will be rejected immediately with "503 Service Unavailable".
Heartbeat requests will be sent to a FS URL according to the interval set, irrespective of the URL already having a dial plan request to process. Previously, a heartbeat will be sent only when there is no dial plan request to be sent.
All the above features can be enabled by setting the option "enable-enhanced-dialplan-handling" to true in the Extended Services VOIP Service DN.
---
Configuration Options
enable-enhanced-dialplan-handling
CME object SIP Server Application (Standalone SIP Server)
VOIP Service DN with service-type=sip-cluster-nodes (SIP Cluster)
Section TServer
enable-enhanced-dialplan-handling
Default Value: false Valid Values true, false Changes Take Effect: Immediately
Option defines whether the dial plan request enhanced handling feature should be enabled or not.
This includes:
Handling various error codes sent as response from Feature Server Retry XS requests once, on recoverable error responses from Feature Server Use a separate timeout 'xs-request-timeout' for each dial plan request, before which a response is expected. An option to configure timeout specific to the heartbeat requests xs-heartbeat-timeout Marking the URL as offline on heartbeat failures based on threshold set by xs-missed-heartbeat-threshold Reject any XS request or Switchover SIP Server to Backup mode, when no active Feature Server connection exists, based on option switchover-on-xs-oos
xs-request-timeout
VOIP Service DN with service-type=extended
Section TServer
Default Value: 8 Valid Values" 4-32 Changes Take Effect: For the next XS dial plan request
Option defines timeout for XS dial plan request to receive a response in seconds. Timeout starts when XS request is added to the queue and stops when response is received from Feature Server.
On timeout, the request will be rejected with corresponding reason for failure. Request timeout should be set atleast as twice as the post timeout option.
xs-post-timeout VOIP Service DN with service-type=extended Section TServer
Default Value: 4 Valid value: 2-16 Changes take effect: For the next XS dial plan request
Option defines timeout for XS dial plan request in transit in seconds. Timeout starts when XS request is send out and stops when response is received from Feature Server.
On timeout, the request will be either retried with alternate URL or rejected with corresponding error, if retry limit(1) has exceeded.
Post timeout should be set atmost as half as the request timeout option.