cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
947
Views
0
Helpful
8
Replies

Monitoring CUCM connection from 2951 voice gateway

grccadmin
Level 1
Level 1

I have two 2951 gateways configured at two different locations configured with H.323 trunks.  The phone company has the PRI setup so if the link to the first gateway is down, it will route the calls to the second gateway.  When there is a disruption in service to the network between the primary gateway and CUCM (10.6), the link to the phone company is up but the gateway has no communication to route calls anywhere, so calls are routed to the first gateway and callers eventually get a busy signal.  If I can find a way to shut down the PRI ports when CUCM is not available, that would force the inbound calls to the other gateway.  I've briefly looked into some of the SIP monitoring options which don't necessarily apply here, but not sure if that monitors the connection to CUCM or just the outbound SIP trunk.

Thanks,

Dan

1 Accepted Solution

Accepted Solutions

Vivek Batra
VIP Alumni
VIP Alumni

This is interesting one. Did some research and found the following, might be of your interest;

https://supportforums.cisco.com/discussion/11999406/isdn-pri-failover-voip-gateway

- Vivek

View solution in original post

8 Replies 8

Chris Deren
Hall of Fame
Hall of Fame

Dan,

Converting the H323 GW to SIP trunk would allow you to use SIP Options Ping feature which does exactly what you are looking for. 

If I'm understanding the SIP Options Ping feature correctly, it is a part of the dial-peer and only prevents the dial-peer from being used if the destination is unresponsive.  In essence, the service provider would still be able to connect to the gateway, but none of the dial-peers would be active perhaps resulting in a quicker busier signal.  I am attempting to actually shut down the connection to the ISDN PRI if the connection to CUCM is down.  I'm new at this though, so maybe I'm missing something.

Hi,

You can enable options ping on the SIP trunk as well as on the dial-peer on the gateway. Setting the options ping on the trunk would enable the CUCM to send options ping to the gateway, if the gateway is unresponsive then CUCM will take the trunk out of service.

https://supportforums.cisco.com/document/12692696/how-enable-sip-options-ping-feature-sip-trunk

Aseem

Is it possible to shut down a different trunk than the one being monitored?  I've attached a picture which better explains what I am trying to accomplish.

Hi,

There is no way to shut down a trunk. To test failover at trunk level you can create two Route groups each containing one trunk, so RG1 has trunk 1 and RG2 has trunk 2. When the primary trunk is unable to ping the gateway 1 then CUCM will mark it Out of service and will route the call from second trunk in second route group.

For incoming calls to the gateway, if the gateway 1 is not able to reach CUCM because of options ping it will mark the dial-peer out of service and for redundancy you can configure a second dial-peer to gateway 2. Make sure you assign preference 1 to the secondary dial-peer to 2nd VG.

I am not sure if i understand the meaning of "Is it possible to shut down a different trunk than the one being monitored? " but if you want to test failover you can create two route groups each containing one trunk and then on trunk 1 you can assign a dummy IP address in the destination pattern. Since the IP address in the trunk 1 will not be pingable therefore for CUCM trunk 1 will be OOS and call will route from trunk 2.

Let me know if this answers your query.

Aseem

Dear grccadmin,

Did you try what is suggested by Vivek Batra about using the event manager applet to shut down and bring back the interface.

Alternatively you can ask provider to use Gateway-2 as secondary such that only if gateway-1 is full call will flow to gateway-2. 

Thanks

Haris

Vivek Batra
VIP Alumni
VIP Alumni

This is interesting one. Did some research and found the following, might be of your interest;

https://supportforums.cisco.com/discussion/11999406/isdn-pri-failover-voip-gateway

- Vivek

It looks like using the IP SLA and event monitoring should accomplish the goal.  I'll test it out and post the results.