H.323 Gateway Overview

Gateways allow H.323 terminals to communicate with devices that are running other protocols. They provide protocol conversion between the devices that are running different types of protocols. For example, Figure: Gateway Between an H.323 Terminal and an H.320 Terminal shows a gateway between an H.323 terminal and a non-H.323 terminal.

Troubleshooting H.323 Gateway Call Routing and Dial Peers

Verifying Digits Received and Sent on the POTS Call Leg

Once the on-hook and off-hook signaling are verified to be working correctly, the next step in troubleshooting and debugging a VoIP call is to verify that the correct digits are being received or sent on the voice-port (digital or analog). A dial peer is not matched or the switch (CO or PBX) is not able to ring the correct station if incomplete or incorrect digits are being sent or received. Some commands that can be used to verify the digits received/sent are:

show dialplan number-This command is used to show which dial peer is reached when a particular telephone number is dialed.

debug vtsp session-This command displays information on how each network indication and application request is processed, signaling indications, and DSP control messages.

debug vtsp dsp -This command displays the digits as they are received by the voice-port.

show dialplan number

The show dialplan numberdigit_string command displays the dial peer that is matched by a string of digits. If multiple dial peers can be matched, they are all shown in the order in which they are matched. The output of this command looks like this:

If you find that the digits are not being sent or received properly, you might need to use either a digit-grabber (test tool) or T1 tester to verify the digits are being sent at the correct frequency and timing interval. If they are being sent incorrectly for the switch (CO or PBX), some values on the router or switch (CO or PBX) might need to be adjusted so that they match and can interoperate. These are usually digit duration and interdigit duration values. If the digits appear to be sent correctly you might want to examine any number translation tables in the switch (CO or PBX) that might add or remove digits.

Verifying End-to-End VoIP Signaling on the VoIP Call Leg

After verifying that voice-port signaling is working properly and the correct digits have been received, verify that the end-to-end VoIP signaling is set up on the VoIP call leg.VoIP signaling involves call control. The following factors explain why call control debugging can become a complex job:

Cisco VoIP gateways use H.323 signaling to complete calls. H.323 is made up of three layers of call-negotiation and call-establishment: H.225, H.245, and H.323. These protocols use a combination of TCP and UDP to set up and establish a call.

End-to-end VoIP debugging shows a number of Cisco IOS state machines, and problems with any state machine can cause a call to fail.

End-to-end VoIP debugging can be very verbose and can create a lot of debug output.

debug voip ccapi inout

The primary command to debug end-to-end VoIP calls is debug voip ccapi inout. The output from a sample call debug is shown below.

The next line shows that the voice gateway received a call proceeding message from the terminating gateway. The line after that shows that the voice gateway received a call alert from the terminating gateway.

If the call is failing and the cause appears to be in the VoIP portion of the call setup, you might need to look at the H.225 or H.245 TCP part of the call setup, as opposed to just the UDP portion of the H.323 setup. The commands that can be used to debug the H.225 or H.245 call setup are:

debug ip tcp transaction and debug ip tcp packet - These examine the TCP portion of the H.225 and H.245 negotiation. They returns the IP addresses, TCP ports and states of the TCP connections.

debug cch323 h225 -This examines the H.225 portion of the call negotiation. Think of this as the Layer1 part of the 3 part H.323 call setup.

debug ch323 h245-This examines the H.245 portion of the call negotiation. Think of this as the Layer2 part of the 3 part H.323 call setup.

Troubleshooting H.323 Gateway Dial Tone

A common problem encountered in a VoIP network is being unable to break dial tone. The router puts a seizure on the local PBX but when digits are dialed, the dial tone stays. The calling party is unable to pass the DTMF tones or digits to the terminating device, resulting in callers being unable to dial the desired extension or interact with the device that needs DTMF tones such as a voice mail or interactive voice response (IVR) application. This problem can result from a number of reasons such as:

DTMF tones not being passed

DTMF tones not being understood

DTMF tones being passed too distorted to be understood

Other signaling and cabling issues

In the case of a VoIP call from an originating gateway (OGW) to a terminating gateway (TGW), terminating the call to a telephony device might not be understood. When you are passing DTMF tones through a compressed VoIP audio path, some or part of the dual-tones could become slightly distorted because DSP codecs are designed to interpret human speech, not machine tones. Usually, this does not occur with lesser compression codecs such as G.732 or G.711. But the higher compression codecs might result in distortion of in-band tones. However, Cisco IOS allows the DTMF tones to be passed out-of-band between VoIP gateways using three different techniques. All of these techniques use the H.245 capabilities-exchange (part of H.323v2) to signal to the remote VoIP gateway that a DTMF-tone has been received and the remote VoIP gateway should regenerate it.

