I have a route group with 2 members, the first is a SIP trunk and the second one is a PRI line. The problem is, when a call is routed through the SIP trunk and for some reason the SIP gateway replies with "486 busy here" or "503 service unavailable", Callmanager (version 7.1) will drop the call instead of trying to route it through the second member of the route group (the PRI line). Is there any way to force CCM to always try the next route group member, when it receives a SIP 483 or 503 response? (setting "Stop Routing on User Busy Flag" to false under service parameters won't do the trick)
thanks in advance
Cisco Call Manager should route the call to the next device for all Cause Codes other than OutofBandWidth, UserBusy and Unallocated Number.
If you have collected the CM Traces, Try to check what was the Q931 Cause Code was released. If it was 17 cause Code
you can change the setting to false for "Stop routing on User busy Flag" under Service Parameter.
If in case you see a different Cause code, please share the same
I forgot to tell you that I had already tried these options, but without sucessful result.
I have all flags option in false, and still the call dont step to the other RG.
have you looked at the CM Traces. The cause 503/486 do you see in CDR or logs.
If you have logs. Can you share? Does the call reaches the SipGateway ?
I believe 483 and 503 are critical errors, and CUCM may not move to the next RG in line
|17||486||USER_BUSY||user busy [Q.850]||This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.|
|34||503||NORMAL_CIRCUIT_CONGESTION||no circuit/channel available [Q.850]||This cause indicates that there is no appropriate circuit/channel presently available to handle the call.|
Although there's a spirit from the SIP RFC to suggest the implementation to retry the call on other endpoint.
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server.
To know for sure we would need a CallManager Trace.
Just want to share my experience on this issue.
Once i have seen this problem and identified that CUCM itself had an issue communicating to gateway with 5060 port. At that time the CUCM did not route the call to the next device in the route list.