|
|
A primary application for VoIP on the Cisco AS5800 is to provide a PSTN gateway for Internet telephone traffic. VoIP used as a PSTN gateway leverages the standardized use of H.323-based Internet telephony client applications as illustrated in "VoIP Used as a PSTN Gateway for Internet Telephone Traffic," below.
This section contains a brief description of the gateway and gatekeeper features required to implement the applications to run VoIP in a service provider environment. The features address the needs of the service provider to offer security, billing, scaling, and reliability.
The Cisco gateway functionality and gatekeeper functionality work in concert to provide the ITU-T H.323 infrastructure. Therefore, the two main components in the Cisco voice architecture that interoperate to enable the service provider feature set are:
Refer to "VoIP PSTN Signaling Architecture" section for a graphical description of the gateway and gatekeeper internetworking functionality.
Refer to "Gatekeeper and Gateway Internetworking Configuration" section for a description of how gateways and gatekeepers interoperate.
The gateway capability is the ability of the Cisco AS5800 to function as an H.323 endpoint. Therefore, the gateway provides: admission control, address lookup and translation, and accounting services.
User configuration and implementation of these features all takes place while setting up and configuring the gatekeeper and the gateway. See the "Gatekeeper and Gateway Internetworking Configuration" section.
Descriptions of each gateway feature are discussed in the following sections.
Registration, Admission, and Status (RAS) is the signaling function that performs registration, admissions, status, and disengage procedures between the VoIP gateway and gatekeeper.
Two new fields are added to the dial-peer entry to implement RAS
The technology prefix field is applicable to the dial-peer of the "voip" encapsulation type. This field is used to indicate to the gatekeeper the type of service that the outbound call is requesting. For a complete description of the technology prefix see the "Technology Prefixes" section.
The session target field of the VoIP dial-peer indicates the address of the remote gateway where the call is terminated. If the RAS protocol is used, the session target field is used to indicate that a gatekeeper needs to be consulted in order to translate an E.164 address to an IP address.
See the following example for dial peer configuration:
See the following example for Gatekeeper Discovery
See the following example forRAS State Machine
The Authentication, Authorization, and Accounting (AAA) feature represents features which are required in the VoIP gateway. The standard Cisco AAA accounting functionality is enhanced to collect digits during the call processing process, such as:
The AAA authentication feature permits RADIUS to be used to authenticate users (typically incoming calls) on the gateway. It is normally used with IVR to check the legitimacy of a prospective gateway user based on an account number (collected by IVR) or based on answer number identification (ANI).
Authentication is based on RADIUS and is performed on the gateway (as opposed to the gatekeeper).
User account and PIN information is collected by the IVR application and is passed to the AAA interface. The AAA interface then makes a RADIUS authentication request with the given information and returns to the IVR application with status of success or failure.
RADIUS is an IETF protocol based on UDP. It functions by exchanging a set of attribute/value pairs between the client, here a VoIP gateway and a RADIUS server. Standard RADIUS server implementations include CiscoSecure, Cisco UCP, and Merit.
An authenticated user is authorized. There is no authorization of specific user capabilities for the service provider voice applications.
Accounting uses a basic start-stop method and standard RADIUS attributes where possible. Attributes that cannot be mapped to standard RADIUS are packed into the Acct-Session-Id attribute field as '/' separated ASCII string.
Data items are collected for each call leg that gets created on the gateway. A call leg is the internal representation of a connection to the gateway. Each call that is made through the gateway consists of two call legs: an incoming and an outgoing call leg. The call leg information that is emitted by the gateway(s) can be correlated by their connection ID, which is the same for all call legs of a connection.
 | Caution If you are using H.323 accounting and are also using CiscoSecure NT, then CiscoSecure version 2.1.8.4 or higher is required. |