Make sure the dtmf-relay command is configured under the VoIP dial-peer on both sides. Three different types of DTMF relays can be configured.

Troubleshooting H.323 Gateway Busy Tone

This section addresses call progress in-band related issues that arise when you are interworking ISDN and H.323 signaling between VoIP and the PSTN. Challenges arise when Cisco VoIP gateways exchange signaling capabilities with the telco switch. The following are some common problem scenarios and symptoms:

No DTMF Digits or Audio Passed on VoIP Calls to PSTN or PBX-This occurs when the IP phone user makes a call, is able to hear announcement messages (for example "enter your account number.") but cannot pass DTMF digits. This symptom applies for both VoIP toll-bypass calls and Cisco IP phone to PSTN/PBX calls.

Problem Description

A Cisco IP phone (using Cisco CallManager) or POTS phone (VoIP) call leaves through a Cisco IOS gateway, where the called number is usually an interactive voice response (IVR). The IVR system sends back an ISDN progress message but does not connect until some account information is entered. By default, the audio path is cut through in the backward direction (toward the Cisco IP phone or originating gateway), but not in the forward direction, until the terminating gateway receives a connect message. Therefore, there is no voice path for the transmission of DTMF tones or speech towards the terminating switch.

Solution

Configure the Cisco IOS global configuration command voice rtp send-recv to establish (cut through) the audio path in both directions prior to receiving an ISDN connect message from the PSTN. For more information on this command refer to the Cisco IOS Voice Command Reference.

No Busy Tone or Announcement Message Received When Placing VoIP Outbound Calls

Symptom

A Cisco IP phone (using CallManager) or POTS phone (VoIP) does not hear a busy tone or announcement message from the PSTN.

Solution

Configure the voice call convert-discpi-to-prog command. This command converts an inbound ISDN disconnect message with a progress indicator (PI) to an H.225 progress message with the same progress indicator (PI) value. This command can help when an announcement is played on the terminating PSTN side, but the calling party does not hear the response. In the VoIP toll-bypass scenario, most of these issues are resolved by upgrading the gateways to Cisco IOS Release 12.2(1) or later. However, if the originating device or originating ISDN switch does not keep the call active when an H.225/ISDN disconnect message is received, try using the voice call convert-discpi-to-prog command.

This might come up when the announcement in-band is a busy tone, as well. Beyond that, the busy signal should be provided by either the terminating device, the originating device, or the network. Some aspects of this can be controlled.

Symptom

You cannot hear busy tone on a call from PSTN through a gateway to a Cisco CallManager IP phone, Cisco IOS gateway, or third-party H.323 device when running either an application or two-stage dialing on the originating gateway.

Solution

This can occur when the originating gateway is either running a voice application such as debit-card, or is running two-stage dialing. The latter refers to the calling party dialing the number to the gateway first, receiving the dial tone and then dialing the called party. In either case, the call has connected in terms of the PSTN network once it terminates on the originating gateway. If the IP call leg comes back with a release with the cause user-busy, the busy state cannot be indicated back towards the telephony session that is in connect state.

This problem has been addressed by having the originating gateway generate a busy tone when the release from the IP call leg is received with a cause code of user busy. The telephony leg is released either by the calling party or by the gateway after several minutes, with the cause code of normal call clearing.

Troubleshooting H.323 Gateway Ringback

This section addresses call progress in-band related issues when you are interworking ISDN and H.323 signaling between VoIP and PSTN networks. Challenges arise when Cisco VoIP gateways exchange signaling capabilities with the telco switch. The following are common problem symptoms:

No Ringback Tone on VoIP Toll-Bypass Calls

Symptom

A POTS user (from the PSTN or a PBX) places a call through a Cisco gateway and does not hear ringback tone before the call is answered.

Problem Description

The call terminating switch is sending the ringback tone, and signals a PI=8 to the terminating Cisco gateway. The PI information is then forwarded to the originating gateway via an H.225 progress message. The originating gateway is unable to decode the progress message and does not cut through the backward audio path to permit the transmission of the ringback tones. Some common scenarios for this problem are as follows:

Terminating gateway running Cisco IOS software Release 12.1(5)T or later with originating gateway running Cisco IOS software Release 12.1T. The originating gateway does not understand the H.225 progress message and does not cut through the audio path until the connect message is received.

