CUCM Failover Incoming Calls

[jefferymitchell]

Can someone help me understand the call path when we test a call manager subscriber failover, and there is an external incoming call to the site where the Call Manager Subscriber is down? We have a Multisite Deployment with Distributed Call Processing. All sites are connected via Cox Metro-E WAN. Our publisher along with a subscriber reside at site "A". Site "B" has its own subscriber. Site "C" has its own subscriber. Each site has its own gateway for external calls (ISDN PRI) to CenturyLink our phone carrier. We tested CUCM failover at site "B". Our configuration is set to have the subscriber at site "A" as the backup to site "B".  The phones at site "B" registered as configured to the subscriber at site "A". We were able to make external call from a phone located at site"B" no problem. But when we tried to call from an external source, my cellphone which Verizon is my carrier, The call would not connect. I received the following message from carrier " This number is no longer in services or has been disconnected". Also consider that our carrier routes calls to each of our sites based on a particular range of our assigned DNs. So the call was routed by the PSTN, based on DN to the gateway at site "B". Here is where I need clarification to troubleshoot this issue. Correct me if I'm wrong here. Call path:

Verizon Cellular  > CenturyLink (PSTN) > Site "B" Gateway > Site "B" Core Router > WAN > Site "A" Core Router > Site "A" CUCM Subscriber >

Site "A" Core Router > WAN > Site "B" Core Router > Phone at Site "B". 

I have uploaded  the failover debug and the non-failover debug. The failover txt file also has the config for the gateway.

[Brandon Buffin]

Gateways are H.323? You would need outbound dial peers on each gateway to point to the failover subscriber such as:

dial-peer voice 1 voip
preference 1
destination-pattern ....
session target ipv4:1.1.1.1
codec g711ulaw

dial-peer voice 2 voip
preference 2
destination-pattern ....
session target ipv4:2.2.2.2
codec g711ulaw

Brandon

[jefferymitchell]

Thanks for your reply. Yes that is configured on the Gateway located at site"B".

[nithin mulley · Accepted solution]

Can you take out the same traces again for the failover call what you did for non-failover? ( for the ISDN debug, dont go for detail)

Not sure you can do the failover test again, but can you can do this for a short time during off-business hours. Try removing the voip dial-peer going to Site-B Subscriber, make test calls and take the traces.

A wild guess, Do you have both A-Site and B-Site subscribers in the Call manager group which is on the Device Pool which is assigned to the H323 Gateway of Site-B?

Nithin M

[jefferymitchell]

Nithin,

Yes, see call manager group setting attached below. Would the fact that the call came in to the gateway at site"B" and the subscriber at Site "A" is doing the call setup, how does the reverse path affect the call to route back to the gateway where the call came in?

[pankajbhosale]

Hi,

In case of failover

Call flow for outgoing pstn call

Site B phone---->sub site A---->pub site B--->gateway site B----->PSTN

Call flow for incoming pstn calls from gateway B

PSTN----->pub site B------->sub site A------>site B phones

Sub site A is not able to find phones on site B can be a routing problem

Bye

[jefferymitchell]

Thanks for your reply. I saw that the sub at site A registered the phones at site b. A phone at Site b was able to make an outbound call. It was when I tested calling from my cellphone, external incoming call is what failed. Interestingly  you mentioned here with the call flow that the publisher is involved. I tested this same type of call with the publisher as the failover cucm and the call was successful. I now believe that I have to use the publisher as the secondary cucm not the subscriber. What is your accessment?

[nithin mulley]

Jeffery,

For this scenario, PUB as failover is not mandatory. There can be other reasons here with why PUB works and not SUB. More logs as I asked before would be a start.

"Can you take out the same traces again for the failover call what you did for non-failover? ( for the ISDN debug, dont go for detail)"

Also, yours would not be a Multisite Deployment with Distributed Call Processing, its simply Clustering over WAN and I beg to differ with Pankaj's understanding of a PUB at Site B in his flowchart.

[jefferymitchell]

Doing maintenance tonight I'll let you know when I gather debugs.

[jefferymitchell]

The H225 timeout was.causing inbound calls to drop. See thread below for explanation 

https://supportforums.cisco.com/discussion/11624151/h225-timer-command-difference

Thank you all for your response.

[nithin mulley]

Glad you figured it out! Enjoy your weekend!