The standard RADIUS attributes supported are:
The nonstandard RADIUS attributes are packed into the Acct-Session-Id are:
To take advantage of standard RADIUS implementations that do not support vendor specific attributes, a new method is defined which embeds the unsupported information elements in the RADIUS Acct-Session-id. The Acct-Session-id field has a maximum length of 256 characters. It is defined to contain the RADIUS account session ID which is a unique identifier that links accounting records associated with the same login session for a user. The internal representation of this field is long. Therefore, the value of this Session ID can become very large as the number of sessions on a router increases.
In order to support additional fields, following string is the format for this field:
session id/<setup time>/<gateway id>/<call origin>/<call type>/<connection id>/<connect time>/disconnect time>/<disconnect cause>/<remote IP address>where:
| Field | Description |
|---|---|
session id | The standard RADIUS account session ID. |
setup time | The Q.931 setup time for this connection in NTP format. |
gateway id | The name of the underlying gateway. Name string is of form |
call origin | Indicates origin of the call relative to the gateway. Possible values are "originate" and "answer." |
call type | Indicates call leg type. Possible values are: "Telephony" and "VoIP." |
connection id | A unique global identifier used to correlate call legs that belong to the same end to end call. The field consists of 4 long words (128 bits). Each long word is displayed in hexadecimal value and separated by a space character. |
connect time | The Q.931 connect time for this call leg in NTP format. |
disconnect time | The Q.931 disconnect time for this call leg in NTP format. |
disconnect cause | Documented in Q.931 specification. Can be in the range of 1 to 160. |
remote IP address | Address of the remote gateway port where the call is connected. Note Support for remote IP address field was introduced with Cisco IOS Release 11.3(7)NA. |
NTP time formats are displayed as: %H:%M:%S.%k %Z %tw %tn %td %Y where:
Note that because of the limited size of the session id string, it is not possible to embed very many information elements in it. Therefore, this feature supports only a limited set of accounting information elements. For implementations that would like to take advantage of more information elements, Cisco's VSA implementation is recommended.
Client-Id = 172.29.248.123 NAS-Port-Type = 0 User-Name = "4004" Called-Station-Id = "+111" Calling-Station-Id = "+222" Acct-Status-Type = Start User-Service-Type = Login-User Acct-Session-Id = "4/23:21:14.078 UTC Sat Jul 18 1998/ak3620-1.cisco.com/859BF275 D7C80001 0 3AFF4/originate/VoIP///" Acct-Delay-Time = 0
Client-Id = 172.29.248.123 NAS-Port-Type = 0 User-Name = "4004" Called-Station-Id = "+111" Calling-Station-Id = "+222" Acct-Status-Type = Stop User-Service-Type = Login-User Acct-Session-Id = "4/23:21:14.078 UTC Sat Jul 18 1998/ak3620-1.cisco.com/859BF275 D7C80001 0 3AFF4/originate/VoIP/23:21:14.093 UTC Sat Jul 18 1998/23:21:23.084 UTC Sat Jul 18 1998/4/123.45.67.890" Acct-Input-Octets = 8340 Acct-Output-Octets = 8900 Acct-Input-Packets = 417 Acct-Output-Packets = 445 Acct-Session-Time = 9 Acct-Delay-Time = 0
Client-Id = 172.29.248.123 NAS-Port-Type = 0 User-Name = "4004" Called-Station-Id = "+111" Calling-Station-Id = "+222" Acct-Status-Type = 3 User-Service-Type = Login-User Acct-Session-Id = "4/21:54:17.052 UTC Mon Jul 20 1998/ak3620-1.cisco.com/BF1AC9CA 8DE60006 0 5ED24/originate/VoIP///" Acct-Delay-Time = 0
The syslog accounting option exports the information elements associated with each call leg through a system log message which can be captured by a syslog daemon that is present on the network. The syslog output consists of the following:
<server timestamp> <gateway id> <message number> : <message label> : <list of AV pairs>
where:
| Field | Description |
|---|---|
server timestamp | The timestamp created by the server when it receives the message to log. |
gateway id | The name of the gateway emitting the message. |
message number | The number assigned to the message by the gateway. |
message label | Is a string used to identify the message category. |
list of AV pairs | Is a string consisting of <attribute name> <attribute value> pairs separated by commas. |
%VOIPAAA-5-VOIP_CALL_HISTORY:CallLegType 2,ConnectionId 300094C0 60E0F3A0 60C894C0 60C90000, SetupTime 22:35:22.023UTC Tue Aug 11 1998, PeerAddress 999, PeerSubAddress , DisconnectCause 10 ,DisconnectText normal call clearing., ConnectTime 22:35:24.027 UTC Tue Aug 11 1998, DisconnectTime 22:35:29.028 UTC Tue Aug 11 1998, CallOrigin 1, ChargedUnits 0, InfoType 2,TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0
The following commands are used to configure Voice over IP AAA functionality.
The Cisco IOS software AAA accounting user interface can be configured to use the H.323 method. The authentication command line creates a method list named H.323 with RADIUS being its only member. Also note that the accounting command line looks like a regular RADIUS accounting command line for connection accounting.
Follow the configuration tasks that begin in global configuration mode:
| Step | Command | Task |
|---|---|---|
| 1 | 5800(config)# aaa new-model | Initiate the AAA script. |
| 2 | 5800(config)# aaa authentication login h323 radius | Configure the router to use the H.323 method list for authentication purposes. |
| 3 | 5800(config)# aaa accounting connection h323 start-stop radius | Specify connection based accounting and the H.323 service. |
| 4 | 5800(config)# radius-server host 171.69.58.104 auth-port 165 acct-port 1646 | Set the server host IP address, and the ports for both the authentication service and the accounting service. |
| 5 | 5800(config)# radius-server key testing123 | Test the connection accounting service. |
| 6 | 5800(config)# end | End the configuration session. |
aaa new-model aaa authentication local-override aaa authentication login default radius ! gw-accounting h323 ! radius-server host 10.90.1.1 auth-port 1645 acct-port 1646 radius-server key xxx
The purpose of this feature is to support the redirecting call feature of the Cisco AS5800 gateway. The redirecting number is an optional field of the Q.931 Setup message.
When a local exchange carrier (LEC) switch detects an incoming call that is destined for a busy or nonanswering party, the switch formulates a Q.931 Setup message with redirecting number field set to the original destination number, and sends it to the gateway. The called party number of the Setup message will be set to one of the service access numbers dialed number identification service (DNIS) of the gateway.
If a redirect number is present on an incoming call, then it is used in place of the destination number (DNIS).
The dial peer configuration for ISDN redirect involves setting up two audio scripts.
To process incoming ISDN voice calls, incoming dial peers need to be configured. The dialed number identification service (DNIS) number of the incoming call is used to match the DNIS number field of the incoming dial peer. The direct-inward-dial flag of the dial peer determines whether a second dial tone is given to the caller to collect the target destination number. For this Cisco service provider feature, the DNIS is set to the access phone number of the Gateway, and the direct-inward-dial flag is set to TRUE.
The outgoing dial peer is selected based on the DNIS number of the incoming call. The outgoing dial peer indicates the session target of the outgoing call.
1. call placed from phone A to phone B
2. phone B is busy so call rerouted by switch to Cisco AS5800 gateway
3. incoming call to Cisco AS5800 gateway in the call setup message includes calling/called and RDN info
4. calling = phone A
5. called = gateway
6. RDN = phone B
7. Cisco AS5800 matches outgoing dial-peer destination pattern against the called (in this case GW) number
8. Cisco AS5800 places call to remote IP endpoint/gateway with the following:
Channel associated signaling (CAS) is the transmission of signaling information within the voice channel. In addition to receiving and placing calls, T1 CAS provides the receipt and capture of dialed number identification (DNIS) and automatic number identification (ANI) information. This particular information (DNIS and ANI) is used to support authentication and other functions that use this information.
This feature allows the support of E&M signaling on the T1 interface. Various types of CAS signaling are available in the T1 world. The most common forms of CAS signaling are loop-start, ground-start, and E&M. CAS signaling is often referred to as robbed-bit-signaling because user bandwidth is being `robbed' by the network for other purposes.
The service provider application for T1 CAS includes connectivity to the public network using T1 CAS from the Cisco AS5300 to the end office switch. In this configuration, the Cisco AS5800 captures the Dialed Number or called party number information and passes it along to the upper level applications, for IVR script selection, modem pooling, and other applications. Service Providers also require access to calling party number, ANI, for user identification, for billing account number, and in the future, more complicated call routing.
Service Providers implementing Voice over IP include traditional voice carriers, new voice and data carriers, and existing Internet Service Providers. Some of these service providers may use subscriber side lines for their Voice over IP connectivity to the PSTN, others will use tandem-type service provider connections.
The new functionality of T1 CAS for voice includes all the T1 CAS and E1/R2 signaling already supported for the Cisco AS5800 in data applications, with the addition of dialed number and calling party number captured whenever available.
The implementation of this feature supports the following T1 CAS signaling systems for VoIP application:
Internet Service Providers can provide switched 56 kbps access to their customers using the Cisco AS5800. The subset of T1 CAS (Robbed Bit) supported features are listed as follows:
Because T1 CAS is not new to the voice and telephony industry, existing Cisco documentation describes the functionality.
See the following Cisco CCO URLs for supporting documentation.
The end user interface resembles the end user interface for T1 CAS for Cisco AS5800 MICA dial.
The following configuration is only intended as an example of how to use the commands to configure T1 CAS. It is not an example of a complete configuration for setting up the entire signaling for a telco network.
The following sample configuration is an example of how to configure the voice ports as a cas-group for the channelized T1 lines. Follow the configuration tasks that begin in global configuration mode.
| Step | Command | Task | ||
|---|---|---|---|---|
| 5800(config)# controller t1 0 | Enter controller configuration mode to configure your controller port. The controller ports are labeled 0 through 3 on the Quad T1/PRI and E1/PRI cards. | ||
| Enter your telco's framing type. | |||
| 5800(config-controller)#clock source line primary | Enter the clock source for the line. Configure other lines as clock source secondary or internal. Note that only one PRI can be clock source primary and one PRI can be clock source secondary. | ||
| 5800(config-controller)#linecode b8zs | Enter your telco's line code type. | ||
| 5800(config-controller)#ds0-group 1 timeslots 1-24 type e&m-fgb dtmf dnis | Configure all channels for E&M, FXS, and SAS analog signaling. If T1, enter 1-24. If E1, enter 1-31. Signaling types include e&m-fgb, e&m-fgd, e&m-immediate-start, fxs-ground-start, fxs-loop-start, sas-ground-start, and sas-loop-start. You must use the same type of signaling that your central office uses. For E1 using the Anadigicom converter, use cas e&m-fgb signaling. | ||
| 5800(config-controller)#controller t1 1 5800(config-controller)#framing esf 5800(config-controller)#linecode b87s 5800(config-controller)#clock source line secondary 5800(config-controller)#ds0-group 2 timeslots 1-24 type e&m-fgb | Repeat steps 3 to 5 to configure each additional controller (there are four). In this example, note that the shelf/slot/port is 1, instead of 0. The clock source is secondary, instead of primary. The ds0-group is 2, instead of 1. | ||
| 5800(config-controller)#controller T1 2 5800(config-controller)#clock source internal 5800(config-controller)#ds0-group 0 timeslots 1-24 type e&m-fgd mf ani-dnis | Repeat steps 3 to 5 to configure each additional controller (there are four). | ||
| 5800(config-controller)#controller T1 3 5800(config-controller)#clock source internal | Repeat steps 3 to 5 to configure each additional controller (there are four). | ||
| 5800(config-controller)#Ctrl-Z | Return to enable mode. | ||
| 5800(config-controller)#dial-peer voice 3070 pots destination-pattern +30... port 0:1 prefix 30 | Enter the dial peer configuration mode to configure a POTS peer. | ||
| 5800(config-controller)#dial-peer voice 4080 pots destination-pattern +40... direct-inward-dial port 1:1 prefix 40 | Specify destination pattern, and direct inward dial for each POTS peer. | ||
| 5800(config-controller)#dial-peer voice 1050 pots destination-pattern +10... direct-inward-dial prefix 50 | Specify the destination pattern and the direct inward dial for the dial peer. | ||
| 5800(config-controller)#dial-peer voice 2060 pots destination-pattern +20... direct-inward-dial prefix 60 | Specify the destination pattern and the direct inward dial for the dial peer. | ||
| 5800(config-controller)#dial-peer voice 5050 voip answer-address 10... destination-pattern +50... | Specify the destination pattern and the direct inward dial for the dial peer. | ||
| 5800(config-if)#Ctrl-Z 5800# %SYS-5-CONFIG_I: Configured from console by console | Return to enable mode. This message is normal and does not indicate an error. |
To verify your controller is up and running and that no alarms have been reported:
5800# sh cont t1 2
T1 2 is up.
No alarms detected.
Version info of slot 0: HW: 2, Firmware: 16, PLD Rev: 0
Manufacture Cookie Info:
EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x42,
Board Hardware Version 1.0, Item Number 73-2217-4,
Board Revision A0, Serial Number 06467665,
PLD/ISP Version 0.0, Manufacture Date 14-Nov-1997.
Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
Data in current interval (269 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
If you are having trouble:
Make sure the show controller t1 output is not reporting alarms or violations.
The gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the Cisco AS5800 gatekeeper and to locate another gatekeeper. The gatekeeper provides logic variables for proxies or gateways in a call path to provide connectivity with the Public Switched Telephone Network (PSTN), to improve Quality Of Service (QoS), and to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into Domain Naming System (DNS), or via Cisco IOS configuration options.
For complete information about the gatekeeper functionality, refer to the Cisco Product Documentation at the following Cisco Connection Online location:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/voip1203.htm
In addition to the Cisco IOS Release 12.0(3)T functionality described in documentation in the above URL, the gatekeeper has been enhanced with these important new features:
The Cisco routers performing the access server functionality for the gatekeeper are:
Brief descriptions of the gatekeeper features follow.
Gatekeeper HSRP (Hot Standby Router Protocol) support consists of elements in both the gateway and gatekeeper functions in the router. The gateway periodically retries its registration when it detects a possible gatekeeper failure, in order to register itself with the backup gatekeeper. Although it is a backup, the gatekeeper operates in a passive mode in which it does not accept registrations, and becomes active when it is notified by HSRP that it will become the primary gatekeeper.
Cisco gatekeepers can be configured to use HSRP so that when one gatekeeper fails, the standby gatekeeper assumes its role.
Step 1 Select one interface on each gatekeeper which will serve as the HSRP interface and configure these two interfaces so that they belong to the same HSRP group and have different priorities. The one with the higher priority will be the active gatekeeper, the other assumes the standby role.
Step 2 Make a note of the virtual HSRP IP address shared by both.
Step 3 Configure the gatekeepers so that this HSRP virtual IP address is the RAS address for all local zones.
Step 4 Ensure that the gatekeeper mode configurations on both routers are identical.
In this example, Ethernet 0 is used as the HSRP interface on both gatekeepers and the gatekeeper is configured using either a Cisco 3620 or Cisco 3640 modular access router. The three stages of the sample gatekeeper HSRP configuration are displayed in the following tables:
The following configuration steps begin in interface configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| gk1(config-if)# int e0 | Enter interface configuration mode for interface e0. | ||
| Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55. | |||
| gk1(config-if)# standby 1 timers 5 15 | Set hello timers to 5 sec, hold timer to 15sec. | ||
| gk1(config-if)# standby 1 priority 110 | Sets standby priority to 110. | ||
| gk1(config-if)# end | End the configuration of the primary gatekeeper. |
Configuration begins from interface configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| gk2(config-if)# int e0 | Enter interface configuration mode for interface e0. | ||
| gk2(config-if)# standby 1 ip 172.21.127.55 | Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55. | ||
| gk2(config-if)# standby 1 timers 5 15 | Set the hello timers for 5 sec and the hold timer for 15 sec. | ||
| gk2(config-if)# end | End the configuration of the backup gatekeeper. |
| Step | Command | Task | ||
|---|---|---|---|---|
| gk1(config)# gatekeeper | Enter gatekeeper configuration mode. | ||
| gk1(config-gk)# zone local gk-sj cisco.com 172.21.127.55 | Define local zone using HSRP virtual address as gatekeeper's RAS address. Note At this point, various other gatekeeper configuration are also performed which are not specific to the HSRP configuration. After all required gatekeeper tasks are performed, continue. | ||
| gk1(config-gk)# no shut | Allow various other gatekeeper mode configurations to bring up the gatekeeper. |
| Step | Command | Task | ||
|---|---|---|---|---|
| gk2(config-gk)# gatekeeper | Enter gatekeeper config mode. | ||
| gk2(confi-gk)# zone local gk-sj cisco.com 172.21.127.55 | Define local zone using HSRP virtual address as gatekeeper's RAS address. Note This uses the same gkname and address as on gk1. | ||
| gk2(config-gk)# no shut | Allow various other gatekeeper mode configurations to bring up the |
If you issue a show gatekeeper status command on both gatekeepers, you see on gk1:
Gatekeeper State: UP
However, if this command is issued on gk2, you see:
Gatekeeper State: HSRP STANDBY
E.164 address support was introduced in the Multimedia Conference Manager software feature that primarily dealt with H.323-ID addressing in interzone calls.
There are two types of addresses used in H.323 destination calls.
With the zone and technology prefix commands you can configure interzone routing when calls are made using E.164 addresses.
When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve "bob@cisco.com," the source endpoint's gatekeeper finds the gatekeeper for "cisco.com," and sends it the Location Request (LRQ) for target address "bob@cisco.com." The destination gatekeeper looks in the registration database, sees "bob" registered, so returns the appropriate IP address to get to bob.
When using E.164 addresses, call routing is handled through means of zone prefixes and "gateway-type" or technology prefixes.
The zone prefixes (typically area codes) serve the same purpose as the domain names in the H.323-ID address space.
For instance, if our local gatekeeper has been configured with the knowledge that zone prefix "212......" (that is, any address beginning "212" and followed by 7 arbitrary digits) is handled by gatekeeper "gk-ny":
router(config-gk)# zone prefix gk-ny 212.......
then when the local gatekeeper is asked to admit a call to destination address "2125551111," it knows to send the Location Request to gk-ny.
However, when the query gets to gk-ny, gk-ny still needs to resolve the address so that the call can be sent to its final destination. There may actually be an H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny will return the IP address for that endpoint. However, the probability is that the E.164 address belongs to a non-H.323 device (for example, a telephone or an H.320 terminal). Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge of whom the address belongs to. It needs to be able to select a gateway which can be used to reach the non-H.323 device. This is where the technology prefixes (or "gateway-type") becomes useful.
The network administrator selects technology prefixes (tech-prefixes) to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers with these prefixes. For example, voice gateways may register with tech-prefix "1#," H.320-gateways with tech-prefix "2#," voicemail-gateways with "3#," and so on. More than one gateway may register with the same type prefix. When that happens, the gatekeeper makes a random selection among gateways of the same type.
The caller, who knows the type of device they are trying to reach, can now prepend a tech-prefix to the destination address to indicate the type of gateway to use to get to the destination.
The caller might ask for 1#2125551111 if they know that the address 2125551111 is for a telephone and the tech-prefix for voice gateways is "1#." When the voice gateway receives the call for 1#2125551111, it strips off the tech-prefix and bridges the next leg of the call to the telephone at 2125551111.
In cases where the call scenario is:
telephone -----> voice-gw1 -----> voice-gw2 ----->telephone
(PSTN) (H.323) (PSTN)
voice-gw1 can be configured (using the dial-peer command) to prepend the voice tech-prefix "1," so that the use of technology prefixes is completely transparent to the caller.
There are a couple of interesting features in the implementation of the gw-type-prefix command.
If the majority of calls hop off on a particular type of gateway, the gatekeeper can be configured to use that type of gateway as the default type, so that callers no longer have to prepend a tech-prefix on the address. For example, if what you use in your network are mostly voice gateways, and you have configured all your voice gateways to register with tech-prefix 1, you can configure your gatekeeper to use "1#" gateways as the default:
5800 (config-gk)# gw-type-prefix 1# default-technologyNow a caller no longer needs to prepend "1#" to use a voice gateway. Any address that does not contain an explicit tech-prefix will be routed to one of the voice gateways which registered with "1#."
With this default-technology definition, suppose a caller asks the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it will route the call to one of its local "1#" voice gateways, so the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it sends a Location Request for 2125551111 to gk-ny. This requires that gk-ny also be configured with some default gateway type prefix, and that its voice gateways be registered with that prefix.
The other gateway-type feature is the ability to force a hop-off to a particular zone. Normally, when an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper resolves the destination address by first looking for the tech-prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address resolves to a remote zone, the entire address, including both technology and zone prefixes, is sent to the remote gatekeeper in a Location Request. That remote gatekeeper then uses the tech-prefix to decide which of its gateways to hop off.
The zone-prefix determines the routing to a zone, when there, the tech-prefix determines the gateway in that zone. See the "Zone Prefixes" section for a description of this command.
This behavior can be overridden by associating a forced hop-off zone with a particular tech-prefix. What this does is force the call to the specified zone, regardless of the zone-prefix in the address.
A hypothetical example to demonstrate a forced hop-off follows. You are in the 408 area code (San Jose) and you want calls to the 212 area code to hop-off in New York via VoIP to save costs but you do not have any gateway in New York. However you do have a H.323 gateway in Denver and to hop-off from Denver is cheaper than to locally hop-off from San Jose. In this case, you would define the gateway-type prefix 212 for H.323 gateways to always be forced to the Denver zone.
Technology prefixes are used to distinguish between gateways having specific capabilities within a given zone. They are handled specially because the technology prefix is ignored during the zone selection process and then examined for gateway selection within the zone. This requires that the prefix be ignored during the zone selection process. Technology prefixes have been designed to enable the use of E.164 address routing. E.164 is an International Telecommunications Union (ITU) specification for the ISDN international telephone numbering plan, which has traditionally only been used in telephone networks.
The gateway technology prefix is set up using the following new commands.
All of the Service Provider for VoIP features are configured when setting up the gatekeeper and gateway internetworking configuration. The example configurations provided in the following sections are supplied for reference only.
Before you can configure your Cisco AS5800 for Service Provider Features, ensure you have the following installed:
The SNMP MIBS are available on CCO. The CISCO-VOICE-DIAL-CONTROL-MIB supports the QoV and QoS of VoIP calls. Refer to the online support reference listed at the following location:
This gatekeeper configuration example uses the E.164 address routing configuration and is based on the following assumptions:
Cisco recommends that the gatekeeper ID should be in the form of gkname.domainname. This is to avoid ambiguity when a gatekeeper communicates with other gatekeepers in another domain.
In this example, gatekeepers are configured for San Jose and New York as follows.
These tasks are performed beginning in gatekeeper configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| gatekeeper | Enter gatekeeper configuration mode. | ||
| Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-sj" and the domain name is "cisco.com."1 | |||
| zone remote gk-ny cisco.com 172.21.127.27 | Notify the gatekeeper that gatekeeper "gk-ny" manages the "212" area code so that calls to E.164 addresses beginning with 212 should be sent to "gk-ny" (at 172.21.127.27). | ||
| zone access gk-sj default direct | Define the accessibility for local zone "gk-sj." This states that the calls originating in any (default) zone, "gk-sj" offers "direct" (unproxied) access to H.323 entities in its zone. Note If this command is not issued, the default gatekeeper behavior will offer access through proxies, which introduces an extra call leg into the call. | ||
| zone prefix gk-sj 1408....... | Configure the gatekeeper to handle the 408 area code. | ||
| zone prefix gk-ny 1212....... | Notify the gatekeeper that gatekeeper "gk-ny" manages the 212 area code, so that calls to E.164 addresses beginning with 1212 should be sent to "gk-ny" (at 172.21.127.27). | ||
| gw-type-prefix 3# hopoff gk-sj | Define a gateway technology "3#" prefix and stipulate that any calls to addresses beginning with this technology prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix is. | ||
| gw-type-prefix 4# default-technology | Define a gateway technology "4#" prefix. The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing unresolvable addresses. |
| 1Although domain names are not used for VoIP calls using an E.164 address, this is a required argument for the zone local command. |
These tasks are performed beginning in gatekeeper configuration mode:
| Step | Command | Task | ||
|---|---|---|---|---|
| gatekeeper | Enter gatekeeper configuration mode. | ||
| zone local gk-ny cisco.com | Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-ny" and the domain name is "cisco.com." | ||
| zone remote gk-sj cisco.com 172.21.1.48 | Notify the gatekeeper about a remote gatekeeper called "gk-sj" which is located at IP address 172.21.1.48. | ||
| zone access gk-ny default direct | Define the accessibility for local zone "gk-ny." This states that the calls originating in any (default) zone, "gk-ny" should offer "direct" (that is, unproxied) access to H.323 entities in its zone. Note If this command is not issued, the default gatekeeper behavior will offer access through proxies, which introduces an extra call leg into the call. | ||
| zone prefix gk-ny 1212....... | Configure the gatekeeper to handle the 1212 area code. | ||
| zone prefix gk-sj1408...... | Notify the "gk-ny" gatekeeper that manages the 408 area code, so that calls to E.164 addresses beginning with 1408 should be sent to "gk-sj" (at 172.21.1.48). | ||
| gw-type-prefix 3# hopoff gk-ny | Define a gateway technology prefix "3#" and stipulate that any calls to addresses beginning with this tech prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix. | ||
| gw-type-prefix 4# default-technology | Define a gateway technology prefix "4#." The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing otherwise, unresolvable addresses. |
In San Jose suppose we have gateways registering with gk-sj as follows:
gw-sj2 configured to register with tech prefix 2#Similarly, in New York, gateways are configured to register with gk-ny as follows:
gw-ny2 configured to register with tech prefix 2#Given the above configuration, in San Jose, a call is presented to the gatekeeper gk-sj with the following target address:
gk-sj recognizes that 2# is a tech prefix (it was not configured as such, but because gw-sj2 registered with it, the gatekeeper now treats 2# as a tech prefix) strips that and is left with "12125551212." This is matched against the zone prefixes, and is a match for 1212......., so gk-sj knows that gk-ny handles this. It forwards the whole address "2#12125551212" over to gk-ny, who also looks at the tech prefix 2#, and routes this to gw-ny2.
gk-sj checks this against known tech prefixes, no match. Checks against zone prefixes, matches on 1212....... for gk-ny, so routes this to gk-ny. gk-ny does not have any local registrations for this address, and there is no tech prefix on the address, but the default prefix is 4# and gw-ny4 is registered with 4#, so the call gets routed to gw-ny4.
Because this contains the tech prefix of 3# and that is defined as a local-hopoff prefix, gk-sj just routes this to gw-sj3, despite the fact that it contains a zone-prefix for New York.
gk-sj looks for a technology prefix match, and fails. Looks for a zone-prefix match and fails again. But succeeds in finding a default gateway prefix of 4#. Succeeds when gw-sj4 is registered with 4#, so, the call gets sent routed out on gw-sj4.
The following show command displays overall gatekeeper status that includes authorization and authentication status and zone:
router# sh gatekeeper status
Gatekeeper State: UP
Zone Name: gk-px4.cisco.com
Accounting: DISABLED
Security: DISABLED
This is an example of the configuration steps required to allow the internetworking functionality between the VoIP gateway and the gatekeeper.
These tasks are performed beginning in gatekeeper configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| gateway | Enter gateway configuration mode. | ||
| interface fe0 | Select the interface to be configured as a gateway.1 | ||
| h323 voip interface | Enable the Fast Ethernet interface as an H.323 Gateway VoIP interface. | ||
| h323-gateway voip h323-id voip1@vvm1lab | Specify the gateway H.323 ID. Note An H.323 ID specifies the ID used by this gateway when it communicates with the gatekeeper. Usually, this H.323 ID is the name given to the gateway with the gatekeeper domain name appended. | ||
| h323-gateway voip tech-prefix 7# | Specify a technology prefix. Note In this example, the gateway is connected to a Voice Mail server with the technology "7#" prefix. | ||
| h323 voip id gatekeeper-id {ipaddr ip-address [port-number] | multicast} | Identify a gatekeeper.2 |
The following example configures Ethernet interface 0.0 as the gateway interface. In this example, the gatekeeper ID is GW15.cisco.com and its IP address is 172.9.53.15 (using port 1719).
5300-1(config)# interface Ethernet0/0 5300-1(config-if)# 5300-1(config-if)# ip address 172.9.53.13 255.255.255.0 5300-1(config-if)# h323-gateway voip interface 5300-1(config-if)# h323-gateway voip id GK15.cisco.com ipaddr 172.9.53.15 1719 5300-1(config-if)# h323-gateway voip h323-id GW13@cisco.com 5300-1(config-if)# h323-gateway voip tech-prefix 13#
The following examples configure various gatekeeper-ids.
5300-1# conf t 5300-1(config)# interface fa0 5300-1(config-if)# h323 voip id gk1.vm1lab multicast
5300-1# conf t 5300-1(config)# int fa0 5300-1(config-if)# h323 voip id gk1.vm1lab ipaddr 10.10.10.1
5300-1# conf t 5300-1(config)# int fa0 5300-1(config-if)# h323 voip id gk1.vm1lab ipaddr 10.10.10.1 port 1719
The following show command displays the current registration status of your gateway:
5300-1# sh gateway
Gateway voip1@vm1lab is registered to gatekeeper gk1.vm1lab
Posted: Wed Nov 3 16:58:47 PST 1999
Copyright 1989-1999©Cisco Systems Inc.