I have the same question. My route list contains a SIP trunk first, and then an H323 gateway. I can pull the ethernet cables out of the server on the other end of the SIP trunk, and Call Manager (7.0.2) still tries to send calls out the SIP trunk. It doesn't see that the trunk is failed, and the route list never goes to the second route group (H323).
The only time I can get CUCM to see that the SIP trunk is no good, is when I reset the trunk from CUCM Admin. For a brief period, calls go to the the second route group (H323) and then after the SIP trunk completes its reset, CUCM sends calls out to that trunk again, even tho it's still no good.
Anybody know how to teach Call Manager that the trunk is down?
Additionally on CUBE you have support for the OOD Options Ping to "keepalive" the L7 status (L3 mechanisms like ICMP ping are also available) of the SIP peer and busy out dial-peers (routes) if the SIP peer is not responding. More info at
The trunk is not to a Service Provider. It's a 3rd-party IVR box in the same room connected to the same switch. We just want to detect a call connect failure in the IVR system and ring hard phones when that happens. The reason we're going thru H323 to get back to CUCM is because you can't put a Hunt Group (or Pickup Group, etc) onto a Route List.
I think the key on why you ought to use a CUBE is in what javalenc said above:
Additionally on CUBE you have support for the OOD Options Ping to "keepalive" the L7 status (L3 mechanisms like ICMP ping are also available) of the SIP peer and busy out dial-peers (routes) if the SIP peer is not responding.
Since CUCM doesn't natively have that, either insure your SIP destination is 100% reliable, or you're Out Of Luck.
Thanks. And how I wish we could go that route. It would have fixed earlier issues with the 3rd-party IVR software's non 2.0 compliance, such as ignoring REFRESH and UPDATE (which they fixed with their new release of this month).
Although CUBE would be the ideal, I was really hoping to be able to adjust timers somewhere, so that when an individual call fails, CUCM would know it and go to the next option.
I don't know how adding a CUBE in between would solve the original problem ( I am not arguing that we should not have a CUBE). Assuming you run SIP trunk between CUCM and CUBE, and another SIP trunk between CUBE and ITSP, how can CUCM detect the SIP trunk between CUBE and ITSP is down?
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...