Terminating Cisco gateway is connected to a CAS or analog interface and sends the PI information in an H.225 progress message to the originating gateway. The originating gateway is unable to decode the H.225 progress message.

ISDN switch sends back inband ringback but Alert message does not contain a PI.

Solutions

Try the following solutions:

1. Configure the Cisco IOS global configuration command voice call send-alert command in the terminating gateway. This command enables the terminating gateway to send an Alert message instead of a Progress message after it receives a call setup. If this command is unavailable or does not work, go to step 2.

2. Upgrade the Cisco IOS software onthe originating gateway to a current Cisco IOS software release. If this does not work, go to step 3.
3. Configure the terminating gateway to send a PI = 8 in the alert message. Configure the command progress_ind alert enable 8 under the voice dial-peer # pots configuration. This command overrides the PI value received in ISDN alert message and causes the router to cut through the audio path back towards the calling party prior to connect.

The progress_ind alert and the progress_ind setup commands are hidden in some versions of Cisco IOS and might not be visible within CLI help. However, if the progress_ind progress command is available in the help parser, the above commands are also available and can be entered into the dial peer in their entirety. These commands subsequently appear in the running configuration output.

Symptom

A POTS user (on the PSTN or PBX) places a call to an IP phone through a Cisco gateway and does not hear ringback tone before the call is answered.

Problem Description

This commonly occurs when the inbound call does not come in to the Cisco gateway/ router with a PI=3. ISDN switches send a PI=3 in the setup message to inform the gateway that the originating call is non-ISDN and that in-band messages are expected.

Solutions

Use one of the following solutions:

Configure the progress_ind setup enable 3 command when configuring the VoIP dial peer in the Cisco gateway. This command forces the gateway to treat the inbound ISDN setup message as if it came in with a PI = 3 generates an in-band ringback tone towards the calling party when the H.225 alert message does not contain a PI of 1, 2, or 8.

The progress_ind alert and the progress_ind setup commands are hidden in some versions of Cisco IOS and might not be visible within CLI help. However, if the progress_ind progress command is available in the help parser, the above commands are also available and can be entered into the dial peer in their entirety. These commands subsequently appear in the running configuration.

An alternative to the progress_ind setup command is the tone ringback alert-no-pi command in dial-peer voice configuration mode. This command causes the gateway to generate ringback towards the calling party if an alert is received on the IP call leg with no PI present. It differs from the progress_ind setup command in that the outbound H.225 setup message does not contain a PI of 3 with the tone ringback command. Some devices might not accept setup messages when a PI is included.

Symptom

A user makes an outbound call from a Cisco IP phone to the PSTN through a Cisco IOS gateway and does not hear ringback tone.

Problem Description

In this situation, the originating device expects in-band ringback tones, but either of the following might be happening:

The PSTN or switch is not providing the ringback tone.

The Cisco IOS gateway is not cutting through the audio to the originating device.

If the PSTN is providing in-band ringback, but the Q.931 alert message is not providing a PI indicating that there is in-band information, the gateway does not cut through the audio until the call is connected.

Solutions

Follow one of the solutions below:

Ringback tones must come from the PSTN for trunk circuits in this situation. There are two dial-peer subcommands which may help. On the Cisco IOS gateway under the outgoing POTS dial peer, configure the command progress_ind alert enable 8. This command presents the Q.931 alert message to the software on the gateway as if the alert message had a PI of 8 and cut through the audio path.

Note:

The progress_ind alert and the progress_ind setup commands are hidden in some versions of Cisco IOS and might not be visible within CLI help. However, if the progress_ind progress command is available in the help parser, the above commands are also be available and can be entered into the dial peer in their entirety. These commands subsequently appear in the running configuration.

In Cisco IOS software releases 12.2(2)T and later, configure the command progress_ind setup enable 3 when configuring the POTS dial peer. This command causes the gateway to send a PI with a value of 3 in the ISDN setup message, indicating to the PSTN or PBX that the originating device is a non-ISDN device and in-band information should be presented. This command should be used with the command progress_ind alert enable 8.

If the PSTN device, such as an ISDN phone directly connected to a BRI port on the gateway, is not able to generate ringback in-band, the gateway can be configured to generate ringback on the IP call leg. Configure the tone ringback alert-no-pi command when configuring the POTS dial peer. When the ISDN alert is received with no PI present, the gateway generates the ringback and includes PI=0x8 in the H.225 alert message.

Symptom

