Call Manager cluster and voice gateway

jcarvalh · ‎05-05-2010

Hello.

I have a CM cluster with one subscriber and one publisher and I had this problem:

- the cluster is up and running (they are in diferent data centers)

- on a remote site the phones and voice gateway can only communicate (register) with subscriber

- publisher cannot communicate with voice gateway on remote site (because of BGP route propagation problems with our provider)

On this conditions, on the remote site I cannot make a call to the "outside" world. To revert the situation I had to use SRST.

Can someone give me an opinion on why this is happening?

All went ok when I got communications up between the remote site and the publisher.

Based on this it seams that the subscriber is not handeling the communications with the gateway because it sees the cluster as up.

Thanks in advance,

Joao Carvalho.

William Bell · ‎05-05-2010

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?

HTH.

Regards,

Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

jcarvalh · ‎05-05-2010

Hello.

During the outage both subscriber and publisher were able to communicate with each other.

Due to network problems the voice gateway could only communicate with the subscriver and also due to the same ntwork problems the publisher could not communicate with the voice gateway.

Because the cluster was up I believe that the publisher is the responsable to handle communication with the voice gateway however that was not possible because of the network problems.

Thanks,

Joao Carvalho.

P.S. - I check the H323 device pool and all is OK (not on default)

William Bell · ‎05-05-2010

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.

HTH.

Regards,

Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

jcarvalh · ‎05-05-2010

William,

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.

Thanks,

Joao Carvalho.

jcarvalh · ‎05-05-2010

Hello.

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.

Best regards,

Joao Carvalho

P.S. - don´t know why but on previous post some characters were bigger than others

P.S.1- the doc I read was... http://www.ciscosystems.org/en/US/products/sw/voicesw/ps556/products_configuration_example09186a0080094852.shtml

David Hailey · ‎05-05-2010

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...

Hailey

jcarvalh · ‎05-05-2010

Hello guys.

After a lot of troubleshooting I decided to start over and keep it simple.

The problem was with the IOS image on the voice gateway; I changed it made some tests and all works fine now

Thanks for your replies.

Best regards,

Joao Carvalho.