Downloads |
Table Of Contents
Improved Gateway Selection Process
Gateway Resource Availability Reporting
Support for Single Proxy Configurations
Registration of E.164 Addresses for Gateway-Attached Devices
Tunneling of Redirecting Number Information Element
Related Features and Technologies
Supported Standard MIBs and RFCs
Gatekeeper Configuration Tasks
show gatekeeper gw-type-prefix
show call resource voice stats
show call resource voice threshold
H.323 Version 2 Support
Feature History
This feature module describes Cisco H.323 Version 2 Support. Included here is an overview of the feature including the benefits, the prerequisites, the supported platforms, the configuration tasks, and a command reference of new and changed commands.
This document includes the following sections:
•
Supported Standard MIBs and RFCs
Feature Overview
Cisco H.323 Version 2 Support upgrades Cisco IOS software to comply with the mandatory requirements and several of the optional features of the version 2 specification. This upgrade enhances the existing Voice Over IP Gateway, the Multimedia Conference Manager (Gatekeeper and Proxy). Future releases will add additional H.323 Version 2 features to the Cisco IOS software.
H.323 Version 2 Compliance
Cisco H.323 Version 2 support enables gatekeepers, gateways, and proxies to send and receive all the required fields in H.323 v2 messages.
Lightweight Registration
Prior to H.323 Version 2, Cisco gateways reregistered with the gatekeeper every 30 seconds. Each registration renewal used the same process as the initial registration, even though the gateway was already registered with the gatekeeper. This generated considerable overhead at the gatekeeper.
H.323 version 2 defines a lightweight registration procedure that still requires the full registration process for initial registration, but uses an abbreviated renewal procedure to update the gatekeeper and minimize overhead.
Lightweight registration requires each endpoint to specify a TimeToLive (TTL) value in its Registration Request (RRQ) message. When a gatekeeper receives a RRQ message with a TTL value, it returns an updated TTL timer value in a Registration Confirmation (RCF) message to the endpoint. Shortly before the TTL timer expires, the endpoint sends an RRQ message with KeepAlive field set to TRUE, which refreshes the existing registration.
An H.323 v2 endpoint is not required to indicate a time-to-live in its registration request. If the endpoint does not indicate a time-to-live, the gatekeeper assigns one and sends it to the gateway in the RCF message. No configuration changes are permitted during a lightweight registration, so all fields other than the endpointIdentifier, gatekeeperIdentifier, tokens, and time-to-live are ignored. In the case of H.323v1 endpoints that cannot process the time-to-live field in the RCF, the gatekeeper probes the endpoint with IRQs for a predetermined grace period to see if the endpoint is still alive.
Improved Gateway Selection Process
Prior to H.323 version 2, the gatekeeper selected a destination gateway by choosing gateways defined with zone prefix commands. This command assigns a dialing prefix to a zone and allows the use of wildcards in the dialing prefix. In version 1, the gatekeeper simply matched the destination number with the longest match in the defined dialing prefixes, and randomly selected a gateway registered in that zone.
The H.323 version 2 software improves the gateway selection process as follows:
•
•
The gatekeeper maintains a separate gateway list, ordered by priority, for each of its zone-prefixes. If a gateway does not have an assigned priority for a zone-prefix, it defaults to priority 5, which is the median. To explicitly bar the use of a gateway for a zone prefix, define it as having a priority 0 for that zone prefix.
When selecting gateways, the gatekeeper identifies a target pool of gateways by performing a longest zone-prefix match; then it selects from the target pool according to priorities and resource availability. If all high-priority gateways are busy, a low-priority gateway might be selected.
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 DSO channels and DSP channels. In release 12.0(5)T,this feature is available only on the AS5300 platform.
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 an RAI to the gatekeeper indicating that the gateway is almost out of resources. When the available resources then cross above another configurable threshold, the gateway sends an RAI indicating that the resource depletion condition no longer exists.
Resource reporting thresholds are configured by using the "resource threshold" command. The upper and lower thresholds are separately configurable to prevent the gateway from operating sporadically due to the availability or lack of resources.
Support for Single Proxy Configurations
In previous releases, the gatekeeper supported two-proxy and no-proxy call scenarios. The destination gatekeeper decided whether a call would be proxied or direct based on its zone configuration. The source gatekeeper would pick a proxy for its outbound calls only when the destination gatekeeper returned its inbound proxy in the location confirm message. This version of the gatekeeper software adds support for single-proxy calls and the option to independently configure proxies for inbound and outbound call scenarios.
Registration of E.164 Addresses for Gateway-Attached Devices
The H.323 version 2 gateway now supports the registration of fully-qualified E.164 numbers with the gatekeeper for phones connected directly to the gateway. To register these E.164 numbers, use the register command when configuring the gateway.
Tunneling of Redirecting Number Information Element
An incoming PRI SETUP message may contain either a Redirecting Number (RDN) Information Element (IE) or an Original Called Number (OCN) IE. These IEs indicate that the call has been redirected (forwarded), and that each message contains the following:
•
•
•
OCN IE is a Nortel variant of the RDN IE. The OCN IE is supported as a nonStandardData.
The H.323 Version 2 gateway propagates the entire RDN or OCN IE from an incoming PRI message into the H.225 SETUP message. The IE is encapsulated in the nonStandardData field within the user-to-user information element (UUIE) of the H.225 SETUP message. The nonStandardData field contain the encapsulated RDN or OCN IE and a tunneled QSIG message, or it contained only the OCN or RDN. Cisco and other third-party H.323 endpoints can access the redirected information by decoding the nonStandardData field. In accordance with the H.225 specification, the nonStandardData is ignored by third-party endpoints and caused no interoperability problems.
For redirected PRI calls that are routed to a Cisco gateway, sent using H.323 to another Cisco Gateway, and exit the gateway using PRI, the RDN/OCN IE is tunneled from the source gateway to the destination gateway. The incoming PRI SETUP message is tunneled through H.323/H.225, and is encoded into the outgoing PRI SETUP message by the destination gateway.
Tunneling the RDN or OCN IE is important for applications such as Unified Messaging servers that need to know the telephone number that was originally dialed to access the correct account information.
DTMF-Relay
Dual-Tone Multifrequency (DTMF) is the tone generated on a touch-tone phone when you press keypad digits. During a call you might enter DTMF to access Interactive Voice Response (IVR) systems such as voicemail, automated banking services and so on.
In previous releases of IOS, DTMF is transported in the same way as voice. This approach can result in problems accessing IVR systems. While DTMF is usually transported accurately when using high-bitrate voice CODECs such as G.711, low-bitrate 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. Cisco H.323 Version 2 support introduces three options for sending DTMF tones out of band. These are:
•
•
•
If none of these options is selected, DTMF tones are transported inband, and encoded in the same way as voice traffic.
The "cisco-rtp" option sends DTMF tones in the same RTP channel as voice. However, the DTMF tones are encoded differently from the voice samples and are identified by a different RTP payload type code. Use of this method accurately transports DTMF tones, but since it is proprietary it requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.
The "h245-signal" and "h245-alphanumeric" options are modes of DTMF transport defined by the ITU H.245 standard. These methods separate DTMF digits from the voice stream and send them through the H.245 signalling channel instead of the RTP channel. The tones are transported in H.245 User Input Indication messages. The H.245 signalling channel is a reliable channel, so the packets transporting the DTMF tones are guaranteed to be delivered. However, because of the overhead of using a reliable protocol, and depending on network congestion conditions, the DTMF tones may be slightly delayed. This delay is not known to cause problems with existing applications.
The "h245-signal" option relays a more accurate representation of a DTMF digit than the "h245-alphanumeric" option, in that tone duration information is included along with the digit value. This information is important for applications that require you to press a key for a particular length of time. For example, one popular calling card feature allows you to break out of an existing call by pressing the (#) key for more than two seconds and then make a second call without having to hang up in between. This feature is beneficial because it allows you to avoid having to dial your access number and PIN code again, and it allows you to avoid access charges if you are charged for accessing an outside line as is common at hotels.
The "h245-alphanumeric" option 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, it will generate the tone on the PSTN interface of the call using a fixed duration of 500 ms. All H.323 version 2 compliant systems are required to support the "h245-alphanumeric" method, while support of the "h245-signal" method is optional.
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. To receive DTMF digits from another H.323 endpoint using any of the methods described above, no configuration is necessary. The Cisco H.323 version 2 gateway is capable of receiving DTMF tones transported by any of these methods at all times.
However, to send digits out of band using one of these methods, two conditions must be met:
1.
2.
You may enable more than one DTMF relay option for a particular dial peer. If you enable more than one option, and if the peer indicates that it is capable of receiving DTMF in more than one of these formats then the gateway will send DTMF using the method among the supported formats that it considers to be the most preferred. The preferences are defined as follows:
1.
2.
3.
If the peer is not capable of receiving DTMF in any of the modes that you have enabled, DTMF tones will be sent inband.
When the Cisco H.323 version 2 gateway is involved in a call to a Cisco gateway running a version of IOS prior to 12.0(5)T, DTMF tones will be sent inband since those systems do not support DTMF relay.
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. You can 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. Since 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 support includes limited support for relaying hookflash indications via H.245. H.245 User Input Indication messages containing hookflash indications that are received on the IP call leg are forwarded to the POTS call leg if the POTS interface is 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 PBX's supplementary services if the PBX supports access to those features via hookflash.
The gateway does not originate H.245 hookflash indications in this release. For example it does not forward hookflash indications from FXS interfaces to the IP network over H.245.
The acceptable duration of a hookflash indication varies by equipment vendor and by country. While 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 this release of IOS adds the "timing hookflash-out" command to allow the administrator to define the duration of a hookflash signal generated on an FXO interface.
CODEC Negotiation
CODEC negotiation allows the Gateway to offer several CODECs during the H.245 capability exchange phase and ultimately settle upon a single common CODEC during the call-establishment phase. This increases the probability of establishing a connection since there will be a greater chance of over-lapping audio capabilities between endpoints. Normally, only one CODEC can be specified when configuring a Dial-Peer, but CODEC negotiation allows you to specify a prioritized list of CODECs associated with a Dial-Peer. During the call-establishment phase the router will use the highest priority CODEC from the list which it has in common with the remote endpoint. It will also adjust to the CODEC selected by the remote endpoint so that a common CODEC is established for both the receive and transmit audio directions.
When a call is originated, all of the CODECs associated with the Dial-Peer are sent to the terminating endpoint in the H.245 Terminal Capability Set message. At the terminating endpoint, the gateway will advertise all of the CODECs that are available in firmware in its Terminal Capability Set. If there is a need to limit the CODECs advertised to a subset of the available CODECs, a terminating Dial-Peer must be matched which includes this subset. The "incoming called-number" command under the Dial-Peer can be used to force this match.
Benefits
Cisco H.323 Version 2 adds the following benefits to Cisco H.323 gatekeepers, gateways, and proxies:
•
•
•
•
•
•
•
•
•
•
•
Restrictions
H.323 Version 2 features will not interoperate with H.323 Version 1 features in Cisco IOS versions prior to 11.3(9)NA or 12.0(3)T. Earlier Cisco IOS versions contain H.323 Version 1 software that does not support protocol messages with an H.323 Version 2 protocol identifier. All systems must be running either Cisco IOS version 11.3(9)NA and later or Cisco IOS version 12.0(3)T and later to interoperate with H.323 Version 2.
If you are planning to use a Cisco AS5300 universal gateway, your software requires VCWare version 4.04.
Related Features and Technologies
Cisco H.323 Version 2 technologies are typically configured using a number of available compression/decompression (CODECs) and the following High Density DSP/Voice modules.
CODECs
The supported compression/decompression (CODECs) are available for use with Cisco H.323 Version 2. The following table lists each CODEC with a default packet size (in bytes) and a ranges.
High Density DSPs
The following platforms support Cisco H.323 with the following DSP/Voice modules:
Cisco 2600 Series
The Cisco 2600 series DSP/voice modules support the following sessions:
•
•
Cisco 3600 Series
The Cisco 3600 series DSP/voice modules support the following sessions:
•
•
Cisco 7200 Series
This Cisco 7200 series DSP/voice modules support the following sessions:
•
•
•
•
Cisco AS5300 Universal Gateway
The Cisco AS5300 universal gateway DSP/voice modules support the following sessions:
•
•
Caution
Related Documents
The following documents describe how to configure Voice over IP:
•
Cisco IOS Voice Configuration Library, Release 12.3
http://www.cisco.com/en/US/products/ps6441/prod_configuration_guide09186a0080565f8a.html
•
Cisco IOS Voice Command Reference, Release 12.3
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/voice_r/index.htm
•
–
•
–
The following table lists the documentation available for configuring and using Cisco IOS H.323 gatekeepers, gateways, and proxies:
Supported Platforms
The gatekeeper and proxy features apply to the following platforms:
•
•
•
•
The gateway features apply to these platforms.
•
•
•
•
•
•
•
Note
Table 1 lists the hardware platforms that support this feature, and the releases in which the feature was first supported. If the First T train Release column is blank, the feature is not yet available in a Cisco IOS T release on that platform.
Platform Support Through Feature Navigator
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.
To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.
Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:
http://www.cisco.com/go/fn
Note
Supported Standard MIBs and RFCs
Standards
This feature adds support for the following ITU-T standards: H.323 Annex E and H.323 Annex G.
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of MIBs supported by platform and Cisco IOS release and to download MIB modules, go to the Cisco MIB web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites
The Cisco AS5350 and Cisco AS5400 do not support the Mica Modem Card, Microcom Modem Card, or VoIP Feature Card. Voice and modem functions are provided by the Universal Port Dial Feature card running SPE firmware. See the Cisco AS5350 Universal Gateway Card Installation Guide and the Cisco AS5400 Universal Gateway Card Installation Guide for more information. All references to the Cisco AS5300 in this document apply to the Cisco AS5350 and Cisco AS5400 platforms with the following exceptions:
•
•
•
Other Prerequisites
Before you can use the H.323 Version 2 features, you must do the following:
•
•
•
•
Configuration Tasks
The H.323 Version 2 configuration options allow you to configure the following H.323 components:
•
•
•
•
Note
For the Cisco AS5300 gateways, port designation is port.
For the Cisco AS5350 and Cisco AS5400, port designation is slot/port.
CODEC Configuration Tasks
To configure multiple CODECs for a dial-peer, use these steps:
Step 1
The "voice class codec" command is used to create a CODEC preference list which is independent of a Dial-Peer and can be applied to several Dial-Peers.
Step 2
Router(config)#[no] voice class codec <tag>Router(config-class)#Step 3
Router(config-class)# [no] codec preference <value> <codec_type> [<cr> | bytes]<size> <cr>Step 4
Router(config-dial-peer)# voice-class codec <tag>Step 5
Here is a sample configuration:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.(config)#voice class codec 99(config-class)# codec preference 1 g711alaw(config-class)# codec preference 2 g711ulaw bytes 80(config-class)# codec preference 3 g723ar53(config-class)# codec preference 4 g723ar63 bytes 144(config-class)# codec preference 5 g723r53(config-class)# codec preference 6 g723r63 bytes 120(config-class)# codec preference 7 g726r16(config-class)# codec preference 8 g726r24(config-class)# codec preference 9 g726r32 bytes 80(config-class)# codec preference 10 g728(config-class)# codec preference 11 g729br8(config-class)# codec preference 12 g729r8 bytes 50(config-class)#end#Router(config)# dial-peer voice 1919 voip(config-dial-peer)#voice-class codec 99(config-dial-peer)#endRouter# show running-configdial-peer voice 1919 voipvoice-class codec 99!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
Gatekeeper Configuration Tasks
With this version of the gatekeeper software, you can configure the gatekeeper to do the following:
•
•
•
•
Detailed instructions for proxy configuration are provided in the "use-proxy" command description. To learn how to configure dialing prefixes, see the "zone prefix" command description.
Gateway Configuration Tasks
This release of the gateway software allows you to configure an H.323 gateway as follows:
•
•
•
•
For information on the "dtmf-relay" command, see the "dtmf-relay" command description. For information on the "timing hookflash-out" command, see the "timing hookflash-out" command description.
Configuration Examples
See the examples provided for each command in the "Gatekeeper Command Reference" section.
Gatekeeper Command Reference
This section documents new or modified commands for the gatekeeper. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.
•
clear h323 gatekeeper call
To force a specific call or all calls currently active on the gatekeeper to disconnect, use the
clear h323 gatekeeper call EXEC command.clear h323 gatekeeper call {all | local-callID local-CallID}
Syntax Description
Command Modes
EXEC
Command History
Defaults
None
Usage Guidelines
Force all calls on the gatekeeper to disconnect by using this command.
Examples
Use the following form of the clear h323 gatekeeper call command to force an active call with the local call ID of "12-3339" to disconnect:
clear h323 gatekeeper call local-callID 12-3339You can get information about specific active calls by using the show gatekeeper calls command.
The following example forces all active calls on this gatekeeper to be disconnected:
clear h323 gatekeeper call allRelated Commands
show gatekeeper calls
To show the status of each ongoing call that a gatekeeper is aware of, use the show gatekeeper calls EXEC command.
show gatekeeper calls
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Use this command to show the status of all outgoing calls that the gatekeeper handles.
Examples
router# show gatekeeper callsTotal number of active calls = 1.GATEKEEPER CALL INFO====================LocalCallID Age(secs) BW12-3339 94 768(Kbps)Endpt(s):Alias E.164Addr CallSignalAddr Port RASSignalAddr Portsrc EP:epA 90.0.0.11 1720 90.0.0.11 1700dst EP:epB@zoneB.comsrc PX:pxA 90.0.0.01 1720 90.0.0.01 24999dst PX:pxB 172.21.139.90 1720 172.21.139.90 24999Related Commands
show gatekeeper endpoints
Display status of registered endpoints for a gatekeeper.
show gatekeeper gw-type-prefix
Display the gateway technology prefix table.
show gatekeeper endpoints
To display the status of all registered endpoints for a gatekeeper, use the show gatekeeper endpoints EXEC command.
show gatekeeper endpoints
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Use this command to display the status of all registered endpoints for a gatekeeper.
Examples
Router#show gatekeeper endpointsCallsignalAddr Port RASSignalAddr Port Zone Name Type F--------------- ---- ------------- ----- ---------- ----- --172.21.127.8 1720 172.21.127.8 24999 sj-gk MCU H323-ID:joe@cisco.com172.21.13.88 1720 172.21.13.88 1719 sj-gk VOIP-GW O H323-ID:la-gw
Related Commands
show gatekeeper gw-type-prefix
To display the gateway technology prefix table, use the show gatekeeper gw-type-prefix EXEC command.
show gatekeeper gw-type-prefix
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
This command first appeared in the Cisco IOS Release 11.3 NA.
Examples
Following is a sample output for a gatekeeper which is controlling two local zones, "sj-gk" and "la-gk":
router#show gatekeeper gw-type-prefixGATEWAY TYPE PREFIX TABLE===========================Prefix:12#* (Default gateway-technology)Zone sj-gk master gateway list:172.21.13.11:1720 sj-gw1172.21.13.22:1720 sj-gw2 (out-of-resources)172.21.13.33:1720 sj-gw3Zone sj-gk prefix 408....... priority gateway list(s):Priority 10:172.21.13.11:1720 sj-gw1Priority 5:172.21.13.22:1720 sj-gw2 (out-of-resources)172.21.13.33:1720 sj-gw3Prefix:7#* (Hopoff zone la-gk)Statically-configured gateways (not necessarily currently registered):1.1.1.1:17202.2.2.2:1720Zone la-gk master gateway list:171.69.127.11:1720 la-gw1171.69.127.22:1720 la-gw2
Related Commands
show gatekeeper zone status
To display the status of zones related to a gatekeeper, use the show gatekeeper zone status EXEC command.
show gatekeeper zone status
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Use this command to display the status of all zones related to a gatekeeper.
Examples
router# show gatekeeper zone statusGATEKEEPER ZONES================GK name Domain Name RAS Address PORT FLAGS MAX-BW CUR-BW(kbps) (kbps)------- ----------- ----------- ---- ----- ------ ------sj.xyz.com xyz.com 1.14.93.85 1719 LS 0SUBNET ATTRIBUTES :All Other Subnets :(Enabled)PROXY USAGE CONFIGURATION :inbound Calls from germany.xyz.com :to terminals in local zone sj.xyz.com :use proxyto gateways in local zone sj.xyz.com :do not use proxyOutbound Calls to germany.xyz.comfrom terminals in local zone germany.xyz.com :use proxyfrom gateways in local zone germany.xyz.com :do not use proxyInbound Calls from all other zones :to terminals in local zone sj.xyz.com :use proxyto gateways in local zone sj.xyz.com :do not use proxyOutbound Calls to all other zones :from terminals in local zone sj.xyz.com :do not use proxyfrom gateways in local zone sj.xyz.com :do not use proxytokyo.xyz.co xyz.com 172.21.139.89 1719 RS 0milan.xyz.co xyz.com 171.69.57.90 1719 RS 0
Related Commands
use-proxy
Use the use-proxy command to enable proxy communications for calls between local and remote zones. The no use-proxy command has two forms and either removes a proxy configuration entry for a remote zone or disables proxy communications between local and remote zones.
use-proxy local-zone-name {default | remote-zone remote-zone-name}{inbound-to | outbound-from}{gateway | terminal}
no use-proxy local-zone-name remote-zone remote-zone-name [{inbound-to | outbound-from}{gateway | terminal}]
Syntax Description
