Table Of Contents
VoIP Gatekeeper Trunk and Carrier Based Routing Enhancements
Wholesale Voice Network Scenario
Call Routing on the Gatekeeper
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring Additional Gatekeeper Capabilities
Verifying the Gatekeeper Configuration
VoIP Gatekeeper Trunk and Carrier Based Routing Enhancements
Feature History
This feature module describes the VoIP Gatekeeper Trunk and Carrier Based Routing Enhancements feature functionality in Cisco IOS Release 12.2(11)T, and includes the following sections:
•
Supported Standards, MIBs, and RFCs
For information about routing enhancements on the gateway, refer to VoIP Gateway Trunk and Carrier Based Routing Enhancements.
Feature Overview
Wholesale voice is a service that interconnects two H.323 Voice over IP (VoIP) service providers to complete a call. The VoIP Gatekeeper Trunk and Carrier Based Routing Enhancements feature enables the H.323 gatekeeper to collect information about the PSTN-side interfaces and the call capacity statistics for those interfaces on a per-call basis from the H.323 gateway and endpoint. This feature also enables the H.323 gateway to report the PSTN-side interfaces for incoming and outgoing calls to the H.323 gatekeeper to help in routing decisions.
The intent of this feature is to accomplish the following:
•
Note
•
•
Figure 1 shows the main components of a carrier-sensitive routing network.
Figure 1 General Trunk and Carrier Based Routing Network
As shown in Figure 1, the network has three main components:
•
Note
•
This feature enhances the gatekeeper with the following software capabilities:
–
–
–
•
This feature enhances the call detail report (CDR) with these software capabilities:
–
The next section, Wholesale Voice Network Scenario, describes the network configuration that incorporates these features. See Call Routing for more detailed descriptions of the new routing functions on the gateways, gatekeepers, and GKTMP server application.
Wholesale Voice Network Scenario
Wholesale voice providers offer call routing services across various types of customer networks. Customers with time-division multiplexing (TDM) transit networks can use gatekeeper trunk and carrier based routing.
In a TDM transit network, customers purchase minutes from the wholesale provider and send the traffic through a set of ingress trunks. Each trunk is assigned to a particular customer. The provider also arranges for a set of carriers or partners to terminate the calls. The wholesale provider's task is to route the calls efficiently and profitably from ingress to egress. Figure 2 illustrates this arrangement.
Figure 2 TDM Transit Network
In this scenario, carriers A, B, and C are ingress carriers with their assigned trunk and carriers B and D are egress carriers with their assigned trunks. Carrier B acts as both a customer and vendor to the wholesale provider.
A PSTN call arrives from an ingress carrier to the provider's gateway. The gateway alerts its gatekeeper that it has a call and needs routing information. The gatekeeper contacts the GKTMP server application gatekeeper, also referred to as a directory gatekeeper, with this request. The directory gatekeeper requests the GKTMP server application for the appropriate routing path and sends that data back to the ingress gatekeeper, who forwards the routing data to the ingress s gateway. The gateway sends the call to the egress gateway, which routes the call across the designated PSTN circuit.
Call Routing
A typical GKTMP server application is hosted over a local zone (leaf) gatekeeper or a directory gatekeeper.
A zone gatekeeper host triggers the GKTMP server application after receiving an admission request (ARQ) and typically requires connection to a local operations support system (OSS) for accurate tracking of current calls. The call routing process is shown in Figure 3.
A directory gatekeeper host connects to a global OSS and triggers the GKTMP server application after receiving an inbound location request (LRQ), as shown in Figure 4. All calls, whether from local or remote zones, pass through the directory gatekeeper, making call routing more efficient.
Figure 3 Call Routing Process for a Zone Gatekeeper
The following table explains the steps in the zone gatekeeper call routing process. For clarity, assume the calling party (ANI) is 1234 and the called party (DNIS) is 5678. Groups A, B, and C have circuit identifiers GroupA, GroupB, and GroupC, respectively. (Circuit identifiers represent trunk group labels or carrier IDs.)
1. The circuit identifiers are registered with the gatekeeper using RRQ messages.
The ingress gateway GWIN registers circuit identifiers GroupA and GroupB and the egress gateway GWOUT registers circuit identifiers GroupB and GroupC.
2. The call comes in to the gateway.
The call arrives at GWIN on GroupA. ANI = 1234 and DNIS = 5678.
Note
3. ARQ
The GWIN sends an ARQ message to the gatekeeper containing:
•
•
•
•
4. GKTMP Request
REQUEST-ARQ
The gatekeeper sends a GKTMP Request message to the GKTMP server application containing:
•
•
•
•
5. GKTMP Response
RESPONSE-ARQ
The GKTMP server application searches its databases for the appropriate route and returns a GKTMP Response message to the gatekeeper containing:
•
•
•
•
6. ACF
The gatekeeper sends an ACF message to the GWIN containing:
•
•
•
7. H.225 Setup
The gateway sends a Setup message to the GWOUT containing:
•
•
•
•
8. ARQ
The GWOUT sends a verifying ARQ message to the gatekeeper containing:
•
•
•
•
•
9. ACF
The gatekeeper sends an ACF message back to the GWOUT.
10. The call goes out the destination gateway.
The GWOUT sends the call out on GroupC.
Figure 4 Call Routing Process for a Directory Gatekeeper
The following table explains the steps in the directory gatekeeper call routing process. For clarity, assume the calling party (ANI) is 1234 and the called party (DNIS) is 5678. Groups A, B, and C have circuit identifiers GroupA, GroupB, and GroupC, respectively. (Circuit identifiers represent trunk group labels or carrier IDs.)
Call Routing on the Gateway
The gateway receives calls on the PSTN side through a single voice port interface (DS-0) or a logical group of physical interfaces (DS-0 or DS-1) called a trunk group. This feature allows you to route calls using trunk group identifiers or by carrier identifiers in addition to existing routing mechanisms. To route by carriers, you create the trunk groups and specify an identifier or descriptor to represent a carrier on those trunk groups. A carrier can have several trunk groups assigned to it.
Note
After receiving the routing information in the admission confirm (ACF) message from the gatekeeper, the gateway sends the call to the next gateway.
Registering with the Gatekeeper
For each carrier assigned to it, the gateway sends to its gatekeeper the carrier ID, the maximum number of calls the carrier can handle, and the number of currently available calls on the carrier. The gatekeeper and the GKTMP server application use this data to determine an appropriate route for an incoming call.
This feature also allows call routing using the trunk groups configured on the gateway without assigning the trunk groups to carriers. The gateway sends the call capacity information for each trunk group to the gatekeeper for route processing. Trunk group routing requires that all trunk groups on a gateway be identified using a trunk group identifier rather than a carrier identifier.
Note
Identifiers
In this document, circuit identifier refers to either a trunk group identifier or a carrier identifier.
A source circuit identifier specifies the trunk group or carrier sending the incoming PSTN call or the service provider sending an incoming VoIP call. The gateway sends this source circuit identifier, the calling party (ANI), and the called party number (DNIS) to the gatekeeper in the admission request (ARQ) RAS message.
If the gatekeeper and gateways are configured for the use of inter-zone clearToken (IZCT), the RAS, ACF, LRQ, LCF, and the H.225.0 Setup messages will include the IZCT, which consists of the circuit identifiers for the call.
Call Routing on the Gatekeeper
Receiving a Call Request
The gatekeeper receives source circuit identifiers from the gateway for the originating call, derived from the voice interface (DS-0). Gateways send this information as part of the ARQ message.
For Cisco gateways running a Cisco IOS version prior to this release and non-Cisco gateways that cannot send circuit identifiers, this feature provides the gatekeeper with a CLI command (endpoint circuit-id h323id) that assigns a circuit identifier to the gateway. Using this command restricts the gateway to the specified circuit. Similarly, for VoIP calls coming to the gatekeeper from a non-Cisco gatekeeper and not from a gateway, this feature provides the gatekeeper with the zone circuit-id command that associates a circuit identifier to the zone and an IP address of the call origination.
Processing the Call Request
Once the gatekeeper receives the source circuit identifier, the ANI number, and the DNIS number, it works with the GKTMP server application to determined the destination circuit identifier, which specifies the PSTN or service provider resource to be used for the outgoing call.
The gatekeeper sends a GKTMP message to the GKTMP server application with the ARQ data. The GKTMP server application searches its databases for an one or more egress circuits, and sends the destination circuit identifier back to the gatekeeper in a RESPONSE ARQ message.
If zones are used in the network, the GKTMP server application may determine that the egress circuit is in another zone. In that case, GKTMP server sends back a remote zone list with the RESPONSE ARQ message.
The gatekeeper uses the destination circuit identifiers and any zone lists to locate an available egress gateway for the call. The gatekeeper checks local gateways first. If none are available and GKTMP server sent remote zones, the gatekeeper sends a location request (LRQ) message to the gatekeeper in each zone on the list to find an available gateway. The LRQs are sent in sequential order and the circuits are sorted in priority order. A gatekeeper with an available egress gateway sends back an acknowledge confirmed (ACF) message to the original gatekeeper.
When a gatekeeper receives an LRQ, it tries to find an egress gateway that supports the circuit identifier. If the LRQ does not include any destination circuit information, the gateway uses the zone definitions and technology prefixes (identifiers for gateways in a zone) to determine an egress circuit. If the gatekeeper must return an LRQ in response to the received LRQ, lrq forward-queries must be enabled in its configuration.
Returning a Destination Endpoint
After finding an available egress gateway, the gatekeeper sends this information to the originating gateway in the admission confirm (ACF) RAS message.
If the IZCT functionality is enabled, the gatekeeper includes an IZCT with the source, destination, and intermediate circuit identifiers. If the egress gateway is in a remote zone with the IZCT functionality enabled, the gatekeeper includes a destination zone in the IZCT as well. The intermediate circuit identifier specifies the carrier or trunk group of the gateway in the next zone to handle the call. The gatekeeper also sends IZCTs for any alternate endpoints.
Carrier-Based Routing Without a GKTMP Application Server
Carrier-based routing is possible without the presence of the GKTMP application server, if you have Cisco IOS Release 12.3(8)T1, Cisco IOS Release 12.3(11)T, or higher. The trunk group label or carrier ID of the terminating gateway can also be provided by the destination circuitInfo field in ARQ. Incoming ARQ to the gatekeeper has the destination circuitInfo field. When both GKTMP and incoming ARQ provide the trunk group ID or carrier ID, the ID provided by the GKTMP server is accepted. The GKTMP server can also add, modify, or delete the trunk group ID or carrier ID present in ARQ using a RESPONSE ARQ or ACF message. If the RESPONSE ARQ or the ACF message does not include a trunk group label (Q tag) or carrier ID (J tag), only the Q tag or the J tag provided by the incoming ARQ is used for routing.
GKTMP Server Call Routing
Note
The GKTMP server application works in conjunction with a Cisco IOS gatekeeper. The GKTMP server and the gatekeeper communicate using GKTMP protocol. When the gatekeeper sends the GKTMP server an ARQ or LRQ request message, the message is formatted into the GKTMP format before the GKTMP server application processes it. Similarly, the GKTMP server application returns its search results, called response messages, in GKTMP format. The gatekeeper uses these response messages to proceed further with the routing decisions and send RAS response messages back to the gateway or to the next gatekeeper.
GKTMP server receives the source circuit identifier and called party (DNIS) information from the gatekeeper in the GKTMP message. The gatekeeper extracts the same information from the ARQ and LRQ messages or IZCT, as applicable. After searching its databases with user-defined rules, the GKTMP server returns the primary destination circuit identifier and a zone list, if needed, for the primary circuit and any secondary circuits that may be used for routing the call.
The GKTMP server application itself is a set of translation rules that determine the destination circuit identifier and optional zone lists. Each rule consists of a processing definition and data. Three types of rules are specified:
•
•
•
The user must provision the GKTMP server application with the following data:
•
•
•
•
•
•
The GKTMP server application has GUI commands for maintaining this network data.
Static Triggers
By default, the Cisco IOS gatekeeper does not forward any RAS messages to any external applications, such as the GKTMP server application. If an application is interested in receiving certain RAS messages, it must register this interest with the gatekeeper. To determine which RAS messages the gatekeeper forwards to the GKTMP server application, you can specify trigger parameters. If the gatekeeper receives a message that satisfies the specified trigger conditions, the message is forwarded to the GKTMP server application. If the message does not meet the trigger conditions, the gatekeeper processes the message according to its usual instructions, but the GKTMP server application does not receive that message.
If multiple trigger conditions are specified in a single registration message, the gatekeeper treats the trigger conditions as "OR" conditions. In other words, if a RAS message received by the gatekeeper meets any of the trigger conditions the message is sent to the GKTMP server application.
Trigger conditions are optional. If the gatekeeper receives a registration that contains no trigger conditions, the gatekeeper forwards all messages of the specified RAS message type to the GKTMP server application.
If the gatekeeper has a registration for a RAS message type and receives another registration for the same RAS message from the same GKTMP server with the same priority, the gatekeeper uses the new registration and discards the previous one. The gatekeeper allows registrations for the same RAS message type with the same priority from multiple servers.
To indicate that the external application is no longer interested in a message, it must unregister its interest. The contents of the unregistration message must match that of the corresponding registration message before the trigger can be removed.
A Cisco IOS gatekeeper can be statically (through a command-line interface) or dynamically (through the gatekeeper API) configured with trigger parameters.
Note
Benefits
GKTMP server call routing offers the following benefits.
Improves Call Routing Flexibility
Through the creation of profiles, call routing is more flexible and easier to implement than it was before.
Improves VoIP Interconnect Support
This feature provides the scalability of VoIP interconnections and eases the implementation and maintenance of the networks.
Provides a Common Architecture
This feature is based on Cisco's open architecture, which permits easier application development than proprietary environments.
Restrictions
The following restrictions apply to GKTMP server call routing.
Features Not Supported
•
•
Static Triggers
Carrier-sensitive routing (CSR) does not accept static trigger request (REQ) messages. CSR sets up the triggers dynamically.
Related Features and Technologies
•
•
Related Documents
General reference documents:
•
•
Feature documents:
•
•
Related Feature Documents
•
Platform Documents
•
•
•
•
Supported Platforms
•
•
•
•
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites
Complete these tasks before configuring the gatekeeper for trunk and carrier based routing enhancements feature functionality:
•
For more information on IP routing, refer to Cisco IOS IP Configuration Guide, Release 12.2
•
For more information on configuring voice ports, refer to Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
•
For more information on configuring Voice over IP, refer to Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
•
Refer to VoIP Gateway Trunk and Carrier Based Routing Enhancements for the details on configuring the trunks and dial peers on the gateway.
•
Refer to the GKTMP server documentation for information and procedures.
Configuration Tasks
See the following sections for configuration tasks for this routing feature. Each task in the list is identified as either required or optional.
•
•
•
Configuring the Gatekeeper
To configure the gatekeeper, follow these steps beginning in global configuration mode:
Configuring Additional Gatekeeper Capabilities
To configure the optional capabilities for the gatekeeper, follow these steps beginning in global configuration mode:
.
Verifying the Gatekeeper Configuration
Use the following commands to verify the gatekeeper configuration. See the command's reference page later in this document for sample output and its description.
•
gatekeeperzone local area1 alpha.com 172.18.193.39zone remote hatteras alpha.com 172.18.193.32 1718 foreign-domainzone cluster remote 387_cluster alpha.comelement planet 172.18.193.29 1719element hatteras 172.18.193.32 1719!zone cluster remote 319_cluster alpha.comelement planet 172.18.193.29 1719element newbridge 172.18.193.38 1719!zone prefix area1 319....zone prefix area1 387....zone circuit-id hatteras foreign-carriersecurity izct password mynamegw-type prefix 1#* default-technology gw ipaddr 172.18.138.69.1720lrq reject-unknown-circuitendpoint resource-threshold onset 95 abatement 75endpoint circuit-id h323id sales-gw-1 MAIN max-calls 1000server routing carrierserver registration-port 5055server flow-control onset 95 abatement 75 qcount 1000•
Router# show gatekeeper circuitsCircuit Endpoint Max Calls Avail Calls Resources Zone------- -------- --------- ----------- --------- ----MAIN Total Endpoints: 1sales-gw-1 1000 1000 Available•
Router# show gatekeeper endpoint circuitsGATEKEEPER ENDPOINT REGISTRATION================================CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags--------------- ----- --------------- ----- --------- ---- -----172.18.193.32 1720 172.18.195.69 54805 area1 VOIP-GWH323-ID: sales-gw-1Voice Caapcity Max.=1000 Avail.=1000Carrier: MAIN, Max Calls: 1000, Available: 1000Total number of active registrations = 1In the example above, the Voice Capacity Max. and Avail. values represent the total voice call capacity maximum and active calls for all carriers on the gateway.
The Carrier Max Calls and Available values represent the voice call capacity maximum and active calls for the specific carrier ID configured or registered by the gateway.
•
GATEKEEPER SERVERS STATUS=========================Gatekeeper Server listening port: 5055Gatekeeper Server timeout value: 30 (100ms)GateKeeper GKTMP version: 4.1Gatekeeper-ID: area1--------------------ARQ Priority: 1Server-ID:CSR01Server IP address: 172.18.197.220:59212Server type:dynamically registeredConnection Status: activeTrigger Information:Trigger unconditionallyServer Statistics:REQUEST ARQ Sent=1000RESPONSE ARQ Received=900RESPONSE ACF Received=60RESPONSE ARJ Received=30timeout Encountered=10Average response time(ms)=6Server Usable=TRUELRQ Priority: 1Server-ID:CSR01Server IP address:172.18.197.220:59212Server type:dynamically registeredConnection Status:activeTrigger Information:Trigger undonditionallyServer Statistics:REQUEST LRQ Sent=160RESPONSE LRQ Received=80RESPONSE LCF Received=20RESPONSE LRJ Received=30Timeout Encountered=30Average response time(ms)=6Server Usable=TRUE•
Router# debug gatekeeper server1w6d:GK TMSG encoded to writer bugger:REQUEST ARQVersion-id:401From:area1TO:CSR01Transaction-Id:815C9FB0000002D0Content-Length:168i=I:172.18.195.69:1720s=E:3870008 H:sales-gw-1d=E:3190008b=1280A=FC=B6E2A7F2-2883-11CC-8014-D7E9930F170Dc=B6E2A7F2-2883-11CC-8015-D7E9930F170Dm=TL=CarrierA1w6d: GK:processing server msg:RESPONSE ARQVersion-id:401From:CSR01To:area1Transaction-Id:815C9FB0000002D0Content-Length:46J={i:MAIN z:{r:I:172.18.193.22:1719 c:1 p:1))In this display, CarrierA represents the source carrier ID, MAIN is the destination carrier, and z{} is the destination zone override information.
Refer to theCisco Gatekeeper External Interface Reference, Version 3.2 for a description of the show gatekeeper server output fields.
Monitoring and Maintaining
Router# debug gatekeeper server
Displays all messages between the gatekeeper and external applications.
Router# show run
Displays the current gatekeeper configuration.
Configuration Examples
The following example illustrates the gatekeeper routing configuration. Dial peer configurations are done on the gateway(s) linked to the gatekeeper.
Router# show runCurrent configuration : 1889 bytes!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname main-ny!logging buffered 500000 debugging!memory-size iomem 20ip subnet-zero!interface Ethernet0/0ip address 172.18.193.39 255.255.255.0no ip route-cacheno ip mroute-cachehalf-duplexno cdp enable!interface Serial0/0no ip addressno ip mroute-cacheshutdownno fair-queue!interface Ethernet0/1no ip addressshutdownhalf-duplex!interface Serial0/1no ip addressshutdown!interface Serial0/2no ip addressshutdown!ip classlessip route 0.0.0.0 0.0.0.0 172.18.193.1ip route 0.0.0.0 0.0.0.0 172.18.193.0ip route 0.0.0.0 0.0.0.0 172.18.195.1ip route 10.2.0.0 255.255.255.0 Ethernet0/0no ip http serverip pim bidir-enable!!snmp-server packetsize 4096snmp-server enable traps tty!dial-peer cor custom!gatekeeperzone local main-ny alpha.com 172.18.193.39zone remote hatteras cisco.com 172.18.193.32 1718 foreign-domainzone cluster remote 387_cluster cisco.comelement planet 172.18.193.29 1719element hatteras 172.18.193.32 1719!zone cluster remote 319_cluster cisco.comelement planet 172.18.193.29 1719element goldengate 172.18.193.38 1719!zone prefix main-ny 319....zone prefix main-ny 387....zone circuit-id hatteras foreign-carriersecurity izct password mynamegw-type-prefix 1#* default-technology gw ipaddr 172.18.138.69 1720lrq reject-unknown-circuitendpoint resource-threshold onset 95 abatement 75endpoint circuit-id h323id sales-gw-1 MYTEL max-calls 1000server routing carrierserver registration-port 5055server flow-control onset 95 abatement 75 qcount 1000!!line con 0exec-timeout 0 0line aux 0line vty 0 4exec-timeout 0 0password labloginline vty 5 15login!!endCommand Reference
All commands used with this feature are documented in the Cisco IOS Voice Command Reference, Release 12.3.
Guest
