Gatekeeper does not properly refresh endpoint's avail./current circuits

Unanswered Question

Hi,


I am using C3640 with c3640-ix-mz.123-10b as a gatekeeper for several voice gw and ipipgw. All works great but gatekeeper has problem with properly refreshing information about one endpoint (7200VXR working as IPIPGW) current and available circuits. It leads to situation when gk see that endpoint as "out of resources" while this endpoint is almost free.

Some output:

---

sh gatekeeper endpoints circuits

GATEKEEPER ENDPOINT REGISTRATION

================================

CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags

--------------- ----- --------------- ----- --------- ---- -----

X.X.X.X 1720 X.X.X.X 58056 ZONE-1 VOIP-GW

H323-ID: AAA

Voice Capacity Max.= 120 Avail.= 120 Current.= 0

Y.Y.Y.Y 1720 Y.Y.Y.Y 55968 ZONE-1 H323-GW O

H323-ID: BBB

Voice Capacity Max.= 100000 Avail.= 0 Current.= 10952Carrier: cisco-default-h323-circuit, Max Calls: 3000, Available: 2934

Z.Z.Z.Z 1720 Z.Z.Z.Z 54639 ZONE-1 H323-GW

H323-ID: CCC

Voice Capacity Max.= 100000 Avail.= 96703 Current.= 3 Carrier: cisco-default-h323-circuit, Max Calls: 1200, Available: 1087

---


Legend:

Endpoint AAA is H323 gateway that works fine.

Endpoint BBB is ipipgw that has problems with circuits status refreshing (note flag 'O' in output) but calls number is displayed properly.

Endpoint CCC is properly working ipipgw.


Have you ever meet such problem?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
hadbou Wed, 12/19/2007 - 06:48
User Badges:
  • Bronze, 100 points or more

Symptom:

When registering a VoIP gateway to a Gatekeeper Cluster, calls through the alternate gatekeeper will fail when the primary becomes unavailable due to a hard reset. If a graceful shutdown if executed, calls are processed normally by this secondary gatekeeper.


Conditions:

This problem has been observed on a couple of Cisco 3640's running 12.3(15) and implementing Gatekeeper Clustering functionality (GUP)


Workaround:

There is no workaround. The problem might not be there if we implement HSRP, but this has not been tested.


Try BUG - CSCsb31842


Actions

This Discussion