Downloads |
Table Of Contents
Prerequisites for Configuring H.323 Gateways
Restrictions for Configuring H.323 Gateways
How to Configure H.323 Gateways
Configuring a Router Interface as a Gateway
Configuring a Router Interface
Shutting Down and Enabling VoIP Services on a Gateway
Shutting Down and Enabling VoIP Service
Shutting Down and Enabling VoIP Submodes
Configuring RAS Retries and Timers
Configuring Gateway-Resource-Availability Reporting
Configuring E.164-Address Registration
Configuring In-Band Tones and Announcements
Configuring H.235 Gateway Security
Information About H.235 Gateway Security
Configuring H.235 Gateway Security
Verifying H.235 Gateway Security
Configuring Alternate-Gatekeeper Support
Restrictions for Alternate-Gatekeeper Support
Information About Alternate-Gatekeeper Support
Configuring Alternate-Gatekeeper Support
Verifying Configuration of Alternate-Gatekeeper Support
Monitoring and Maintaining DTMF Relay
Configuring FXS Hookflash Relay
Configuring Rotary Calling Pattern
Configuring H.323 Support for Virtual Interfaces
Configuring the Source IP Address of a Gateway
Verifying the Source IP Address of the Gateway
Configuring and Provisioning an Annex G Border Element
Configuring Basic Service Relationships
Verifying Annex G Configuration
Associating the H.323 Voice Class with Each VoIP Dial Peer
Configuring the SETUP Response Timeout Value
Configuring the Number of Concurrent Calls Per Connection
Changing the Idle Timer for Concurrent Calls
Configuring Overlap Signaling on H.323 Terminating Gateways
Configuring No Retry on User Busy in an H.323 Gateway
Configuring the VoIP Transport Method
Configuring Zone Bandwidth Management
Information About GTD for GKTMP Using SS7 Interconnect for Voice Gateways
Prerequisites for GTD for GKTMP Using SS7 Interconnect for Voice Gateways
Configuring GTD for a Dial Peer
Configuring H.323 Version 4 Zone Prefix Registration
Information About H.323v4 Gateway Zone Prefix Registration Enhancements
Configuring H.323v4 Gateway Zone Prefix Registration Enhancements
Configuring Call Admission Control
Configuring Trunk-Based and Carrier-Based Routing
Configuring Signal ISDN B-Channel ID to Enable Application Control of Voice Gateway Trunks
Information About Signal ISDN B-Channel ID
Configuring Signal ISDN B-Channel ID
Troubleshooting Signal ISDN B-Channel ID
Configuring H.323 VoIP Call Preservation Enhancements for WAN Link Failures
Configuring H.323 Call Preservation Enhancements for WAN Link Failures
Configuring Cisco Unified CallManager
Configuration Examples for H.323 Gateways
Alternate Gatekeeper Support: Example
Rotary Calling Pattern: Example
H.323 Support for Virtual Interfaces: Example
H.323v4 Gateway Zone Prefix Registration Enhancements: Examples
Signal ISDN B-Channel ID: Example
H.323 VoIP Call Preservation Enhancements for WAN Link Failures Examples
H.323 VoIP Call Preservation for All Calls Example
H.323 VoIP Call Preservation for a Dial Peer Example
H.323 Call Preservation for RTP and RTCP and Silence Detection Example
RTP and RTCP Inactivity Detection Configuration Example
Bidirectional Silence Detection Enable Example
Configuring H.323 Gateways
This chapter describes the configuration of H.323 gateways.
Feature History for Basic Service Relationships (H.225 Annex-G)
Feature History for Cisco H.323 Scalability and Interoperability Enhancements for Gatekeepers
Feature History for Gateway Codec Order Preservation and Shutdown Control
Feature History for H.323 Dual Tone Multifrequency Relay Using Named Telephone Events
Feature History for H.323 Version 2 Enhancements
Feature History for H.323v4 Gateway Zone Prefix Registration Enhancements
Feature History for Signal ISDN B-Channel ID to Enable Application Control of Voice Gateway Trunks
Feature History for H.323 VoIP Call Preservation Enhancements for WAN Link Failures
12.4(4)XC
This feature was introduced.
12.4(9)T
This feature was integrated into this release.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note
For more information about these and other related Cisco IOS voice features, see the following:
•
•
Contents
•
•
•
•
Note
Prerequisites for Configuring H.323 Gateways
•
•
•
•
–
–
Restrictions for Configuring H.323 Gateways
Restrictions are described in the Restrictions for Configuring an H.323 Network, page 10
Note
How to Configure H.323 Gateways
This section contains the following information:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuring a Router Interface as a Gateway
To configure a Cisco device as an H.323 gateway in a service provider environment, configure at least one of its interfaces as a gateway interface. Use either an interface that is connected to the gatekeeper or a loopback interface for the gateway interface. The interface that is connected to the gatekeeper is usually a LAN interface: Fast Ethernet, Ethernet, FDDI, or Token Ring.
Configuring a Router Interface
To configure a gateway interface, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPSVerifying a Router Interface
To verify the router interface, perform the following step.
Step 1
Use this command to verify gateway configuration by displaying the current registration information and gateway status.
Router# show gateway
Shutting Down and Enabling VoIP Services on a Gateway
This section contains the following procedures:
•
•
Shutting Down and Enabling VoIP Service
To shut down or enable all VoIP services on a Cisco gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Shutting Down and Enabling VoIP Submodes
To shut down and enable VoIP submodes, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSVerifying Gateway Status
To verify gateway status, perform the following step.
Step 1
Use this command to display gateway status.
The following example displays output after the gateway has been shut down:
Router# show gatewayH.323 ITU-T Version: 4.0 H323 Stack Version: 0.1H.323 service is shutdownGateway Router is not registered to any gatekeeperThe following example displays output after a graceful shutdown with calls in progress:
Router# show gatewayH.323 ITU-T Version: 4.0 H323 Stack Version: 0.1H.323 service is shutting downGateway Router is registered to Gatekeeper GK1The following example displays output when H.323 call service has been shut down with the call service stop maintain-registration command:
Router# show gatewayH.323 ITU-T Version: 4.0 H323 Stack Version: 0.1H.323 service is shutdownGateway Router is registered to Gatekeeper GK1
Configuring Gateway RAS
This section contains the following information:
•
•
Registration, Admission, and Status (RAS) signaling performs registration, admissions, status, and disengage procedures between the H.323 VoIP gateway and the H.323 VoIP gatekeeper. RAS tells the gatekeeper to translate a E.164 phone number of the session target into an IP address.
In the RAS exchange between a gateway and a gatekeeper, a technology prefix is used to identify the specific gateway when the selected zone contains multiple gateways. The tech-prefix command is used to define technology prefixes.
In most cases there is a dynamic protocol exchange between the gateway and the gatekeeper that enables the gateway to inform the gatekeeper about technology prefixes and where to forward calls. If, for some reason, that dynamic registry feature is not in effect, statically configure the gatekeeper to query the gateway for this information.
Note
To configure RAS, define specific parameters for the applicable POTS and VoIP dial peers. The POTS dial peer informs the system of which voice port to direct incoming VoIP calls to and (optionally) determines that RAS-initiated calls have a technology prefix prepended to the destination telephone number. The VoIP dial peer determines how to direct calls that originate from a local voice port into the VoIP cloud to the session target. The session target indicates the address of the remote gateway where the call is terminated. There are several different ways to define the destination gateway address:
•
•
•
Configuring Basic RAS
To configure basic RAS, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPSVerifying RAS Configuration
To verify RAS configuration, perform the following step.
Step 1
Use this command to verify the POTS and VoIP dial-peer configuration.
The following example shows output for a VoIP dial peer using RAS on a Cisco AS5300:
Router# show dial-peer voice 1234VoiceOverIpPeer1234tag = 1234, destination-pattern = 1234',answer-address = ',group = 1234, Admin state is up, Operation state is up,incoming called-number = ', connections/maximum = 0/unlimited,application associated:type = voip, session-target = ras',technology prefix: 8#ip precedence = 0, UDP checksum = disabled,session-protocol = cisco, req-qos = controlled-load,acc-qos = best-effort,fax-rate = voice, codec = g729r8,Expect factor = 10, Icpif = 30,VAD = enabled, Poor QOV Trap = disabled,
Troubleshooting Tips
•
•
Configuring RAS Retries and Timers
You can configure RAS message timeout values, message retry counter values, and registration request (RRQ) message time-to-live and early transmit time margins on Cisco gateways. This provides greater flexibility in configuring gateways in different network environments.
The ras timeout command configures the number of seconds for the gateway to wait before resending a RAS message to a gatekeeper. The ras retry command configures the number of times to resend the RAS message after the timeout period expires. The default values for timeouts and retries are acceptable in most networks. You can use these commands if you are experiencing problems in RAS message transmission between gateways and gatekeepers. For example, if you have gatekeepers that are slow to respond to a type of RAS request, increasing the timeout value and the number of retries increases the call success rate, preventing lost billing information and unnecessary switchover to an alternate gatekeeper.
The ras rrq ttl command configures the number of seconds that the gateway should be considered active by the gatekeeper. The gateway transmits this value in the RRQ message to the gatekeeper. The margin time keyword and argument allow the gateway to transmit an early RRQ to the gatekeeper before the time-to-live value advertised to the gatekeeper.
Configuring RAS Timeout and Retry Counters
To configure RAS message timeout values and retry counters, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSConfiguring RRQ Time-to-Live Value
To configure the RRQ time-to-live value, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSVerifying RAS Retries and Timers
To verify RAS retries and timers, perform the following step.
Step 1
Use this command to verify RAS message retry counters, timeout values, and time-to-live values.
Router# show running-configCurrent configuration : 925 bytes!version 12.3...voice service voiph323ras rrq ttl 90 margin 30ras timeout all 7ras timeout grq 10ras timeout drq 30ras retry all 10ras retry grq 5...
Examples
The following example shows the GRQ message timeout value set to 10 seconds and all other RAS message timeout values set to 7 seconds:
Router(conf-serv-h323)# ras timeout grq 10Router(conf-serv-h323)# ras timeout all 7The following example shows the GRQ message counter set to 5 and all other RAS message counters set to 10:
Router(conf-serv-h323)# ras retry all 10Router(conf-serv-h323)# ras retry grq 5The following example shows the time-to-live value configured to 90 seconds and the margin time value configured to 30 seconds:
Router(conf-serv-h323)# ras rrq ttl 90 margin 30Configuring Gateway-Resource-Availability Reporting
To allow gatekeepers to make intelligent call-routing decisions, the gateway reports the status of its resource availability to its gatekeeper. Resources that are monitored are digital-signal-level 0 (DS0) channels and digital-signal-processor (DSP) channels.
The gateway reports its resource status to the gatekeeper using the RAS Resource Availability Indication (RAI). When a monitored resource falls below a configurable threshold, the gateway sends a RAI to the gatekeeper indicating that the gateway is almost out of resources. When the available resources then cross over another configurable threshold, the gateway sends an RAI indicating that the resource depletion condition no longer exists.
You can configure resource-reporting thresholds by using the resource threshold command. Upper and lower thresholds are separately configurable to prevent the gateway from operating sporadically because of the availability or lack of resources.
Configuring E.164-Address Registration
If phones are connected directly to the gateway, the Cisco H.323 Version 2 gateway allows fully qualified E.164 numbers to be registered with the gatekeeper. When configuring the gateway, use the register e164 command to register these E.164 numbers.
Configuring In-Band Tones and Announcements
In-band progress tones and announcements are required for PSTN services and for ISDN speech and 3.1-kHz voice services, per Bellcore and ANSI specifications. To guarantee that in-band tones and announcements are generated when required and at the appropriate switch, Cisco H.323 signaling software ensures that the progress indicator (PI) is carried end to end in call-signaling messages between the called party and the calling party. The PI in outbound dial peers can also be configured at the H.323 VoIP gateway, if necessary.
The PI is an IE that signals when in-band tones and announcements are available. The PI controls whether the local switch generates the appropriate tone or announcement or whether the remote switch is responsible for the generation. For example, if the terminating switch generates the ringback tone, it sends a PI of 1 or 8 in the alerting message. If the originating switch receives an alerting message without a PI, it generates the ringback tone.
The specific PI that a switch sends in call messages, if any, depends on the model of the switch. To ensure that in-band communication is generated appropriately, it may be necessary in some instances to override the default behavior of the switch by manually configuring the PI at the Cisco H.323 gateway.
The PI is configurable in setup messages from the outbound VoIP dial peer, typically at the originating gateway, and in alert, progress, and connect messages from the outbound POTS dial peer, typically at the terminating gateway. The PI is configured by the progress_ind command. Table 1 shows the PI values that can be configured on the H.323 gateway.
When interworking is between ISDN and non-ISDN networks, the originating gateway reacts as follows:
•
–
–
Note
•
Note
Configuring Gateway AAA
For the gateway to provide authentication and accounting services, enable and configure your gateway to support authentication, authorization, and accounting (AAA) services. AAA enables the gateway to interact with a RADIUS security server to authenticate users (typically incoming calls) and to perform accounting services.
Note
•
Configuring H.235 Gateway Security
This section contains the following information:
•
•
•
Information About H.235 Gateway Security
The Cisco H.235-based security and accounting features described in this section can be used by a gatekeeper, which is considered a known and trusted entity, to authenticate, authorize, and route H.323 calls.
The Cisco H.323 gateway supports the use of CryptoH323Tokens for authentication. The CryptoH323Token is defined in the ITU-T H.225 Version 2 standard and is used in a "password-with-hashing" security scheme as described in section 10.3.3 of the H.235 specification.
A cryptoToken can be included in any RAS message to authenticate the sender of the message. A separate database can be used for user ID and password verification.
Cisco H.323 gateways support three levels of authentication:
•
Note
•
•
CryptoTokens for RRQs, unregistration requests (URQs), DRQs, and the terminating side of ARQs contain information about the gateway that generated the token. The cryptoTokens include the gateway identification (ID)—which is the H.323 ID configured on the gateway—and the gateway password. The cryptoTokens for the originating-side ARQ messages contain information about the user that is placing the call, including the user ID and PIN.
Although the scenarios in this document describe how to use the security and accounting features in a prepaid call environment, these features may also be used to authorize IP calls that originate in another domain (interservice provider or intercompany calls).
H.235-based security and accounting features can be used with AAA. The gateway can be configured to use the gatekeeper for call authentication or authorization, and AAA can be used for call accounting.
In addition, H.235-based security and accounting features include support for the following:
•
•
Note
Settlement with the Gatekeeper
The H.235 security and accounting features are designed to support a variety of situations in which some form of authentication or tracking is required. The security features control access through a userID-password database. The accounting enhancements allow call usage to be tracked at the origin and at the destination.
Fields in the RAS messages allow the gateway to report call-usage information to the gatekeeper. The call-usage information is included in the DRQ message that is sent when the call is terminated.
Call Tracking
With prepaid calling services, an account number and PIN must be entered and the duration of the call must be tracked against the remaining credit of the customer. The Cisco H.323 gateway monitors prepaid account balances and terminates a call if the account is exceeded.
Note
Figure 1 illustrates the flow of a possible call for which H.323 security and accounting features are used.
Figure 1 Flow for a Call That Requires H.323 Security and Accounting Features
In this example, Telephone A is attempting to establish a phone call to Telephone B. The following numbered explanations correspond to the action taking place at each numbered reference in Figure 1.
Gateways Establish Secure Communication with the Gatekeepers
1.
2.
3.
4.
5.
If an authentication failure occurs, the gatekeeper responds with a registration rejection (RRJ) message.
Secure Telephone Communications Initiated
6.
7.
8.
9.
10.
11.
12.
If the authentication information is in error, Gatekeeper B sends an admission rejection (ARJ) message to Gateway B with a reject reason of securityDenial.
13.
14.
15.
Telephone Communications Terminated
16.
17.
18.
Communication Between the Gateways and the Gatekeepers Terminated
19.
20.
Downloading IVR Scripts
Tool Command Language (TCL) IVR scripts are the default scripts for all Cisco voice features that use IVR.
The H.323 security and accounting enhancements described in this document require the use of one of the following IVR scripts:
•
•
Note
voip_auth_acct_pin_dest.tcl Script
The voip_auth_acct_pin_dest.tcl script does the following:
•
If the caller is using a debit card account number, the following occurs:
–
–
–
•
This feature also allows the caller to continue making additional calls if the called party hangs up.
•
•
Note
•
•
•
•
voip_auth_acct_pin_dest_2.tcl Script
The voip_auth_acct_pin_dest_2.tcl script is a simplified version of the voip_auth_acct_pin_dest.tcl script. It prompts the caller for an account number followed by a PIN. The caller is then prompted for a destination number. This information is provided to the H.323 gatekeeper that authenticates and authorizes the call. This script provides prompts only in English.
If the caller is using a debit account number, it plays a "time running out" message when the caller has 10 seconds of credit time remaining. It also plays a "time has expired" message when the credit of the caller has been exhausted.
Configuring H.235 Gateway Security
To use the H.235 security features for routing H.323 calls as illustrated above, do the following:
•
•
http://www.cisco.com/cgi-bin/tablebuild.pl/tclware
•
To enable security on the gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
gateway
Example:Router(config)# gateway
Enters gateway configuration mode.
Step 2
security password password level {endpoint | per-call | all}
Example:Router(config-gateway)# security password password level all
Enables security and specifies the level of validation to be performed.
•
•
•
•
Step 3
exit
Example:Router(config-gateway)# exit
Exits the current mode.
Step 4
dial-peer voice tag pots
Example:Router(config)# dial-peer voice 1 pots
Enters dial-peer configuration mode for the POTS dial peer designated by the tag value.
Step 5
call application voice application-name location word
Example:Router(config-dial-peer)# call application voice xyz tftp://172.18.16.2/samp/xyz.tcl
Initiates the IVR application and the selected TCL application name.
•
•
•
Step 6
destination-pattern string[T]
Example:Router(config-dial-peer)# destination-pattern 1513200....
Specifies the E.164 address associated with this dial peer. For an explanation of the keywords and arguments, see the "Configuring Gateway RAS" section, Step 2.
Step 7
port controller-number:D
Example:Router(config-dial-peer)# port 0:D
(Cisco AS5300 only) Configures the voice port associated with this dial peer. Keywords and arguments are as follows:
•
•
Note
Step 8
exit
Example:Router(config-dial-peer)# exit
Exits the current mode.
Verifying H.235 Gateway Security
To verify H.235 gateway security, perform the following step.
Step 1
Use this command to display the security password and level when it is enabled. By default, security is disabled.
Router# show running-configsecurity password 151E0A0E level all
Configuring Alternate-Gatekeeper Support
This section contains the following information:
•
•
•
•
Restrictions for Alternate-Gatekeeper Support
•
•
•
Information About Alternate-Gatekeeper Support
A gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the 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 the DNS or by using Cisco IOS configuration options.
An alternate gatekeeper provides redundancy for a gateway in a system in which gatekeepers are used. Redundant H.323 zone support in the gateway allows a user to configure two gatekeepers in the gateway (one as the primary and the other as the alternate). All gatekeepers are active. Each alternate gatekeeper, or gatekeeper node, shares its local zone information so that the cluster can effectively manage all local zones within the cluster. Each alternate gatekeeper has a unique local zone. Clusters provide a mechanism for distributing call processing seamlessly across a converged IP network infrastructure to support IP telephony, facilitate redundancy, and provide feature transparency and scalability.
An endpoint that detects the failure of its gatekeeper can safely recover from that failure by utilizing an alternate gatekeeper for future requests, including requests for existing calls. A gateway can only be registered to a single gatekeeper at a time. Only one gatekeeper is allowed to manage a single zone. The cluster manages up to five similarly configured zones and shares resources between the alternate gatekeepers in the cluster for each zone. You can define up to 100 zones in a single gatekeeper.
With gatekeeper clustering there is the potential that bandwidth may be overcommitted in a cluster. For example, suppose that there are five gatekeepers in a cluster and that they share 10 Mbps of bandwidth. Suppose that the endpoints registered to those alternates start placing calls quickly. It is possible that within a few seconds, each gatekeeper could be allocating 3 Mbps of bandwidth if the endpoints on each of the gatekeepers request that much bandwidth. The net result is that the bandwidth consumed in the cluster is 15 Mbps.
The alternate gatekeeper was purposely designed to restrict bandwidth because there is no clear way to sync bandwidth information quickly and efficiently. To work around this problem, "announcement" messages were restricted to intervals as small as 10 seconds. If the gatekeepers get into a situation in which endpoints request bandwidth rapidly, the problem is discovered and corrective action takes place within 10 seconds. Assuming that the gatekeepers are not synchronized on their timers, the announcement messages from the various gatekeepers are likely to be heard more quickly. Therefore, the problem is less severe. The potential exists, however, for overcommitment of the bandwidth between announcement messages if the call volume increases substantially in a short amount of time (as small as 10 seconds).
Note
Configuring Alternate-Gatekeeper Support
To configure alternate gatekeeper support on a gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
interface Ethernet 0/1
Example:Router(config)# interface Ethernet 0/1
Enters interface configuration mode for the selected Ethernet interface.
Step 2
h323-gateway voip interface
Example:Router(config-if)# h323-gateway voip interface
Identifies this as a VoIP gateway interface.
Step 3
h323-gateway voip id gatekeeper-id {ipaddr ip-address [port]| multicast} [priority priority]
Example:Router(config-if)# h323-gateway voip id gk3.gg-dn1 ipaddr 172.18.0.0 1719
Identifies the gatekeeper for this gateway interface and sets its attributes.
For an explanation of the keywords and arguments, see the "How to Configure H.323 Gateways" section, step 6.
Step 4
h323-gateway voip id gatekeeper-id {ipaddr ip-address [port] | multicast} [priority priority]
Example:Router(config-if)# h323-gateway voip id gk3.gg-dn1 ipaddr 172.18.0.0 1721
Identifies the alternate gatekeeper and sets its attributes.
Step 5
h323-gateway voip h323-id interface-id
Example:Router(config-if)$ h323-gateway voip id gk4.gg-dn1 ipaddr 209.165.202.132 1719
Defines the H.323 name of the gateway, identifying this gateway to its associated gatekeeper. Usually this ID is the name of the gateway, with the gatekeeper domain name appended to the end: name@domainname.
Step 6
exit
Example:Router(config-if)# exit
Exits the current mode.
Verifying Configuration of Alternate-Gatekeeper Support
To verify configuration of alternate-gatekeeper support, perform the following step.
Step 1
Use this command to verify that an alternate gatekeeper is configured.
Router# show gatewayPermanent Alternate Gatekeeper Listpriority 127 id bmx1 ipaddr 10.77.241.103 1719 register neededpriority 127 id bmx2 ipaddr 10.77.241.117 1719 register neededPrimary gatekeeper ID bmx1 ipaddr 10.77.241.103 1719
Configuring DTMF Relay
This section contains the following information:
•
Information About DTMF Relay
Dual-tone multifrequency (DTMF) is the tone generated on a touchtone phone when the keypad digits are pressed. During a call, DTMF may be entered to access interactive voice response (IVR) systems, such as voice mail and automated banking services.
Although DTMF is usually transported accurately when using high-bit-rate voice codecs such as G.711, low-bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns and tend to distort DTMF tones. As a result, IVR systems may not correctly recognize the tones.
DTMF relay solves the problem of DTMF distortion by transporting DTMF tones "out of band," or separate from the encoded voice stream.
Relay Types
Cisco gateways currently support the following methods of DTMF relay:
•
•
•
The ability of a gateway to receive DTMF digits in a particular format and the ability to send digits in that format are independent functions. No configuration is necessary to receive DTMF digits from another H.323 endpoint using any of the methods described. The Cisco gateway is capable of receiving DTMF tones transported by any of these methods at all times.
Capabilities and Priorities
Cisco H.323 gateways advertise capabilities using H.245 capabilities messages. By default, they advertise that they can receive all DTMF relay modes. If the capabilities of the remote gateway do not match, the Cisco H.323 gateway transmits DTMF tones as in-band voice.
Configuring DTMF relay on the Cisco H.323 gateway sets preferences for how the gateway handles DTMF transmission. You can enable more than one DTMF relay option for a particular dial peer. If more than one option is enabled and if the peer indicates that it is capable of receiving DTMF in more than one of these formats, the gateway sends DTMF using the method among the supported formats that it considers to be the most preferred. If the remote device supports multiple formats, the gateway chooses the format according to the following priority:
1.
2.
3.
4.
5.
Payload Types
In addition, Cisco gateways provide support for asymmetrical payload types. Payload types can differ between local and remote endpoints. Therefore, the Cisco gateway can transmit one payload type value and receive a different payload type value.
The dtmf-relay h245-signal command relays a more accurate representation of a DTMF digit than does the dtmf-relay h245-alphanumeric command because tone duration information is included along with the digit value. This information is important for applications requiring that a key be pressed for a particular length of time. For example, one popular calling card feature allows the caller to terminate an existing call by pressing the # key for more than 2 seconds and then making a second call without having to hang up in between. This feature is beneficial because the access number and personal identification number (PIN) code do not need to be dialed again. Outside-line access charges, which are common at hotels, may also be avoided.
The dtmf-relay h245-alphanumeric command simply relays DTMF tones as ASCII characters. For instance, the DTMF digit 1 is transported as the ASCII character 1. There is no duration information associated with tones in this mode. When the Cisco H.323 gateway receives a DTMF tone using this method, the gateway generates the tone on the PSTN interface of the call using a fixed duration of 500 ms. All systems that are H.323 Version 2-compliant are required to support the dtmf-relay h245-alphanumeric command, but support of the dtmf-relay h245-signal command is optional.
H.245 Tunneling of DTMF Relay in Conjunction with Fast Connect
Through H.245 tunneling, H.245 messages are encapsulated within H.225 messages without using a separate H.245 TCP connection. When tunneling is enabled, one or more H.245 messages can be encapsulated in any H.225 message. H.245 tunneling is not supported as a stand-alone feature; initiation of H.245 tunneling procedures can be initiated only by using the dtmf-relay command and only from an active fast connect call. Furthermore, if dtmf-relay is configured on a Version 2 VoIP dial peer and the active call has been established by using fast connect, tunneling procedures initiated by the opposite endpoint are accepted and supported.
H.245 tunneling is backward compatible with H.323 Version 1 configurations.
Configuring DTMF Relay
To configure DTMF relay on a gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
or
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] hostname | loopback:rtp | loopback:compressed | loopback:uncompressed | mailto:{name | $d$.}@domainname}
7.
DETAILED STEPS
Step 1
dial-peer voice tag voip
Example:Router(config)# dial-peer voice tag voip
Enters dial-peer configuration mode for the VoIP dial peer designated by tag.
Step 2
dtmf-relay [cisco-rtp] [h245-alphanumeric] [h245-signal] [rtp-nte]
Example:Router(config-dial-peer)# dtmf-relay cisco-rtp h245-alphanumeric h245-signal rtp-nte
Forwards DTMF tones. Keywords are as follows:
•
•
•
•
Step 3
rtp payload-type nte number
Example:Router(config-dial-peer)# rtp payload-type nte 100
Identifies the payload type of a Real-Time Transport Protocol (RTP) packet. Keyword and argument are as follows:
•
Do not use the following numbers, because they have preassigned values: 96, 97, 100, 121 to 123, and 125 to 127.
Use of these values causes the command to fail. You must first reassign the value in use to a different unassigned number, for example:
rtp payload-type nse 105rtp payload-type nte 100Step 4
codec {clear-channel | g711alaw | g711ulaw | g723ar53 | g723ar63 | g723r53 | g723r63 | g726r16 | g726r24 | g726r32 | g726r53 | g726r63 | g728 | g729abr8 | g729ar8 | g729br8 | g729r8 | gsmefr | gsmfr} [bytes payload_size]
Example:Router(config-dial-peer)# codec g711alaw
Specifies the voice coder rate of speech for a dial peer.
Step 5
destination-pattern string[T]
Example:Router(config-dial-peer)# destination-pattern 1513200....
Specifies the prefix, the full E.164 telephone number, or an ISDN directory number to be used for a dial peer (depending on the dial plan).
For an explanation of the keywords and arguments, see the "Configuring Gateway RAS" section, Step 2.
Step 6
Cisco 2600 Series and Cisco 3600 Series
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] hostname | loopback:rtp | loopback:compressed | loopback:uncompressed}
Cisco AS5300
session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] hostname | loopback:rtp | loopback:compressed | loopback:uncompressed | mailto:{name | $d$.}@domainname}
Example:Router(config-dial-peer)# session target ipv4:192.168.0.0
Specifies a network-specific address for a specified dial peer or destination gatekeeper.
Step 7
exit
Example:Router(config-dial-peer)# exit
Exits the current mode.
Monitoring and Maintaining DTMF Relay
To monitor and maintain H.323 DTMF relay using NTE, use the following commands.
Step 1
Use this command to turn on debugging for RTP NTEs.
Step 2
Use this command to display local and remote calling ID and IP address and port information.
Configuring FXS Hookflash Relay
A hookflash indication is a brief on-hook condition that occurs during a call. It is not long enough in duration to be interpreted as a signal to disconnect the call. Create a hookflash indication by quickly depressing and then releasing the hook on your telephone.
PBXs and telephone switches are frequently programmed to intercept hookflash indications and use them as a way to allow a user to invoke supplemental services. For example, your local service provider may allow you to enter a hookflash as a means of switching between calls if you subscribe to a call waiting service.
In the traditional telephone network, a hookflash results in a voltage change on the telephone line. Because there is no equivalent of this voltage change in an IP network, the ITU H.245 standard defines a message representing a hookflash. To send a hookflash indication using this message, an H.323 endpoint sends an H.245 user input indication message containing a "signal" structure with a value of "!". This value represents a hookflash indication.
Cisco H.323 Version 2 software includes limited support for relaying hookflash indications using the H.245 protocol. H.245 user input indication messages containing hookflash indications that are received on the IP call leg are forwarded to the plain old telephone service (POTS) call leg if the POTS interface is Foreign Exchange Office (FXO). If the interface is not FXO, any H.245 hookflash indication that is received is ignored. This support allows IP telephony applications to send hookflash indications to a PBX through the Cisco gateway and thereby invoke the IOS supplementary services of the PBX if the PBX supports access to those features using hookflash.
The gateway does not originate H.245 hookflash indications in this release. For example, it does not forward hookflash indications from foreign-exchange-station (FXS) interfaces to the IP network over H.245.
The acceptable duration of a hookflash indication varies by equipment vendor and by country. Although one PBX may consider a 250-ms on-hook condition to be a hookflash, another PBX may consider this condition to be a disconnect. Therefore, the timing hookflash-out command allows the administrator to define the duration of a hookflash signal generated on an FXO interface.
Figure 2 illustrates an FXS hookflash being translated to an H.245 user input.
Figure 2 Translating an FXS Hookflash to an H.245 User Input
In Cisco H.323 Version 2 software, an FXS hookflash relay is generated only if the following two conditions are met:
•
•
This implies that the VoIP dial peer is configured for dtmf-relay h245-alphanumeric or dtmf-relay h245-signal, but not cisco-rtp.
Enter the timing hookflash-input command on FXS interfaces to specify the maximum length of a hookflash indication. If the hookflash lasts longer than the specified limit, then the FXS interface processes the indication as an onhook.
To configure hookflash relay on a gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Multiple Codecs
Normally only one codec is specified when a dial peer is configured on a gateway. However, you can configure a prioritized list of codecs to increase the probability of establishing a connection between endpoints during the H.245 exchange phase.
Codec-order preservation enables a gateway to pass codec preferences to the terminating leg of a VoIP call. This feature was developed primarily for Cisco multiservice IP-to-IP gateways (IPIPGWs), which are configured to use a transparent codec. The transparent codec enables an IPIPGW to pass codecs from the originating endpoint to the terminating endpoint; however, previous versions of the IPIPGW did not preserve the preferential order of the codecs.
With codec-order preservation, the IPIPGW passes codecs transparently from the originating device, listed in order of preference, to the terminating device. It also enables gateways to pass user-configured codecs in their preferred order when the endpoints exchange capabilities, enabling endpoints to use the codec that best suits both devices.
Codec-order preservation is enabled by default in Cisco gateways running Cisco IOS Release 12.3(1) and later releases. No further configuration is needed.
To configure multiple codecs for a dial peer, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Verifying Preservation
To verify preservation, perform the following step.
Step 1
Use this command to verify the codecs defined for a particular prioritized list of codecs.
Router(config-dial-peer)# show running config
Configuring Rotary Calling Pattern
Rotary calling pattern routes an incoming call that arrives over a telephony interface back out through another telephony interface under certain circumstances. Rotary calling pattern primarily provides reliable service during network failures.
Call establishment using rotary calling pattern is supported by rotary group support of dial peers, where multiple dial peers may match a given destination phone number and be selected in sequence. In addition, if the destinations need to be tried in a certain order, preference may be assigned. Use the preference command when configuring the dial peers to reflect the preferred order (0 being the highest preference and 10 the lowest).
If several dial peers match a particular destination pattern, the system attempts to place a call to the dial peer configured with the highest preference. If the call cannot be completed because of a system outage (for example, the gatekeeper or gateway cannot be contacted), the rotary call pattern performs the following tasks:
•
•
•
If there are equal priority dial peers, the order is determined randomly.
Note
Configuring H.323 Support for Virtual Interfaces
H.323 support for virtual interfaces allows the IP address of the gateway to be configured so that the IP address included in the H.323 packet is always the source IP address of the gateway, regardless of the physical interface and protocol used. This single-address feature allows firewall applications to be easily configured to work with H.323 messages.
Configuring the Source IP Address of a Gateway
To configure a source IP address for a gateway, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying the Source IP Address of the Gateway
To verify the source IP address of the gateway, perform the following step.
Step 1
Use this command to verify the source IP address of the gateway. The output shows the source IP address that is bound to the interface.
router# show running-configinterface Loopback0ip address 10.0.0.0 255.255.255.0no ip directed-broadcasth323-gateway voip bind srcaddr 10.0.0.0!interface Ethernet0/0ip address 172.18.194.50 255.255.255.0no ip directed-broadcasth323-gateway voip interfaceh323-gateway voip id j70f_2600_gk2 ipaddr 172.18.194.53 1719h323-gateway voip h323-id j70f_3640_gw1h323-gateway voip tech-prefix 3#...In the following example, Ethernet interface 0/0 is used as the gateway interface. For convenience, the h323-gateway voip bind srcaddr command has been specified on the same interface. The designated source IP address is the same as the IP address assigned to the interface.
interface Ethernet0/0ip address 172.18.194.50 255.255.255.0no ip directed-broadcasth323-gateway voip interfaceh323-gateway voip id j70f_2600_gk2 ipaddr 172.18.194.53 1719h323-gateway voip h323-id j70f_3640_gw1h323-gateway voip tech-prefix 3#h323-gateway voip bind srcaddr 172.18.194.50
Configuring Annex G
This section contains the following information:
•
•
•
Information About Annex G
Annex G of the H.323 standard provides address resolution using border elements (BE). The BE (as described in Annex G) is colocated with the Cisco H.323 gatekeeper and provides additional address resolution capabilities. The BE can cache address information from neighboring BEs. When the gatekeeper receives a call that it cannot resolve, it can contact its local BE. If the address is in the BE's cache, the BE on the gatekeeper sends an AccessRequest to the BE in the terminating domain. If the address is not in the BE's cache, then the BE attempts to resolve the address by sending an AccessRequest to each of its neighboring BEs.
Note
Figure 3 illustrates a call flow for a scenario in which a call has originated in the zone administered by Border Element D, but the address cannot be resolved locally.
Figure 3 Address Resolution Using Border Elements
Table 2 describes how address resolution works in the illustration.
Configuring and Provisioning an Annex G Border Element
To configure and provision an Annex G border element, use the following commands beginning in global configuration mode.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
DETAILED STEPSConfiguring Basic Service Relationships
Cisco H.225 Annex G implementation supports the minimal set of Annex G features that are needed to allow Cisco border elements (BE) to interoperate with other BEs per the iNow profile for IP telephony interoperability. The implementation also allows Cisco BEs to interoperate with ClearingHouse and other third-party elements. Figure 4 depicts a basic network configuration of BEs, gatekeepers, and Clearing Houses. This feature addresses the link between the gatekeeper/border element (GK/BE) in a Cisco domain and the ClearingHouse border element that complies with the Annex G specification and the iNow profile.
Figure 4 Basic Network Configuration
Restrictions for Basic Service Relationships
•
•
•
•
•
•
•
Prerequisites for Basic Service Relationships
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPSConfiguring Usage Indication
To enter usage indication submode and configure usage-indicators after service relationships are established, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPSVerifying Annex G Configuration
To verify Annex G configuration, perform the following step.
Step 1
Use this command to display Annex G border-element status.
Router# show call-router status neighborsANNEX-G CALL ROUTER STATUS:===========================Border Element ID Tag : CelineDomain Name : Celine-DomainBorder Element State : UPBorder Element Local IP : 172.18.193.31:2099Advertise Policy : STATIC descriptorsHopcount Value : 7Descriptor TTL : 3180Access Policy : Neighbors onlyCurrent Active Calls : 0Current Calls in Cache : 0Cumulative Active Calls : 0Usage Ind Messages Sent : 0Usage Ind Cfm Rcvd : 0IRRs Received : 0DRQs Received : 0Usage Ind Send Retrys : 0NEIGHBOR INFORMATION:=====================Local Neighbor ID : (none)Remote Element ID : (unknown)Remote Domain ID : (unknown)IP Addr : 1.2.3.4:2099Status : DOWNCaching : OFFQuery Interval : 30 MIN (querying disabled)Usage Indications :Current Active Calls : 0Retry Period : 600 SECRetry Window : 3600 MINService Relationship Status: ACTIVEInbound Service Relationship : DOWNService ID : (none)TTL : 1200 SECOutbound Service Relationship : DOWNService ID : (none)TTL : (none)Retry interval : 120 SEC (0 until next attempt)
Configuring H.225
This section contains the following information:
•
•
•
•
•
•
•
Associating the H.323 Voice Class with Each VoIP Dial Peer
To associate the H.323 voice class with a dial peer, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSConfiguring the SETUP Response Timeout Value
To configure the timeout value for the response of the outgoing SETUP message, use the following commands in global configuration mode.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSConfiguring the Number of Concurrent Calls Per Connection
To limit the number of concurrent calls on an H.225 TCP connection, use the following commands in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSChanging the Idle Timer for Concurrent Calls
To change the H.225 idle timer for concurrent calls, use the following commands in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPSConfiguring Overlap Signaling on H.323 Terminating Gateways
The terminating gateway is responsible for collecting all the called number digits. Overlap signaling is implemented by matching destination patterns on the dial peers. When H.225 signal overlap is configured on the originating gateway, it sends the SETUP to the terminating gateway once a dial-peer match is found. The originating gateway sends all further digits received from the user to the terminating gateway using INFO messages until it receives a sending complete message from the user. The terminating gateway receives the digits in SETUP and subsequent INFO messages and does a dial-peer match. If a match is found, it sends a SETUP with the collected digits to the PSTN. All subsequent digits are sent to the PSTN using INFO messages to complete the call.
To configure overlap signaling on H.323 terminating gateways, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSConfiguring No Retry on User Busy in an H.323 Gateway
This section describes how to configure the alternate endpoint hunt for failed calls in an IP-to-IP Gateway (IPIPGW) based on Q.850 disconnect cause codes.
The default behavior of the gateway is to retry all alternate endpoints received from the gatekeeper regardless of the ReasonComplete reason. Perform this task if you want to stop the alternate endpoint hunt retry attempts when the ReasonComplete is User-busy or Invalid-number.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
voice service voip
Example:Router(config)# voice service voip
Enters voice service configuration mode and specifies a voice encapsulation type.
Step 4
h323
Example:Router(conf-voice-service)# h323
Enters H.323 configuration mode.
Step 5
no h225 alt-ep hunt user-busy
Example:Router(conf-serv-h323)# no h225 alt-ep hunt user-busyDisables alternate endpoint hunts.
•
•
Note
Note
Examples
The following example shows a configuration that disables the alternate endpoint hunt for user busy and no answer:
!
voice service voip
h323
no h225 alt-ep hunt user-busy
no h225 alt-ep hunt no-answer
!Configuring the VoIP Transport Method
To configure the VoIP transport method, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Zone Bandwidth Management
In the current version of the Cisco H.323 gateway (which conforms with H.323 version 3), the reported bandwidth is bidirectional. Initially, 128 kb is reserved. If the endpoints in the call select a more efficient codec, the gatekeeper is notified of the bandwidth change.
If you prefer to use the behavior of previous Cisco H.323 gateway versions for zone bandwidth management, configure the gateway accordingly.
To configure the Cisco H.323 gateway to use its previous behavior, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSConfiguring Generic Transparency Descriptor for GKTMP Using SS7 Interconnect for Voice Gateways Version 2.0
This section contains the following information:
•
•
•
Information About GTD for GKTMP Using SS7 Interconnect for Voice Gateways
The GTD for GKTMP Using SS7 Interconnect for Voice Gateways feature provides additional functionality to Cisco gateways and gatekeepers in a Cisco SS7 Interconnect for Voice Gateways Solution. The generic transparency descriptor or generic telephony descriptor (GTD) format is defined in the a Cisco-proprietary draft. GTD format defines parameters and messages of existing SS7 ISUP protocols in text format and allows SS7 messages to be carried as a payload in the H.225 RAS messages between gateway and gatekeeper. With the GTD feature, the gatekeeper extracts the GTD message and the external route server derives routing and accounting information based upon the GTD information provided from the Cisco Gatekeeper Transaction Message Protocol (GKTMP).
Currently routing on Cisco gateways is based on generic parameters such as originating number, destination number, and port source. Adding support for SS7 ISUP messages allows the VoIP network to use additional routing enhancements found in traditional TDM switches.
Figure 5 shows an example of a Cisco SS7 Interconnect for Voice Gateways solution using the GTD feature.
Figure 5 Cisco SS7 Interconnect for Voice Gateways Solution With the GTD Feature
In the originating network, the following events occur:
•
•
•
•
•
•
•
•
•
•
•
In the terminating network, the following events occur:
•
•
Prerequisites for GTD for GKTMP Using SS7 Interconnect for Voice Gateways
•
–
–
–
–
–
Note
Configuring GTD System-Wide
To configure the GTD feature system-wide for a VoIP network, enter the commands shown below. If you want to configure the feature on individual dial peers rather than system-wide, use the commands in the "Configuring GTD for a Dial Peer" section.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSConfiguring GTD for a Dial Peer
To configure the GTD feature on an individual dial peer, follow the steps below.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSVerifying GTD
To verify GTD, perform the following step.
Step 1
Use this command to verify that the GTD feature is configured.
The following shows sample output for system-wide employment.
Router# show running-configBuilding configuration...Current configuration : 4192 bytes!version 12.2service configno service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice udp-small-servers!hostname as5300-2!voice service voipsignaling forward unconditionalh323...The following shows sample output for employment on select dial peers.
Router# show running-configBuilding configuration...Current configuration : 4192 bytes!version 12.2service configno service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice udp-small-servers!hostname as5300-2!...!dial-peer voice 1 potsapplication sessionincoming called-number 25164port 0:D!dial-peer voice 1513 voipdestination-pattern 1513.......session target ipv4:1.8.156.3!dial-peer voice 1408525 voipdestination-pattern 1408525....!dial-peer voice 1800877 voipdestination-pattern 1800877....session target ipv4:1.8.156.3!dial-peer voice 2 potsdestination-pattern 51550no digit-stripdirect-inward-dialport 3:D!dial-peer voice 51557 voipdestination-pattern 51557signaling forward unconditionalsession target ras!dial-peer voice 52557 voipdestination-pattern 52557signaling forward unconditionalsession target ipv4:1.8.156.3!...
Configuring H.323 Version 4 Zone Prefix Registration
The H.323v4 Gateway Zone Prefix Registration Enhancements feature provides support for two capabilities included in H.323 Version 4: additive registration and dynamic zone prefix registration. Additive registration allows a gateway to add to or modify a list of aliases contained in a previous registration without first unregistering from the gatekeeper. Dynamic zone prefix registration allows a gateway to register actual public switched telephone network (PSTN) destinations served by the gateway with its gatekeeper.
Information About H.323v4 Gateway Zone Prefix Registration Enhancements
To configure the H.323v4 Gateway Zone Prefix Registration Enhancements feature, you must understand the following concepts:
•
Additive Registration
Prior to H.323 version 4, there was no way for a large device, such as a gateway, to register hundreds or thousands of E.164 alias addresses with a gatekeeper. The limiting factor was the size of a User Datagram Protocol (UDP) packet, which does not allow an unlimited number of aliases in a single heavyweight registration request (RRQ) RAS message.
To allow an endpoint to register an unlimited number of aliases with the gatekeeper, H.323v4 introduces the concept of additive registration. When the gateway registers with a gatekeeper, it provides an initial list of aliases. Additive registration allows the gateway to send subsequent RRQ messages with more lists of aliases until the gatekeeper has the complete list of the gateway's aliases.
When the gatekeeper wants to acknowledge only a subset of the aliases proposed in an additive RRQ, the gatekeeper returns a registration confirm (RCF) RAS message specifying the accepted aliases. The gateway assumes that the aliases not listed in the RCF were rejected.
Dynamic Zone Prefix Registration
H.323v4 allows a gateway to register actual zone prefixes that it can terminate to the PSTN with a gatekeeper. A gateway can register multiple zone prefixes with the gatekeeper via the RRQ message and subsequently remove one or more zone prefixes using an unregistration request (URQ) RAS message indicating the specific prefixes to be removed. When the gatekeeper receives the URQ, it leaves the gateway registered and removes the specified zone prefixes.
When the H.323v4 Gateway Zone Prefix Registration Enhancements feature is enabled on a trunking gateway, all addresses specified by the destination patterns in the plain old telephone service (POTS) dial peers that are operational are advertised to the gatekeeper.
The gatekeeper treats these addresses similarly to configured zone prefixes. The dynamically registered zone prefixes are used in routing decisions just as if they had been entered using the zone prefix command. Dynamically registered zone prefixes have a default gateway priority of 5.
Table 3 shows destination patterns on gateway GW1 and how the gatekeeper GK1 views the dynamically registered prefixes.
Configuring H.323v4 Gateway Zone Prefix Registration Enhancements
This section contains the following tasks:
•
•
•
•
•
Enabling the Dynamic Zone Prefix Registration
This task shows you how to enable the gateway to send an advertisement of dynamic prefixes in additive RRQ RAS messages automatically to the gatekeeper.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPSEnabling the Dynamic Zone Prefix Registration Along with the Gateway Priority
This task shows you how to configure the priority to the dynamic prefixes on the gateway. Allowing you to configure a different priority to each of the dynamic prefix. When configured, the gateway sends the priority along with the prefixes in additive RRQ and the gatekeeper assigns the received priority to the gateway for a given dynamic prefix.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPSVerifying Gateway Advertisement of Dynamic Zone Prefixes
Perform this task to verify that the gateway is advertising dynamic zone prefixes.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPSVerifying Gatekeeper Processing of Additive RRQ Messages
Perform this task to verify that the gatekeeper is processing additive RRQ messages.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Troubleshooting H.323v4 Gateway Zone Prefix Registration Enhancements
Use the debug h225 asn1 command to observe the dynamic registration process. The debug h225 asn1 command is intended only for troubleshooting purposes because the volume of output generated by the software can result in severe performance degradation on the router.
Prerequisites
Attach a console directly to a router running Cisco IOS Release 12.2(15)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Configuring Call Admission Control
Cisco H.323 gateways provide the ability to support resource-based call admission control (CAC) processes. These resources include system resources such as CPU, memory, and call volume, and interface resources such as call volume.
If system resources are not available to admit the call, two kinds of actions are provided: system denial which busyouts all of T1 or E1 or per call denial, which disconnects, hairpins, or plays a message or tone. If the interface-based resource is not available to admit the call, the call is dropped from the session protocol.
Note
Configuring Trunk-Based and Carrier-Based Routing
Voice wholesalers use multiple ingress and egress carriers to route traffic. A call coming into a gateway on a particular ingress carrier must be routed to an appropriate egress carrier. As networks grow and become more complicated, the dial plans needed to route the carrier traffic efficiently become more complex and the need for carrier-sensitive routing (CSR) increases.
Note
Configuring Signal ISDN B-Channel ID to Enable Application Control of Voice Gateway Trunks
This section contains the following information:
•
•
•
Information About Signal ISDN B-Channel ID
The Signal ISDN B-Channel ID to Enable Application Control of Voice Gateway Trunks feature enables call-management applications to identify specific ISDN bearer (B) channels used during a voice-gateway call for billing purposes. With identification of the B channel, H.323 gateways can enable port-specific features such as voice recording and call transfer.
In Cisco IOS releases prior to 12.3(7)T, fields used to store call leg information regarding the telephony port do not include B channel information. B-channel information is used to describe incoming ISDN call legs. The Signal ISDN B-Channel ID to Enable Application Control of Voice Gateway Trunks feature allows H.323 and SIP gateways to receive B-channel information from incoming ISDN calls. The acquired B-channel information can be used during call transfer or to route a call.
SIP and H.323 gateways use two different commands to enable receiving the B channel of a telephony call leg. Using a different command for each protocol allows users to run the two protocols on one gateway simultaneously.
Note
For H.323, if the billing b-channel command is configured, the H.323 gateway accesses B-channel information on all calls in the ARQ, LRQ, and GKTMP messages.
Configuring Signal ISDN B-Channel ID
To provide H.323 users with B-channel information, use the following commands beginning in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Troubleshooting Signal ISDN B-Channel ID
To troubleshoot signal ISDN B-channel ID problems, perform the following steps.
Step 1
Use this command to display ASN1 contents of H.245 messages.
The following sample command output shows an H.323 ARQ nonstandard message. The format of the B-channel billing information is: 1 is the D-channel ID, 1 is the T1 controller, and 10 is the B-channel.
Router# debug h245 asn1...value ARQnonStandardInfo ::={sourceAlias{}sourceExtAlias{}interfaceSpecificBillingId 1:D 1:DS1 10:DS0gtd '49414D2C0D0A50524E2C6973646E2A2C2...'H}...Step 2
Use this command on gatekeeper to trace all the message exchanges between a gatekeeper and an external application. It also displays any errors that occur in sending messages to the external application or in parsing messages from the external application.
The following sample command output also shows B-channel information. The format of the B-channel billing information is as follows: 1 is the D-channel ID, 1 is the T1 controller, and 10 is the B-channel.
Router# debug gatekeeper servers"REQUEST ARQVersion-id:402From:voip6-2600-1To:GKTMP_SERVERTransaction-Id:81A3EB4000000001Content-Length:258i=I:1.3.26.21:1720s=E:9190001 H:voip6-5300-1d=E:4080001b=1280A=FC=C13CB8DE-C47F-11D3-80A9-FC0BFCA7B068c=C13D5506-C47F-11D3-80AB-FC0BFCA7B068B= 1:D 1:DS1 10:DS0
Configuring H.323 VoIP Call Preservation Enhancements for WAN Link Failures
H.323 VoIP call preservation enhancements for WAN link failures sustains connectivity for H.323 topologies where signaling is handled by an entity that is different from the other endpoint, such as a gatekeeper that provides routed signaling or a call agent, such as the Cisco BTS 10200 Softswitch, Cisco PGW 2200, or Cisco CallManager, that brokers signaling between the two connected parties.
Call preservation is useful when a gateway and the other endpoint (typically an Cisco Unified IP phone) are collocated at the same site and the call agent is remote and therefore more likely to experience connectivity failures.
Note
H.323 call preservation covers the following types of failures and connections:
Failure Types
•
•
•
Connection Types
•
–
–
–
–
•
–
–
–
•
Note that after the media is preserved, the call is torn down later when either one of the parties hangs up or media inactivity is detected. In cases where there is a machine-generated media stream, such as music streaming from a media server, the media inactivity detection will not work and the call may hang. Cisco Unified CallManager addresses such conditions by indicating to the gateway that such calls should not be preserved, but third-party devices or IPIP gateways would not do this.
Flapping is defined for this feature as the repeated and temporary loss of IP connectivity that can be caused by WAN or LAN failures. H.323 VoIP calls between a Cisco IOS gateway and Cisco Unified CallManager may be torn down when flapping occurs. When Cisco Unified CallManager detects that the TCP connection is lost, it clears the call and closes the TCP sockets used for the call by sending a TCP FIN, without sending an "H.225.0 Release Complete" or "H.245 End Session" message. This is called quiet clearing. The TCP FIN sent from the Cisco Unified CallManager could reach the gateway if the network comes up for a short duration, and the gateway will tear the call down. Even if the TCP FIN does not reach the gateway, the TCP keepalives sent from the gateway could reach Cisco Unified CallManager when the network comes up. Cisco Unified CallManager will send TCP RST messages in response to the keepalives as it has already closed the TCP connection. The gateway will tear down H.323 calls if it receives the RST message.
Configuration of H.323 VoIP call preservation enhancements for WAN link failures involves configuring the call preserve command. If you are using Cisco Unified CallManager you must enable the "Allow Peer to Preserve H.323 Calls" parameter from Cisco Unified CallManager's Service Parameters window.
The call preserve command causes the gateway to ignore socket closure or socket errors on H.225.0 or H.245 connections for active calls, allowing the socket to be closed without tearing down calls using those connections.
Call preservation may be reported through Syslog, which optionally can be obtained through a simple network management protocol (SNMP) trap. New syslog messages are printed when call preservation is applied. An SNMP trap can be configured on this syslog message, so you can be notified when call preservation occurs on a gateway.
Preservation information is displayed through the show h323 calls preserved command. The following is an example of the command's output:
CallID = 11EC , Calling Number = , Called Number = 3210000 , RemoteSignallingIPAddress=9.13.0.26 , RemoteSignallingPort=49760 , RemoteMediaIPAddress=9.13.0.11 , RemoteMediaPort=17910 , Preserved Duration = 262 , Total Duration = 562 , H225 FD = -1 , H245 FD = -1The previous example represents one preserved call. One such display is provided per preserved call. The show h323 calls preserved displays active calls only. No history is output.
To obtain additional information about a call, you can also use the show call active voice command. Calls can be cleared with the clear call voice causecode command.
Prerequisites
•
•
•
Restrictions
H.323 VoIP Call preservation enhancements for WAN link failures does not support the following:
•
•
•
•
•
•
Configuring H.323 Call Preservation Enhancements for WAN Link Failures
The tasks for configuring H.323 VoIP call preservation enhancements for WAN link failures include the following:
•
Configuring the Gateway
The call preserve command activates H.323 VoIP call preservation. RTP and RTCP inactivity detection and bidirectional silence detection can be used with this feature. Note that voice activity detection (VAD) must be set to off if you are using RTP and RTCP inactivity detection. VAD may be set to on, for bidirectional silence detection. For configuration examples, see the "RTP and RTCP Inactivity Detection Configuration Example" section and "Bidirectional Silence Detection Enable Example" section.
When bidirectional silence and RTP and RTCP inactivity detection are configured, they are enabled for all calls by default. To enable them for H.323 VoIP preserved calls only, you must use the call preserve command's limit-media-detection keyword.
H.323 VoIP call preservation can be applied to all calls and to dial peers. The required steps are described in the following sections:
•
•
Configuring H.323 VoIP Call Preservation for All Calls
The following describes how to configure H.323 VoIP call preservation for all calls.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Examples
The following configuration example enables H.323 VoIP call preservation for all calls.
voice service voiph323call preserveThe following configuration example enables H.323 VoIP call preservation and limits RTP and RTCP inactivity detection and bidirectional silence detection (if configured) to preserved calls only:
voice service voiph323call preserve limit-media-detectionConfiguring H.323 VoIP Call Preservation for a Dial Peer
The following describes how to configure H.323 VoIP call preservation for a dial peer.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPSExamples
The following configuration example enables H.323 VoIP call preservation for dial peer 1.
voice-class h323 4call preservedial-peer voice 1 voipvoice-class h323 4Troubleshooting Tips
•
Nov 29 12:39:55.167: %VOICE_IEC-3-GW: H323: Internal Error (Socket error):•
Router# debug h225 asnH.225 ASN1 Messages debugging is on3725-GW1#*May 3 15:57:27.920: H225.0 INCOMING ENCODE BUFFER::= 28501900060008914A00040000D2D6D6D87EB11D02000000090D194410A00100110140B50000120A80A480 04000101000100*May 3 15:57:27.920:*May 3 15:57:27.920: H225.0 INCOMING PDU ::=value H323_UserInformation ::={h323-uu-pdu{h323-message-body notify :{protocolIdentifier { 0 0 8 2250 0 4 }callIdentifier{guid '00D2D6D6D87EB11D02000000090D1944'H}}h245Tunneling FALSEnonStandardControl{{nonStandardIdentifier h221NonStandard :{t35CountryCode 181t35Extension 0manufacturerCode 18}data '80A48004000101000100'H}}}}*May 3 15:57:27.924: H225 NONSTD INCOMING ENCODE BUFFER::= 80A48004000101000100*May 3 15:57:27.924:*May 3 15:57:27.924: H225 NONSTD INCOMING PDU ::=value H323_UU_NonStdInfo ::={callMgrParam{interclusterVersion 1enterpriseID {}}callPreserveParam{callPreserveIE FALSE}}When the call is resumed, "callPreserve" is again set to True as shown in the following output example:
Router# debug h225 asn*May 3 15:57:32.676: H225.0 INCOMING ENCODE BUFFER::= 28501900060008914A00040000D2D6D6D87EB11D02000000090D194410A001001B0140B50000121480A680 04000101000943004C0580323030300140*May 3 15:57:32.676:*May 3 15:57:32.676: H225.0 INCOMING PDU ::=value H323_UserInformation ::={h323-uu-pdu{h323-message-body notify :{protocolIdentifier { 0 0 8 2250 0 4 }callIdentifier{guid '00D2D6D6D87EB11D02000000090D1944'H}}h245Tunneling FALSEnonStandardControl{{nonStandardIdentifier h221NonStandard :{t35CountryCode 181t35Extension 0manufacturerCode 18}data '80A68004000101000943004C0580323030300140'H}}}}*May 3 15:57:32.680: H225 NONSTD INCOMING ENCODE BUFFER::= 80A68004000101000943004C0580323030300140*May 3 15:57:32.680:*May 3 15:57:32.680: H225 NONSTD INCOMING PDU ::=value H323_UU_NonStdInfo ::={callMgrParam{interclusterVersion 1enterpriseID {}}callSignallingParam{connectedNumber '4C058032303030'H}callPreserveParam{callPreserveIE TRUE}}•
Router# debug cch323 all(CCH323-6-CALL_PRESERVED).Nov 29 12:39:55.167: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 3 Event 0x1Nov 29 12:39:55.167: //31/A9E0FB268017/H323/cch323_h225_handle_conn_loss: cch323_h225_handle_conn_loss Call not torn down despite H.225.0 socket error: socket error status = 1, ccb status = 403760899, fd = 3, pre-V3 = 0Nov 29 12:39:55.167: %CCH323-6-CALL_PRESERVED: cch323_h225_handle_conn_loss: H.323 call preserved due to socket closure or error, Call Id = 4593, fd = 3Nov 29 12:39:55.167: %VOICE_IEC-3-GW: H323: Internal Error (Socket error): IEC=1.1.186.5.7.6 on callID 31 GUID=A9E0FB26600B11DA8017000653455072Nov 29 12:39:55.167: //-1/xxxxxxxxxxxx/H323/h323_set_release_source_for_peer: ownCallId[31], src[6]Nov 29 12:39:55.167: //-1/xxxxxxxxxxxx/H323/h323_gw_clean_send_blocked_watch: fd 3Nov 29 12:39:55.167: //-1/xxxxxxxxxxxx/H323/cch323_cleanup_xport: hashDestroy for TcpFDTbl•
–
–
–
Configuring Cisco Unified CallManager
If you are using Cisco Unified CallManager, you must activate H.323 call preservation through the "Allow Peer to Preserve H.323 Calls" parameter, which preserves the following:
•
•
•
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Configuration Examples for H.323 Gateways
This section provides the following configuration examples:
•
•
•
•
•
•
RAS: Example
Figure 6 shows a Cisco 2600 and a Cisco AS5800 as gateways and a Cisco 3640 as a gatekeeper.
Figure 6 VoIP for the Cisco AS5800
The following example shows a Cisco AS5800 as a gateway using RAS:
! Configure the T1 controller. (This configuration is for a T3 card.)controller T1 1/0/0:1framing esflinecode b8zspri-group timeslots 1-24!! Configure POTS and VoIP dial peers.dial-peer voice 11111 potsincoming called-number 12345destination-pattern 9#11111direct-inward-dialport 1/0/0:1:Dprefix 11111!dial-peer voice 12345 voipdestination-pattern 12345tech-prefix 6#session target ras!! Enable gateway functionality.gateway!! Enable Cisco Express Forwarding.ip cef!! Configure and enable the gateway interface.interface FastEthernet0/3/0ip address 172.16.0.0.255.255.255.0no ip directed-broadcastno keepalivefull-duplexno cdp enableh323-gateway voip interfaceh323-gateway voip id gk3.gg-dn1 ipaddr 172.18.0.0 1719h323-gateway voip h323-id gw3@gg-dn1h323-gateway voip tech-prefix 9#!! Configure the serial interface.(This configuration is for a T3 serial interface.)interface Serial1/0/0:1:23no ip addressno ip directed-broadcastip mroute-cacheisdn switch-type primary-5essisdn incoming-voice modemno cdp enableGateway Security: Example
H.323 Gateway Security
The following example illustrates H.323 security configuration on a Cisco AS5300 gateway.
hostname um5300!enable password xyz!resource-pool disable!clock timezone EST -5clock summer-time EDT recurringip subnet-zerono ip domain-lookup!isdn switch-type primary-5essisdn voice-call-failure 0call application voice xyz tftp://172.18.16.2/samp/xyz.tclcall application voice load xysmta receive maximum-recipients 1024!xgcp snmp sgcp!controller T1 0framing esfclock source line primarylinecode b8zspri-group timeslots 1-24!controller T1 1framing esfclock source line secondary 1linecode b8zspri-group timeslots 1-24!controller T1 2!controller T1 3!voice-port 0:D!voice-port 1:D!dial-peer voice 4001 potsapplication xyzdestination-pattern 4003port 0:Dprefix 4001!dial-peer voice 513 voipdestination-pattern 1513200....session target ras!dial-peer voice 9002 voipdestination-pattern 9002session target ras!dial-peer voice 4191024 potsdestination-pattern 4192001024port 0:Dprefix 4001!dial-peer voice 1513 voipdestination-pattern 1513.......session target ras!dial-peer voice 1001 potsdestination-pattern 14192001001port 0:D!gatewaysecurity password 151E0A0E level all!interface Ethernet0ip address 10.99.99.7 255.255.255.0no ip directed-broadcastshutdown!interface Serial0:23no ip addressno ip directed-broadcastisdn switch-type primary-5essisdn protocol-emulate userisdn incoming-voice modemfair-queue 64 256 0no cdp enable!interface Serial1:23no ip addressno ip directed-broadcastisdn switch-type primary-5essisdn protocol-emulate userisdn incoming-voice modemisdn guard-timer 3000isdn T203 10000fair-queue 64 256 0no cdp enable!interface FastEthernet0ip address 172.18.72.121 255.255.255.192no ip directed-broadcastduplex autospeed autoh323-gateway voip interfaceh323-gateway voip id um5300@vgkcisco3 ipaddr 172.18.72.58 1719h323-gateway voip h323-id um5300h323-gateway voip tech-prefix 1#!no ip http serverip classlessip route 10.0.0.0 172.18.72.65!!line con 0exec-timeout 0 0length 0transport input noneline aux 0line vty 0 4password xyzlogin!ntp clock-period 17179974ntp server 172.18.72.124H.235 Gateway Security
The following example shows output from configuring secure registrations from the gatekeeper and identifying which RAS messages the gatekeeper checks to find authentication tokens:
dial-peer voice 10 voipdestination-pattern 4088000session target rasdtmf-relay h245-alphanumeric!gatewaysecurity password 09404F0B level endpointThe following example shows output from configuring which RAS messages contain gateway-generated tokens:
dialer-list 1 protocol ip permitdialer-list 1 protocol ipx permitradius-server host 10.25.0.0 auth-port 1645 acct-port 1646radius-server retransmit 3radius-server deadtime 5radius-server key labradius-server vsa send accounting!gatekeeperzone local GK1 test.com 10.0.0.3zone remote GK2 test2.com 10.0.2.2 1719accountingsecurity token required-for registrationno use-proxy GK1 remote-zone GK2 inbound-to terminalno use-proxy GK1 remote-zone GK2 inbound-to gatewayno shutdownAlternate Gatekeeper Support: Example
In the following example, the gateway is configured to have alternate gatekeepers. The primary and secondary gatekeepers are configured with the priority option. The priority range is 1 to 127. The first alternate gatekeeper is configured as priority 120; the second alternate gatekeeper is not configured, so remains at the default setting of 127.
interface Ethernet 0/1ip address 172.18.193.59 255.255.255.0h323-gateway voip interfaceh323-gateway voip id GK1 ipaddr 172.18.193.65 1719 priority 120h323-gateway voip id GK2 ipaddr 172.18.193.66 1719h323-gateway voip h323-id cisco2DTMF Relay: Example
The following example configures DTMF relay with the cisco-rtp keyword when sending DTMF tones to dial peer 103:
dial-peer voice 103 voipdtmf-relay cisco-rtpThe following example configures DTMF relay with the cisco-rtp or h245-signal keywords when DTMF tones are sent to dial peer 103:
dial-peer voice 103 voipdtmf-relay cisco-rtp h245-signalThe following example configures the gateway to send DTMF in-band (the default) when DTMF tones to are sent dial peer 103:
dial-peer voice 103 voipno dtmf-relayThe following example shows that DTMF relay is configured on an H.323 gateway using NTE RTP and H.245 signaling. In this example, the Named Signaling Event (NSE) value in use is reassigned to a different, unassigned number (110). NTE payload is then assigned to the previously used value (100).
dial-peer voice 400 voipdestination-pattern 400dtmf-relay rtp-nte h245-signalrtp payload nse 110rtp payload-type nte 100session target ipv4:172.18.193.181Multiple Codecs: Example
The following configuration shows how to create a list of prioritized codecs and apply that list to a specific VoIP dial peer:
voice class codec 99codec preference 1 g711alawcodec preference 2 g711ulaw bytes 80codec preference 3 g723ar53codec preference 4 g723ar63 bytes 144codec preference 5 g723r53codec preference 6 g723r63 bytes 120codec preference 7 g726r16codec preference 8 g726r24codec preference 9 g726r32 bytes 80codec preference 10 g728codec preference 11 g729br8codec preference 12 g729r8 bytes 50!dial-peer voice 1919 voipvoice-class codec 99Rotary Calling Pattern: Example
The following example configures POTS dial peer 10 for a preference of 1, POTS dial peer 20 for a preference of 2, and Voice over Frame Relay dial peer 30 for a preference of 3:
dial-peer voice 10 potsdestination pattern 5552150preference 1dial-peer voice 20 potsdestination pattern 5552150preference 2dial-peer voice 30 vofrdestination pattern 5552150preference 3H.323 Support for Virtual Interfaces: Example
In the following example, Ethernet interface 0/0 is used as the gateway interface. For convenience, the h323-gateway voip bind srcaddr command is specified on the same interface. The designated source IP address is the same as the IP address assigned to the interface.
interface Ethernet0/0ip address 172.18.194.50 255.255.255.0no ip directed-broadcasth323-gateway voip interfaceh323-gateway voip id j70f_2600_gk2 ipaddr 172.18.194.53 1719h323-gateway voip h323-id j70f_3640_gw1h323-gateway voip tech-prefix 3#h323-gateway voip bind srcaddr 172.18.194.50H.225 Annex-G: Example
The following example shows the gatekeeper border element router with service relationship and usage-reporting functionality turned on:
Router# show running configBuilding configuration......call-router h323-annexg boston1neighbor 1.2.3.4service-relationshipoutbound retry interval 120inbound ttl 1200no shutdownusage-indicationretry interval 600retry window 3600domain-name Celine-Domainaccess-policy neighbors-onlylocal ip 172.18.193.31no shutdown...GTD Payload: Examples
GTD Payload System-Wide
The following example shows the GTD feature configured on the system:
Router# show running-configBuilding configuration...Current configuration : 4192 bytes!version 12.2service configno service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice udp-small-servers!hostname as5300-2!voice service voipsignaling forward unconditionalh323!...GTD Payload on a Dial Peer
The following example shows GTD configured with unconditional forwarding on two dial peers:
Router# show running-configBuilding configuration...Current configuration : 4192 bytes!version 12.2service configno service single-slot-reload-enableno service padservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice udp-small-servers!hostname as5300-2!...!dial-peer voice 1 potsapplication sessionincoming called-number 25164port 0:D!dial-peer voice 1513 voipdestination-pattern 1513.......session target ipv4:1.8.156.3!dial-peer voice 1408525 voipdestination-pattern 1408525....!dial-peer voice 1800877 voipdestination-pattern 1800877....session target ipv4:1.8.156.3!dial-peer voice 2 potsdestination-pattern 51550no digit-stripdirect-inward-dialport 3:D!dial-peer voice 51557 voipdestination-pattern 51557signaling forward unconditionalsession target ras!dial-peer voice 52557 voipdestination-pattern 52557signaling forward unconditionalsession target ipv4:1.8.156.3!gateway!..H.323v4 Gateway Zone Prefix Registration Enhancements: Examples
Verifying Gateway Advertisement of Dynamic Zone Prefixes
The following example displays the status of the destination pattern database and the status of the individual destination patterns for Gatekeeper1:
Gateway1# show h323 gateway prefixesGK Supports Additive RRQ : TrueGW Additive RRQ Support Enabled : TruePattern Database Status : ActiveDestination ActivePattern Status Dial-Peers================================================================1110509* ADD ACKNOWLEDGED 21110511* ADD ACKNOWLEDGED 223* ADD ACKNOWLEDGED 2Verifying Gatekeeper Processing of Additive RRQs Example
The following example displays the zone prefix table, including the dynamic zone prefixes, for Gatekeeper1:
Gatekeeper1# show gatekeeper zone prefix allZONE PREFIX TABLE===============================================GK-NAME E164-PREFIX Dynamic GW-priority------- ----------- -------------------gatekeeper1 1110507* gateway2 /5gatekeeper2 1110508*gatekeeper1 1110509* gateway1 /5gatekeeper1 1110511* gateway1 /5gatekeeper1 23* gateway1 /5gatekeeper1 4666002*gatekeeper3 55530..