When a call to an IP phone is answered and then transferred, the caller does not hear ringback. When the transferred call is answered, both parties are able to hear each other.

Problem Description

From the perspective of the Cisco IOS gateway, the call is completed once the call is answered by an IP phone through Cisco CallManager or Unity Voice Mail system. Any further progress tones (in case of a call transfer) should be generated by the terminating device. However, Cisco CallManager and Unity are not capable of generating the in-band progress tones.

Solution for Cisco CallManager 3.0

To solve this problem you can either check the following conditions, or configure the Cisco IOS gateway as an MGCP gateway, instead of an H.323 gateway.

You must have Cisco CallManager Release 3.0 (8) or higher.

From the CallManager Administration page go to the Service menu and select Service Parameters. Perform the following steps for each active CallManager server:

In the Configured Services box, select Cisco CallManager.

In the Param drop-down list box, select ToSendH225UserInfoMsg.

Set the Value drop-down list box, to T for true.

Upgrade the gateway to Cisco IOS Release 12.2 (2) or higher.

This problem is documented in DDTS software bug CSCds11354.

Note:

These fixes are valid for ringback tones, but not for other progress tones, such as busy signal.

Solution for Cisco CallManager 3.3 or Newer

To solve this problem for Cisco CallManager 3.3 or newer, perform the following steps:

From the Cisco CallManager Administration page, go to the Service menu and select Service Parameters.

Select the Cisco CallManager server from the drop down box.

Select the system to modify from the drop down box. Make sure to select Cisco CallManager.

From the Cisco CallManager Administration page go to the Service menu and select Service Parameters.

From the drop-down box, select the server you wish to change.

In the second drop-down box, select the service:Cisco CallManager.

In the Cluster Wide Parameters ( Device - H323)' section, under the Send H25User Info Message selection, verify that the box for No Ringback is not checked and the box for User Infro for Ring Back Tone is checked.

Troubleshooting H.323 Gateway One-Way or No Audio

One-way audio and no audio are problems that are fairly common during a new VoIP network installation. Most of these problems are caused by misconfigurations. This section addresses some of the common issues that are known to result in IP telephony one-way audio conversations involving Cisco gateways.

This section provides scenarios and solutions to the following problems:

On a phone call from an IP station through a Cisco IOS voice gateway, only one party receives audio (one-way communication).

On a toll-bypass call between two Cisco gateways, only one party receives audio (one-way communication).

The causes for one-way audio or no audio in IP telephony can be varied, however the root of the problem is usually related to IP routing issues. For one-way audio, pay attention to which direction is experiencing the audio loss. Check the following topics if you are experiencing this issue:

Ensuring IP Routing Is Enabled on Cisco IOS Gateways

Some Cisco IOS gateways, such as the VG200, have IP routing disabled by default. This leads to one-way voice problems. To enable IP routing, simply type the following global configuration command in your Cisco IOS gateway:

Router(config)#ip routing

Checking Basic IP Routing

Basic IP reachability should always be checked first. Because Real-Time Protocol (RTP) streams are connectionless (transported over UDP), traffic might travel successfully in one direction, but get lost in the opposite direction.

Once a call is established, an RTP stream carrying audio needs to flow in both directions between the endpoints. It could be that subnet A can be reached from subnet B, but subnet B cannot be reached from subnet A, so the audio stream from A to B always gets lost.

This is a basic routing issue, so use IP routing troubleshooting methods to get to the stage at which you can successfully ping phone A from gateway B. Bear in mind that ping is a bidirectional verification.

Check the following IP routing issues:

Default gateways configured at the end stations

IP routes on the default gateways, mentioned above, leading to the destination networks

If you are using the Cisco IP SoftPhone application and more than one NIC (network interface card) is installed in the box, make sure the box sources the correct NIC. This issue is often present in IP SoftPhone software Version 1.1.x.

Note:

If you are using Cisco DT24+ gateways, check the DHCP scope and make sure there is a default gateway (003 router) option in the scope. The 003 router parameter is what populates the Default Gateway field in the devices and PCs. Scope option 3 should have the IP address of the router interface that is doing routing for the gateway.

Binding the H.323 Signaling to a Specific IP Address

When the Cisco IOS gateway has multiple active IP interfaces, some of the H.323 signaling might be sourced from one IP address and other parts of it might reference different source addresses. This can generate various kinds of problems, one of them being one-way audio.

To get around this problem, the H.323 signaling can be bound to a specific source address, which can belong to a physical or virtual interface (loopback). The command syntax to use under interface configuration mode is h323-gateway voip bind srcaddrip_address. Configure this command under the interface by using the IP address that Cisco CallManager points to.

