Currently we have two SIP trunks to different providers. These tunks reside in two Route Groups, which, in turn, are included into Route List.
The problem is, when we receive 503 error from first trunk, the call routing stops and CUCM does not try to send failed call to the second trunk. As far as I uderstand, this is default behaviour of CUCM. Is it possible to override this?
Set these service parameters to FALSE:
Stop Routing on Unallocated Number Flag
Stop Routing on User Busy Flag
HTH, please rata ll usful posts!
Unallocated Number Flag is 404 and User Busy Flag is 486, so changing these settings will not affect my case.
No, because they are unrelated to my situation.
Let me explain:
Stop Routing on Unallocated Number Flag:
When the parameter is set to True and a call that is being routed to a remote Cisco cluster through a route list is released by a remote Cisco CallManager because of the unallocated number, a local Cisco CallManager will stop routing the call to a next device in the route list. When the parameter is set to False, the local Cisco CallManager will route the call to the next device. SIP message for Unallocated Number is "SIP/2.0 404 Not Found"
Stop Routing on User Busy Flag:
When the parameter is set to True and a call that is being routed to a remote Cisco cluster through a route list is released by a remote Cisco CallManager because a remote user (phone) is busy, a local Cisco CallManager will stop routing the call to the next device in the route list. When the parameter is set to False, the local Cisco CallManager will route the call to the next device. SIP message for User Busy is "SIP/2.0 486 User Busy"
In my case I receive "SIP/2.0 503 Service Unavailable" message from trunk, that's why turning these setting to True will not help in my situation.
We are working with mature, well-documented product. When documentation says: "Changing parameter "A" will affect behaviour "B"", it does not mean, that setting this parameter will affect also behaviour "X". I hope, you understand my idea. It's somewhat like trying to cure headache by using plaster bandage on the leg.
Moreower, setting "Stop Routing on User Busy Flag" to False will increase unwanted trunk usage. When remote user is busy, we must try to call them later, but not right now, just using another trunk.
OK, if you say so.
Note, I set those parameters to FALSE on every deployment I have done this since CM 3.1 days and it always resolves the issue you are describing for various trunk types. Obviously SIP trunks are slightly different and I'll admit I never played with togging this parameter to True when I've deployed exactly what you are doing, but at the same time I never ran into this issue with it being set to False. In addition I never deployed SIP provider connection without CUBE and would never recommend that to anyone (for many reasons beyond the scope of this thread).
Well, it seems, I finally found the root cause of such behaviour.
In document http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a03rp.html (It is for 8.6, but older documents are similar) is stated following about rerouting:
When the system initially presents a call to a member of a route list, Cisco Unified Communications Manager reroutes for all cause codes other than Out of Bandwidth, User Busy, and Unallocated Number. The value of the associated service parameters for the Cisco CallManager service determines the rerouting decision for those cause codes. The Clusterwide Parameters (Route Plan) grouping includes the Stop Routing on Out of Bandwidth Flag, Stop Routing on User Busy Flag, and Stop Routing on Unallocated Number Flag service parameters. You can set each service parameter to True or False.
After a route list locks onto a trunk, no rerouting occurs. The media connect time of the endpoints and the Stop Routing service parameters determine when a route list stops hunting for the next route group. When media negotiation begins, the route list or hunt list loses the ability to reroute.
Since my trunks have "MTP requred" checked, the media path is established at the first stage of SIP negotiation. This blocks the ability to reroute.