When a call is being directed by Lotus Sametime Unified Telephony to a SIP gateway for routing into the PSTN, the most common reason for a call rejection is congestion at the PSTN interface (all trunks busy).
Calls may also be rejected due to the following:
Processor overload conditions in the gateway
Partial gateway system failures
Other maintenance problems
In version 2.1, a rerouting option was provided in the case where the first choice gateway rejects the outgoing call request for any reason.
When gateways reject offered SIP phone calls, they do so by returning a SIP response code (an error code in the range 1xx – 6xx) indicating the reason for the rejection. Unfortunately, there are many possible response codes, and little consistency on their use among the many third-party SIP gateways that may interface to a softswitch such as Lotus Sametime Unified Telephony.
Therefore, the list of response codes that can be used to trigger a call rerouting action can be configured for special customer configurations. The initial (default) list of actionable codes is defined in the resilient telco platform (RTP) parameter file SrxSip.parm. Changes to the lists in this file are possible via CLI or by direct editing of the file, but should only be attempted by system experts, following standard MOP procedures. The response codes listed in the table below will, by default cause a gateway to attempt rerouting.
Table 1. SIP Response Codes That Cause Rerouting
|400||Bad Request||483||Too Many Hops|
|403||Forbidden||488||Not Acceptable Here|
|405||Method Not Allowed||493||Undecipherable|
|406||Not Acceptable||500||Server Internal Error|
|408||Request Timeout||501||Not Implemented|
|413||Request Entity Too Large||502||Bad Gateway|
|414||Request-URI Too Long||503||Service Unavailable|
|416||Unsupported URI Scheme||504||Server Time-out|
|420||Bad Extension||505||Version Not Supported|
|423||Interval Too Brief||513||Message Too Large|
|480||Temporarily Unavailable||580||Precondition Failure|
|481||Call/Transaction Does Not Exist||606||Not Acceptable|
In addition, if a SIP gateway is detected to have become unresponsive because an outgoing call to it timed out, the gateway is marked as inaccessible and no calls are routed to it anymore. Prior to the gateway becoming active again, calls will be offered to the next provisioned route. An audit of the defective gateway is started in order to detect the gateway becoming active again. When the audit is successful, calls can then be routed to the gateway again.
In order for intelligent gateway rerouting to occur, the craftsperson must enable the following SIP systemwide features:
Rerouting for SIP endpoints
A provisionable audit interval time can be set by the craftsperson. Audits are regularly scheduled to all unresponsive gateways.
A detected unresponsive route is also selected for outgoing calls again after an incoming call of the route and a subsequent immediate audit.
Parent topic: CAC (Call Admission Control) Rerouting