My current environment has 2 Cisco 3945 CUBEs that each have a SIP connection to our provider, Windstream. We use a Session Manager Edition (SME) of CallManager (version 9.1.2) to connect to these two 3945’s using two SIP trunks. The two SIP trunks are in a Route Group together.
Last week Windstream had a routing issue where their SBC could not route back (IP routing) to one of our 3945’s. A “debug ccsip messages” trace showed that the 3945 was sending three SIP invites (fairly quickly) to their SBC and not getting anything in return. After those three invites, it sent a SIP 408 (Request Timeout) back to SME.
It appears that at that point SME was returning a busy signal to the user, rather than moving on to the other SIP trunk in the Route Group (which was working). My questions are:
1. 1. Is that the actual default behavior of a CallManager Cluster (upon receiving a SIP 408 to not try to continue routing the call via other SIP trunks)? I’m wondering if this is specific to something in our config or if possibly we were hitting a timeout issue?
2. 2. Is it possible to configure CallManager/SME to try to continue routing (to the next option in the Route Group or move onto the next Route Group in the Route List) in order to connect the call in this scenario?
You need to enable SIP Options Ping , check the following section on SIP profile configuration:
Check this check box if you want to enable the SIP OPTIONS feature. SIP OPTIONS are requests to the configured destination address on the SIP trunk. If the remote SIP device fails to respond or sends back a SIP error response such as 503 Service Unavailable or 408 Timeout, Cisco Unified Communications Manager tries to reroute the calls by using other trunks or by using a different address.
If this check box is not checked, the SIP trunk does not track the status of SIP trunk destinations.
When this check box is checked, you can configure two request timers.
- Do rate helpful posts -
Thanks for the reply. In the CallManager "SIP Profile Configuration" I do have the "Enable OPTIONS Ping to monitor destination status for Trunks with Service Type "None (Default)"" box checked, so I believe Options Ping is running between the SME and my 3945's.
I think the problem is the 3945's were responding to the Options Ping from SME, since they were up and running.
Perhaps I need Options Ping enabled with Windstream (if they support it)? In this case the ping surely would have failed...though I'm not sure this would have solved my issue??
Thanks - Rob.
I don't think that's going to help - the user isn't busy...my 3945 can't communicate with my provider via SIP and sends a 408 (Request Timeout) back to SME. At that point SME does not think the number is busy, however it does stop routing and, because it stops routing, returns a busy signal to the user.
Thanks - Rob.
I agree its worth a try, unfortunately SME is servicing three clusters and over 40,000 endpoints, so I can't test changing that parameter - it would affect several other things.
Try to schedule an outage window for testing. If you have a test CUCM, you can point your CUBE to it for a specific called number (test number) and test the parameter.
The parameter you should be changing is the "Stop Routing on Unallocated Number Flag" to false.This option is what allows the call to keep routing to other RGs within a RL. Also you can configure the "voice class sip options-keepalive" on the dial-peer to monitor the status of Winstream.
Thanks for the reply but "Stop Routing on Unallocated Number Flag" already is set to false. The reason this does not help my situation is SME is not receiving a response of Unallocated Number, it is receiving a 408 timeout. At times SME will receive an Unallocated Number response from one of our leaf clusters and at that point it does continue routing, but this is a different scenario.
I will definitely investigate "voice class sip options-keepalive" - thanks!