.NODE

CallManager and Gatekeepers

Gatekeepers can provide the same call routing and CAC functionality for CallManager. You can use gatekeepers with CallManager between CallManager clusters in a pure IP Telephony network or in hybrid networks with CallManager clusters and voice gateways that are interfacing to PBX systems.

Configuring a CallManager Gatekeeper Trunk

You can set up CallManager to use a gatekeeper as follows:

   

Step 1.

Define the gatekeeper to CallManager.

The only information that you need for this step is the IP address of the gatekeeper interface. Be sure that the Enable Device checkbox is also selected. An example is shown in Figure 17-3.


 

Figure 17-3. Defining a Gatekeeper to CallManager

 

Step 2.

Set up the actual trunk to the gatekeeper.

If your CallManager is running software version 3.2 or higher, Cisco recommends using H.225 gatekeeper-controlled trunks.

When you are configuring the trunk, you need to give it a unique name to be used to point traffic to the trunk in the next step. You also need to select the gatekeeper that you defined previously from a drop-down box. Add an appropriate technology prefix. You might want a different technology prefix for CallManager, because CallManager 4.0 and higher systems can handle both voice and video traffic. Always set the Terminal Type field to gateway for normal CAC.
 

   

Step 3.

Enter the zone name.

It is almost always desirable to have a different zone name for each CallManager cluster that is defined on the gatekeeper. This helps when configuring bandwidth management.

Figure 17-4 shows an example of setting up a gatekeeper trunk. Some of the items on the configuration screen are not related to the gatekeeper and are not shown in this example.


 

Figure 17-4. Defining a Gatekeeper Trunk on CallManager


At this point, the trunk should be registered to the gatekeeper and ready for use. You can verify this by using the show gatekeeper endpoints command on the gatekeeper, as shown in Example 17-13.


 

Example 17-13. Verifying CallManager Trunk Registration


 

[View full width]

GK_A#show gatekeeper endpoints GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags -------------- ----- ------------- ---- ---- ---- ---- ----- 10.1.5.2 56105 10.1.5.2 60570 ny VOIP-GW H323-ID: GK_Trunk_1 Voice Capacity Max.= Avail.= Current.= 0 10.12.1.2 1720 10.12.1.2 56783 miami VOIP-GW H323-ID: miami@cisco.com Voice Capacity Max.= Avail.= Current.= 0 10.1.5.200 1720 10.1.5.200 50240 boise VOIP-GW E164-ID: 0100 E164-ID: 0101 H323-ID: boise@cisco.com Voice Capacity Max.= Avail.= Current.= 0 Total number of active registrations = 3  

You can provide redundancy on the trunk by assigning up to three subscriber servers to the CallManager redundancy group that is associated with the device pool assigned to the trunk. This configuration causes all servers in the redundancy group to register with the gatekeeper. However, the H.323 trunk name that is used for the h323_id has a suffix of _n, where n is the node number of the CallManager server in the cluster. This ID is assigned automatically and cannot be changed.

This feature provides redundancy without adding administrative complexity. You configure a single trunk, but the gatekeeper registers multiple trunks, one from each subscriber in the CallManager redundancy group.
 
   

Step 4.

After you have created the trunk, set up CallManager to use the gatekeeper trunk for specific dialed numbers.

You can include the trunk in CallManager route groups, route lists, and route patterns. Figure 17-5 shows a typical CallManager route pattern configuration using the gatekeeper trunk GK_Trunk. Dialed numbers that match this pattern cause CallManager to issue an ARQ to the gatekeeper to resolve the destination gateway IP address for this call.


 

Figure 17-5. Associating a Route Pattern to the Gatekeeper Trunk


Cisco also recommends that you use the arq reject-unknown-prefix gatekeeper configuration command to prevent potential call routing loops that might occur across redundant CallManager trunks. If a called address does not match any of the known zone prefixes, the gatekeeper attempts to hairpin the call back through the originating gateway without arq reject-unknown-prefix configured. This action might cause loops in a CallManager environment with multiple trunks active to the gatekeeper.

CallManager does not support dynamic zone prefix registration. You must manually code zone prefixes on the gatekeeper for CallManager destinations.

You can verify proper operation and troubleshoot call routing problems in the same manner as with any registered H.323 gateway. CallManager uses the same RAS messaging format for call admission. For more information, see the "Troubleshooting Gatekeepers" section earlier in this chapter.
 

Gatekeeper Redundancy

Part I: Voice Gateways and Gatekeepers

Gateways and Gatekeepers

Part II: Gateways

Media Gateway Control Protocol

H.323

Session Initiation Protocol

Circuit Options

Connecting to the PSTN

Connecting to PBXs

Connecting to an IP WAN

Dial Plans

Digit Manipulation

Influencing Path Selection

Configuring Class of Restrictions

SRST and MGCP Gateway Fallback

DSP Resources

Using Tcl Scripts and VoiceXML

Part III: Gatekeepers

Deploying Gatekeepers

Gatekeeper Configuration

Part IV: IP-to-IP Gateways

Cisco Multiservice IP-to-IP Gateway

Appendix A. Answers to Chapter-Ending Review Questions

Index

show all menu





Cisco Voice Gateways and Gatekeepers
Cisco Voice Gateways and Gatekeepers
ISBN: 158705258X
EAN: 2147483647
Year: 2004
Pages: 218
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net