Checking That Answer Supervision Is Being Sent and Received Correctly From the Telco or Switch

In an implementation that has a Cisco IOS gateway connected to a telco or switch, verify that answer supervision is being sent correctly when the called device answers the call from behind the switch. Failure to receive answer supervision causes the Cisco IOS gateway to fail cut through (open) the audio path in a forward direction, causing a one-way voice. A workaround is to configure voice rtp send-recv on.

Using the voice rtp send-recv Command to Establish Early Two-Way Audio

The voice path is established in the backward direction as soon as the RTP stream is started. The forward audio path is not cut through until the Cisco IOS gateway receives a connect message from the remote end.

In some cases it is necessary to establish a two-way audio path as soon as the RTP channel is opened, before the connect message is received. To achieve this, use the voice rtp send-recv global configuration command.

Checking cRTP Settings on a Link-by-Link Basis

This issue applies to scenarios, such as toll-bypass, where more than one Cisco IOS gateway is involved in the voice path and compressed RTP (cRTP) is used. cRTP, or RTP header compression, is a method for making the VoIP packet headers smaller to regain bandwidth. cRTP takes the 40-byte IP/UDP/RTP header on a VoIP packet and compresses it to 2-4 bytes per packet, yielding approximately 12 KB of bandwidth for a G.729 encoded call with cRTP. For more information on cRTP, refer to Voice Over IP - Per Call Bandwidth Consumption, document ID 7934.

cRTP is done on a hop-by-hop basis with decompression and recompression on every hop. Each packet header needs to be examined for routing, therefore cRTP needs to be enabled on both sides of an IP link.

It is also important to verify that cRTP is working as expected on both ends of the link. Cisco IOS levels vary in terms of switching paths and concurrent cRTP support.

If you are running cRTP using Cisco IOS Release 12.1, verify that bug CSCds08210 does not affect your Cisco IOS version (VoIP and fax not working with RTP header compression on).

Verifying Minimum Software Level for NAT on Cisco IOS Gateways

If you are using Network Address Translation (NAT), the minimum software level requirements must be met. Earlier versions of NAT do not support skinny protocol translation and leads to one-way voice issues.

The minimum software levels required for using NAT and skinny simultaneously are Cisco IOS® Software 12.1(5)T for IOS gateways to support skinny and H.323v2 with NAT.

Note:

If your Cisco CallManager is using a TCP port for skinny signaling different from the default port (2000), you need to adjust the NAT router with the ip nat service skinny tcp port number global configuration command.

The minimum software level required for using NAT and skinny simultaneously on a PIX firewall is Release 6.0.

Note:

These levels of software do not necessarily support all of the RAS messages necessary for full gatekeeper support. Gatekeeper support is outside the scope of this document.

The Cisco IOS command voice-fastpath enable is a hidden global configuration command for the Cisco AS5350 and Cisco AS5400. This command is enabled by default. To disable it, use the no voice-fastpath enable global configuration command.

When enabled, this command caches the IP address and UDP port number information for the logical channel opened for a specific call and prevents the RTP stream from getting to the application layer, but rather forwards the packets at a lower layer, which helps reduce CPU utilization marginally in high call volume scenarios.

When supplementary services, such as hold or transfer are used, the voice-fastpath command causes the router to stream the audio to the cached IP address and UDP port, disregarding the new logical channel information generated after a call on hold is resumed or a transfer is completed. To get around this problem, traffic should go to the application layer constantly so that redefinition of the logical channel is taken into account and audio is streamed to the new IP address/UDP port pair. That is why you should disable voice-fastpath to support supplementary services.

Configurinng the VPN IP Address with SoftPhone

Cisco IP SoftPhone enables you to make a PC work like a Cisco IP Phone 7900 Series phone. Remote users who connect back to their company network through VPN need to configure some additional settings in order to avoid a one-way voice problem. This is a result of the media stream needing to have the endpoint of the connection specified.

The solution is to configure the VPN IP address, instead of the IP address of the network adapter, under the Network Audio Settings.

Verifying One-Way Audio

A useful command to verify packet flow is debug cch323 rtp. This command displays packets transmitted (X) and received (R) by the router. An uppercase character indicates successful transmission/reception, and a lowercase character indicates a dropped packet.

