health check to remote dial-peer on voice gateway

[johnyoon75]

Hello.

I hav a question about health check to remote dial-peer.

I have two pod in our VoIP Network, Pod-A and Pod-B.

I had configured dial-peer to make call remote peer on Pod-A gateway.

If pod-B's ethernet interface may be go down, Pod-A's gateway doesn't konw.

At this time, How can i configure to check remote gateway's ethernet ip address whether live or dead?

Regard,

john.

[venkekri]

Check this link. Should be able to answer your question.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801f3.html

Thanks

Venky

[johnyoon75]

hello.

i had configured about busyout under voice port.

if i shutdown opposite voice gateway, the local gateway's voice port didn't shutdown.

the configuration is below.

voice-port 1/1:15

busyout action shutdown

busyout monitor probe 192.168.1.2 codec g711ulaw

what's problem?

should i additional configured to opposite side gateway?

regard,

john.

[venkekri]

Hi John

Was not able to check the update till now.

Anyway i quickly configured the below commands

voice-port 1/2

busyout action graceful

busyout monitor probe

For me i used busyout monitor probe ethernet 0

I then shutdown the ethernet interface and did a

"show voice busyout " and it returned me the above port number as busyout.

So the point is that dont give the ip address of the remote gw's interface. This probing is local.

Regards

Venky

[johnyoon75]

Hello Venky.

That is not good news for me...

As you told me, the probe opton is limited local ip address...right?

Thank you for helping.

regard,

John.

[venkekri]

Hi John,

I have used the local probing and it has worked like a charm for me. However remote probing is also an option. However in that you need to make sure you configure the Fallback command.

check the below link for more and also look for PSTN fallback option in cco.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801f3.html#36619

Let me know how it goes.

Thanks

Venky

[teodorgeorgiev]

Hi Johny,

you have several workarounds:

1. If you change your call routing mode not to be direct "GW-GW signalling", but "gatekeeper routed signalling", then both Pod-A and Pod-B must be registered to a gatekeeper. If the Ethernet interface of Pod-B goes down, then it will be un-registered from the H.323 gatekeeper. And if at this time Pod-A sends a call for Pod-B, then it will be sent through the gatekeeper. The gatekeeper knows that the call can not be routed to Pod-B, because it is disconnected (not registered) and will either return a disconnect reason to Pod-A (+ARJ --> Admission Reject), or will try to route the call to another registered gateway/endpoint if its destination prefix matches the call number :)

2. I suppose that you want to know that the remote gateway is down, so to be able to route the call at Pod-A to another location (another voice gateway, or PSTN). In this case, just configure another dial-peer matching the same call pattern, but with higher preference (lower priority). Pod-A will try to place a call to Pod-B, if Pod-B does not reply to the H.323 Q.931 SETUP, then Pod-A will try to route the call to the secondary dial-peer.

Hope that helps.