I would agree that the issue is that your publisher could not communicate with the gateway. From an egress (i.e. offnet) calling perspective, this boils down to the call manager group that is associated with the device.
With h323, check the Device Pool association. With MGCP, you need to check two things. First, check the Device Pool association on the MGCP endpoint (e.g. pri) in question. Second, each MGCP gateway (the config page where you see the mgcp endpoints you can select) has a Call Manager group assigned locally/globally? to the gateway. A lot of folks forget this and usually leave it at "Default". The Default call manager group uses the publisher.
A SIP trunk would be similar to a H323 gateway with respect to device pool assignment.
I would check the above first. Also, during this outage was the publisher able to communicate with the subscriber?
OK. The publisher plays no special role in the gateway communication. Meaning, if configured correctly you would be able to shutdown you publisher and calls should flow in/out of the gateway just fine.
So, you checked the voice gateway device pool association and verified that it has a Call Manager group that contains both the subscriber and publisher (order really isn't pertinent to this issue).
The next thing I would check are your Route Lists. Route Lists are also assigned a Call Manager group. Which means a Route List "registers" to a call manager. Again, if you are using the default then the route list will use the publisher only. Which means that outbound calls would fail because route patterns point to route lists that aren't "registered". Just another place to check.
Oh, if you find the Route List/CM Group thing is an issue then you may want to check any Hunt Lists you have configured as well.
All seems to configured in the right way (verified everything you asked).
You mentioned that "you would be able to shutdown you publisher and calls should flow in/out of the gateway just fine"; the thing is that the publisher was not shutdown at least from the subscriber perspective. So my ideia is that the subscriver might ask the publisher to deal with these calls, and since there is no routing from the publisher to the gateway (ISP problem) signalling will never reach the voice gateway.
This routing problems sometimes occour on our network and I am trying to understand typical behavior of both publisher and subscriber on similar situations in order to prevent future issues.
Found this doc that states that "lower preference should be given to the subscriber because it is the Cisco CallManager server designated for call handling, while the publisher is designated to handle both the SQL database and the LDAP directory. "
According to this the subscriber handles all the calls; so it should have worked just fine. I will now go and verify all my configs...again.
Thanks once again.
P.S. - don´t know why but on previous post some characters were bigger than others
Bill is correct as you found in that document. Ideallly, the Publisher only does DB and Web services (usually TFTP too in many clusters) within the cluster. The Subscriber(s) should handle all call processing and hold the registrations for all phones and gateway devices. Let us know how your config scrub goes...
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...