Router# debug cch323 rtp
RTP packet tracing is enabled
Router#
!--- This is an unanswered outgoing call.
!--- Notice that voice path only cuts through in forward
!--- direction and that packets are dropped. Indeed,
!--- received packets are traffic from the IP phone to the PSTN
!--- phone. These will be dropped until the call is answered.
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
Router#
Router#
!--- This is an example of an answered call:
Router#
Router#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
!-- At this point the remote end picks up the phone.
*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR
!-- End of conversation.

Using the Test Call Feature to Verify Voice Path

The Test Call feature provides the ability for a remote station or gateway to establish a call to any destination address from a Test Call station located at a network operations center and to audibly verify the voice path:

The system administrator can manually place a specific CIC on the target TG in test mode.

The TCL script in OGW can specify a destination CIC or DS0 number.

This circuit number can then be carried to the terminating gateway.

The TGW can override any local circuit selection configured and use the specified circuit number for the outgoing call.

Information About the Test Call Feature

This section provides summary information about the test call feature. This section also describes some of the restrictions and limitations that should be taken into account when you are enabling and activating the test call feature.

Route Server

The route server detects this test call by the "Test Call" source trunk group label, bypasses the normal routing logic, and routes the call directly to a specified trunk group based on the configured destination (gateway IP address plus trunk group label). All trunk group members (GW IP address plus trunk group label) in a trunk group will be displayed in the route server routing hierarchy and the test call person can select any trunk requisite.

The group member can be specified as the destination so that the test call can be routed to a specific destination trunk group label on a specific gateway.

A test call syslog is generated in the route server. This syslog covers the route information (incoming carrier ID/trunk group ID/trunk group number, outgoing carrier ID/trunk group ID/trunk group number), the IP address of the destination gateway, and the called number, and can be browsed from its GUI web.

Because the ARQ message sent from the test station OGW will not have any GTD payload, the route server builds a GTD if the Termination trunk group is ISDN/ISUP/R2. The route server also sends the same format of the currently used route descriptor to the test station OGW.

TCL Script

TCL scripts in the OGW send the route descriptor to the mediation server for accounting purposes.

TCL scripts in the OGW override the GTD CPC value received from the route server with the configured value.

The configured value may be changed using the application, service, and paramspace command structure shown in the Sample Tasks.

TCL scripts in the OGW insert the termination CIC port number in the outgoing H225 Setup message.

The TCL script in the OGW handles two-stage calls. If the call is originated from the test call trunk group, the TCL script in the OGW parses the dialed digits to identify the delimiter and split the dialed digits to the E164 number and CIC number.

Limitations

Test-mode status maintained within the gateway is reset if any interface is added or removed from the trunk group.

If the DS0 is placed in test mode, it is not selected for nontest calls. The system administrator must reset the DS0 from the test mode.

The test mode configuration is not saved for reloads. Once the gateway reloads, the test mode configuration is lost. The administrator has to place the CIC in test mode again to place a test call.

Test Mode Limitations

In some SS7 networks, the signaling on the terminating switch can override the local channel selection. In such cases, there is no guarantee that the test call will be placed on that specified channel.

The number of the DS0 or CIC in test-mode status does not affect the call capacity update to the H323 client.

When a DS0 or channel is placed in test-mode, the trunk group circuit selection algorithm avoids using the channel for outgoing nontest calls. But if call routing on the gateway is not based on the trunk group or carrier-ID, then this channel may be used. Similarly, the DS0 or channel is not guaranteed to be reserved if the gateway supports hybrid routing (some calls are based on the trunk group or carrier-ID routing and some calls not)

Placing a DS0 or channel in test mode would only guarantee that no new outgoing calls will be placed on the DS0 in the trunk. However, no control is exercised on existing calls or incoming calls in that channel. To clear the existing call through the channel (if desired), enter this command:

clear call voice causecode cause id callID

All incoming calls through the channel in test mode will not be rejected. It is up to the terminating switch to correspondingly place the channel in test mode and avoid sending calls through this channel.

Feature Limitations

The Test Call feature allows the Tcl script in the OGW to send the CIC number for Test Call to the TGW. If the corresponding DS0 is not placed in test mode, the trunk selection API would make a best-effort attempt to select the corresponding CIC or DS0 number if it is free and would continue with the test call setup.

The CIC number is carried in H225 Setup message H323 V4 field. Thus this feature would work only in H323v4 networks,

The test call feature is not supported in SIP and H323 v2 networks.

Test Call Command-Line Interface

To enable the test call feature, use a new CLI to place specific CIC or DS0s of a trunk group in test mode. The normal circuit selection algorithm would not select this DS0 or CIC number for nontest calls.