Troubleshoot Analog FXO GroundStart Outbound Call Failures

Available Languages

Download Options

  • PDF     (456.0 KB)
    View with Adobe Reader on a variety of devices
Updated:May 14, 2006
Document ID:61947

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

The intent of this technical note is to provide step-by-step troubleshooting recommendations to users who experience call setup problems that involve Cisco Foreign eXchange Office (FXO) GroundStart (GS) analog voice-ports. Oftentimes, these call setup failures are manifested as unsuccessful outbound call attempts. This document outlines general GS troubleshooting considerations applicable to all situations. It then provides a discussion of more specific misbehavior related to known defects and their respective workarounds.

Prerequisites

Requirements

Basic knowledge of voice signaling is required to best understand this document. For more information about the voice signaling techniques, refer to Voice Network Signaling and Control.

For a better understanding of FXO voice interface cards, refer to Understanding Foreign Exchange Office (FXO) Voice Interface Cards.

These are some additional requirements:

  • RJ-11 cables (straight-through, two conductors, Tip and Ring only preferred)

  • RJ-11 connector ends and spare two-conductor RJ-11 cable

  • Wire strippers

  • RJ-11 crimpers

  • RJ-11 or RJ-45 cable extenders

  • Digital Multi Meter (DMM) with true Root Mean Square (RMS) leavingcisco.com capability

  • Oscilloscope, if available

  • Regular analog telephones

  • Testing ButtSet

Components Used

The majority of this document is not restricted to specific software and hardware versions. Where specific hardware parts are named, however, software versions applicable are those which support the named hardware. Hardware and software compatibility matrices for analog FXO voice products can be found in the Understanding Foreign Exchange Office (FXO) Voice Interface Cards and Understanding High-Density Analog Voice/FAX Network Modules (NM-HDA) documents.

Specific FXO hardware discussed in this document includes:

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Problem Description

A typical symptom of this problem is a situation where an FXO voice-port configured for GS signaling attempts to place an outbound call to the voice switch to which it is connected—such as the Telephone Company Central Office (CO, also known as PSTN) or a Private Branch eXchange (PBX)—and the Cisco FXOGS voice-port fails to detect a tip-ground acknowledgment. This detection failure then results in an unsuccessful call setup.

Troubleshooting Steps for GS Call Failures

Use these steps to troubleshoot GS call failures:

  1. Verify the functionality of the GS line from the Central Office (CO):

    Use a GS-capable ButtSet or similar testing device, ground the ring lead, and listen for a dial tone to be returned from the CO. Once a dial tone is heard, you should be able to dial digits and complete a voice call. If you can not get a dial tone from the CO, you should take this up with the provider.

    If the GS line is verified, connect the VIC-2FXO, VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, or EVM-HD FXO voice-port to the GS line with RJ-11 cabling.

    The easiest way to test outbound calls is to build a simple plain old telephone service (POTS) dial-peer on the voice gateway. For example:

    !
dial-peer voice N pots
 destination-pattern 9T
 port X/Y/Z
!

    You can use the csim start dialstring hidden command to initiate simulated calls to whichever real-world E.164 number is desired. This allows you to determine whether you can properly go offhook from the router to the PSTN, send digits, and complete a call to the destination phone. You can modify the POTS dial-peer appropriately to account for long-distance access codes and other prefixed digits as necessary. In the example above, the POTS dial-peer can match on any string of digits starting with “9”, and all digits that follow the “9” are played out voice-port X/Y/Z.

    On POTS dial-peers, destination-patterns with wildcards have all exact digit matches stripped off. That means on:

    !
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
!

    when “12345678” comes into the router, it matches with the dial-peer, but only “5678” gets passed onwards to the PBX since the “1234” are exact digit matches and get stripped off. Depending on what your PBX is looking for to be able to route a call, this may be a problem.

    Refer to these commands as workarounds:

    Any of these now sends the entire string “12345678” off to the PBX:

    !
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 forward-digits all
!

    or:

    !
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 no digit-strip
!

    or:

    !
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 prefix 1234
!

    The MC3810 platform is a special case; in older versions of Cisco IOS® software, you have to specify how many digits are to be passed to the PBX with the forward-digits command, regardless of whether or not the digit is an exact match or a wildcard.

    In the example above, destination-pattern 9T only has the exact digit match “9.” If “91234567890” is matched on this dial-peer, this leading “9” is stripped and “1234567890” is played out by the router to the voice switch.

    You may issue the debug vpm all, undebug vpm dsp, and debug voip hpi all commands to observe the FXOGS voice-port signaling state changes and the dual tone multifrequency (DTMF) digit playout to the CO. If the csim start command for the outbound call attempt results in ringing the desired phone, you should have no further call issues. If problems persist, proceed to the next step.

    Note: In Cisco IOS Software Release 12.3 mainline releases and Cisco IOS Software Release 12.3T releases prior to 12.3(8)T, the syntax of the debug voip hpi all command is debug hpi all. Use the appropriate command syntax to collect the HPI debugs.

  2. Test and verify the Tip and Ring (T&R) lead polarity.

    GS signaling is polarity-sensitive, so it is important that the T&R leads on the RJ-11 line are properly connected between the demarc point from the CO and the FXO port on the VIC-2FXO, VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, or EVM-HD FXO equipment. If the polarity is the reverse of what it needs to be, inbound calls from the CO to the voice router work, but outbound call attempts from the router to the CO fail 100 percent of the time.

    The easiest way to quickly reverse the polarity on an RJ-11 line is to insert an RJ-45 cable extender and a short span of two-wire RJ-11 crossover cable inline between the existing cabling and the voice-port. Such a short crossover RJ-11 cable can either be crimped by the tester, or is commonly found in the collection of accessories provided with store-bought analog phones. Two-wire RJ-11 cabling is preferred for both testing and production connections to FXS and FXO voice-ports, with just the conductors on pins 2 (Ring) and 3 (Tip) connected (for a 4-conductor RJ-11 cable end).

    For additional pinout information, refer to the VIC Cables and Pinouts section of the Cabling Specifications documentation.

  3. Ensure that the voice router chassis ground reference and the electrical ground reference, which the CO provides for the GS lines, are the same.

    GS signaling is not only polarity-sensitive, but also requires that proper electrical grounding be observed. This is especially important on FXO hardware which is installed as Expansion Modules (EMs) onto base Network Modules (NMs), such as the EM-HDA-6FXO and EM-HDA-3FXS/4FXO on the EVM-HD-8FXS/DID module, and the EM2-HDA-4FXO on the NM-HDA-4FXS module. This is because the electrical connection between the EMs and the base NM constitute another degree of separation between chassis electrical ground and the NM, and care must be taken to ensure that the EMs are securely fastened to the NM for all electrical connectivity to be sound. For example, refer to Figure 16-4 in Connecting High-Density Analog Telephony Network Modules to a Network for EMs on the NM-HDA-4FXS. For each EM, two mounting screws must be installed with 6–8 lbs-in (67.8 N-cm) of torque. Failure to properly secure the EM hardware with both screws compromises product reliability; and, in the case of FXO ports, failure to properly tighten both mounting screws may cause FXO GroundStart outgoing call operation to fail outright.

    For more information regarding grounding considerations, refer to these documents:

  4. If things continue to fail, verify that the VIC-2FXO, VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, or EVM-HD FXO equipment is functioning properly.

    The easiest empirical way to do this is to connect the FXO port to a known functioning FXS port, such as an VIC-2FXS, VIC2-2FXS, VIC-2DID (in FXS mode), VIC-4FXS/DID (in FXS mode), NM-HDA FXS, or EVM-HD FXS port on another (or even same) Cisco voice gateway. In this case, a straight-through, two-wire RJ-11 connection should be used. The aim here is to verify that one voice gateway can signal the other over the connection and draw a dial tone from the peer gateway. A complete testing scenario for this could be:

    ddtsdisp_cgi_01.gif

    Router A Router B 
    !
voice-port 1/0/0
 description FXSLS port
!
voice-port 2/0/0
 description FXOGS port
 signal GroundStart
!
dial-peer voice 888 pots
 destination-pattern 888
 port 1/0/0
!
dial-peer voice 999 pots
 destination-pattern 999
 port 2/0/0
!
    		 
    !
voice-port 1/0/0
 description FXSLS port
!
voice-port 2/0/0
 description FXSGS port
 signal GroundStart
!
dial-peer voice 888 pots
 destination-pattern 888
 port 2/0/0
!
dial-peer voice 999 pots
 destination-pattern 999
 port 1/0/0
!

    A successful test would enable a user to pick up either analog phone and get a dial tone from the local router, dial the far-end extension to go offhook over the GS line, hear a dial tone from the peer gateway, then dial the far-end extension once again to complete the call to the far-end phone. If this works fine in both directions, then the FXO voice-port functions as expected. Be sure to check the phone call for two-way audio from both parties.

    If the call attempts continue to fail or an audio problem such as one-way or no-way audio is experienced, then there may be an actual hardware problem. Check the RJ-11 cabling again, and test with another FXS or FXO voice card, if available.

  5. Determine if there is a Cisco IOS software or DSP firmware (DSPware) defect involved. To verify there is not a Cisco FXO equipment problem:

    Issue the show voice dsp command to determine the version level of the DSPware for the FXO ports, and the show version command to determine your current Cisco IOS version level.

    Then, refer to the Cisco Connection Online (CCO) IOS Release Notes for a list of resolved and unresolved caveats for Cisco IOS software releases newer than what is currently being used on the voice gateway. This enables you to determine if any of the listed defects appear to be a possible culprit for the outbound FXOGS problem.

Issues Specific to the VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO

There is a misbehavior which has been observed on the VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO voice hardware, that is not observed on the original VIC-2FXO series of voice cards. In addition, there are Finite State Machine (FSM) differences between the operation of the two different groups of FXO hardware. These differences, under rare conditions, result in outbound FXOGS calls that work when a VIC-2FXO card is used, but consistently fail when VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO hardware is used. Some of these differences are explained here:

  1. As discussed earlier in Step 3 of the Troubleshooting Steps for GS Call Failures section, proper electrical grounding should always be observed. This is especially important on FXO Expansion Modules (EMs) which are installed onto base Network Modules (NMs). On the EVM-HD-8FXS/DID, these EMs are the EM-HDA-6FXO and EM-HDA-3FXS/4FXO; and on the NM-HDA-4FXS, it is the EM2-HDA-4FXO. The electrical connection between the EMs and the base NM constitute another degree of separation between chassis electrical ground and the NM, and care must be taken to ensure that the EMs are securely fastened to the NM for all electrical connectivity to be sound. For each EM, two mounting screws must be installed with 6–8 lbs-in (67.8 N-cm) of torque. Failure to properly secure the EM hardware with both screws compromises product reliability; and, in the case of FXO ports, failure to properly tighten both mounting screws may cause FXO GroundStart outgoing call operation to fail outright.

    These pictures show the mounting screws which must be properly secured:

    EVM-HD-8FXS/DID

    ddtsdisp_cgil_02sm.jpg

    Note:  Click here for a larger version of this photograph.

    NM-HDA-4FXS

    ddtsdisp_cgi_03sm.jpg

    Note:  Click here for a larger version of this photograph.

  2. The original VIC-2FXO generation of Voice Interface Cards (VICs) use a different chipset and DSP architecture, as well as a slightly different call state FSM, than the VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO generation of hardware. For this reason, you can sometimes use an original VIC-2FXO card and an accompanying NM-1V or NM-2V Network Module (NM) to validate the functionality of the CO GS line when the more recent FXO hardware can not. If this generation of FXO VIC is available for testing alongside the newer generation FXO hardware in the same Cisco IOS software release, and it is found that outbound GS call attempts are successful using the original hardware, then Cisco Technical Support would certainly like to know this information.

    Note: This manner of testing is not possible on Cisco Integrated Services Router (ISR) platforms where the original generation VIC product line is not supported by Cisco IOS software.

  3. Ensure that you are running a Cisco IOS software release with a DSPware version which is not affected by Cisco bug ID CSCee11089 (registered customers only) , “VIC2-xFXO GS debounce timer should be the same as original VIC-2FXO.” As the title suggests, this defect only affects the VIC2-2FXO and VIC2-4FXO voice cards. Its resolution can be found in DSPware 4.1.40 and later versions in the 4.1.x family, DSPware 4.3.16 and later in the 4.3.x family, and DSPware 4.4.2 and later in the 4.4.x family.

    As mentioned in Step 5 of the Troubleshooting Steps for GS Call Failures section, issue the show voice dsp command to determine the version level of the DSPware for the FXO ports. If the DSPware used is suspect, upgrade the Cisco IOS software on the voice gateway and test again.

  4. The state machine and outbound call behavior between the VIC-2FXO card and the other analog FXO hardware is actually a little different. For this reason, outbound call attempts may work for the VIC-2FXO but fail for the other hardware. The call flow for an outbound call from FXOGS to the CO is should be:

    • The FXOGS port provides ring-ground towards the CO.

    • The CO responds to the ring-ground with a tip-ground towards the FXOGS port.

    • The FXOGS port detects the tip-ground and goes offhook with a full loop-close. You hear a dial tone from the CO and from this point forward, you can dial digits and complete a call.

    [ GW ]FXOGS ========== FXSGS [ CO ]

(IDLE STATE)
------> AB=01 (ON HOOK/LOOP OPEN ) ------>
<------ AB=11 (ON HOOK/NO TIP GND ) ------>

(FXO GOES OFFHOOK TO CO)
------> AB=00 (GROUND ON RING) ------>
<------ AB=01 (OFF HOOK/TIP GROUND) <------
------> AB=11 (OFF HOOK/LOOP CLOSED) ------>

    A VIC-2FXO card appears to work because it does not really follow proper GS handshaking. A ring-ground and loop-close are performed at the same time without waiting for a tip-ground.

    For a VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, or EVM-HD FXO voice-port, proper GS handshaking is followed, and in some outbound call failure scenarios, the debug output indicates that you never see a tip-ground acknowledgement from the CO in response to the ring-ground. The debug sequence for the missing tip-ground could look similar to the next output shown. Here, the FXOGS port 1/0/15 goes offhook to the CO (set signal state = 0x0), waits for a tip-ground response, and when it does not see it 10 seconds later, goes back onhook (set signal state = 0x4).

    In this case, the call continues to fail with another voice-port 1/0/14.

    
!--– Output from debug vpm all and undebug vpm dsp.

Jul 9 11:38:03.099: htsp_process_event: [1/0/15, 
FXOGS_ONHOOK, E_HTSP_SETUP_REQ]fxogs_onhook_setup[Foreign Exchange Office 1/0/15]
 set signal state = 0x0
Jul 9 11:38:03.099: htsp_timer - 10000 msec
Jul 9 11:38:13.095: htsp_process_event: [1/0/15, 
FXOGS_WAIT_TIP_GROUND, E_HTSP_EVENT_TIMER]fxogs_offhook_disc
Jul 9 11:38:13.095: htsp_timer_stop [Foreign Exchange Office 1/0/15] 
set signal state = 0x4
Jul 9 11:38:13.095: htsp_timer - 2000 msec
Jul 9 11:38:13.095: htsp_process_event: [1/0/15, FXOGS_ONHOOK, 
E_HTSP_RELEASE_REQ]fxogs_onhook_release
Jul 9 11:38:13.095: htsp_timer_stop2 htsp_setup_req
Jul 9 11:38:13.179: htsp_process_event: [1/0/14, FXOGS_ONHOOK, 
E_HTSP_SETUP_REQ]fxogs_onhook_setup[Foreign Exchange Office 1/0/14]
 set signal state = 0x0
Jul 9 11:38:13.179: htsp_timer - 10000 msec
Jul 9 11:38:15.095: htsp_process_event: [1/0/15, FXOGS_ONHOOK, 
E_HTSP_EVENT_TIMER]
Jul 9 11:38:23.176: htsp_process_event: [1/0/14, FXOGS_WAIT_TIP_GROUND, 
E_HTSP_EVENT_TIMER]fxogs_offhook_disc
Jul 9 11:38:23.176: htsp_timer_stop [Foreign Exchange Office 1/0/14] 
set signal state = 0x4
Jul 9 11:38:23.176: htsp_timer - 2000 msec
Jul 9 11:38:23.176: htsp_process_event: [1/0/14, FXOGS_ONHOOK, 
E_HTSP_RELEASE_REQ]fxogs_onhook_release
Jul 9 11:38:23.176: htsp_timer_stop2
Jul 9 11:38:25.175: htsp_process_event: [1/0/14, FXOGS_ONHOOK,
E_HTSP_EVENT_TIMER]

  5. Another potential source of problems for outbound call attempts on FXOGS voice-ports is the presence of a large 60 Hz AC component on the T&R Leads from the CO. This presence may confuse the detection circuitry on the VIC2-FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO voice-ports. This is electromagnetic interference (EMI) from a source, most likely from AC mains cabling running parallel to the GS lines within the same electrical conduit. This AC noise is important because it can explain outbound call success between different releases of Cisco IOS software.

    Sometimes outbound FXOGS call attempts may work in older 12.2(15)ZJ IOS releases, but not in current 12.3T IOS releases, because there was a FSM change introduced by Cisco bug ID CSCeb74150 (registered customers only) , “Outbound call on groundstart FXO goes offhook on ringing event,” beginning with the Cisco IOS Software Release 12.3(7)T. In pre-12.3(7)T IOS releases, the report of an incoming ring signal actually triggers the command for the voice-port to go offhook, so the CO dial tone is heard and the call succeeds.

    In later 12.3T IOS releases, the ring event is ignored, and you continue to look for tip-ground from the CO. The ring qualification interval is longer in 12.2(15)ZJ IOS releases, so they are less prone to detect false ring signals after the ring-ground event than current 12.3T IOS releases. For this reason, outbound call attempts seldom ever work in current 12.3T IOS releases, but intermittently, may work in 12.2(15)ZJ IOS releases.

    The set of debugs below show timing out waiting from a tip-ground response from the CO. There is also a ring detect event (E_DSP_SIG_0000) and a battery reversal event (E_DSP_SIG_0110).

    
!--– Output from debug vpm all and undebug vpm dsp.

Gateway#
Jul 7 11:30:52.020 EDT: htsp_timer_stop3 htsp_setup_req
Jul 7 11:30:52.020 EDT: htsp_process_event: [1/0/0, FXOGS_ONHOOK, 
E_HTSP_SETUP_REQ]fxogs_onhook_setup
Jul 7 11:30:52.020 EDT: [1/0/0] set signal state = 0x0 timestamp = 0
Jul 7 11:30:52.020 EDT: dsp_set_sig_state: [1/0/0] packet_len=12 
channel_id=128 packet_id=39 state=0x0 timestamp=0x0
Jul 7 11:30:52.020 EDT: TGRM: reg_invoke_tgrm_call_update(1, 0, 0, 0, 1, 
TGRM_CALL_BUSY, TGRM_CALL_VOICE, TGRM_DIRECTION_OUT)
Jul 7 11:30:52.020 EDT: htsp_timer - 10000 msec
Jul 7 11:30:52.344 EDT: htsp_process_event: [1/0/0, FXOGS_WAIT_TIP_GROUND,
E_DSP_SIG_0000]
Jul 7 11:31:02.021 EDT: htsp_process_event: [1/0/0, FXOGS_WAIT_TIP_GROUND,
 E_HTSP_EVENT_TIMER]fxogs_offhook_disc
Jul 7 11:31:02.021 EDT: htsp_timer_stop
Jul 7 11:31:02.021 EDT: [1/0/0] set signal state = 0x4 timestamp = 0
Jul 7 11:31:02.021 EDT: dsp_set_sig_state: [1/0/0] packet_len=12 
channel_id=128 packet_id=39 state=0x4 timestamp=0x0
Jul 7 11:31:02.021 EDT: htsp_timer - 2000 msechtsp_release_req: 
cause 16, no_onhook 0
Jul 7 11:31:02.021 EDT: htsp_process_event: [1/0/0, FXOGS_ONHOOK, 
E_HTSP_RELEASE_REQ]fxogs_onhook_release
Jul 7 11:31:02.021 EDT: htsp_timer_stop2
Jul 7 11:31:02.021 EDT: htsp_timer_stop3
Jul 7 11:31:02.021 EDT: TGRM: reg_invoke_tgrm_call_update(1, 0, 0, 0, 1, 
TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_OUT)
Jul 7 11:31:02.021 EDT: flex_dsprm_close_cleanup
Jul 7 11:31:02.289 EDT: htsp_process_event: [1/0/0, FXOGS_ONHOOK, E_DSP_SIG_0110]
Jul 7 11:31:02.373 EDT: htsp_process_event: [1/0/0, FXOGS_ONHOOK, 
E_DSP_SIG_0100]fxogs_onhook_tip_ground
Jul 7 11:31:02.373 EDT: htsp_timer - 7000 msec
Jul 7 11:31:02.373 EDT: TGRM: reg_invoke_tgrm_call_update(1, 0, 0, 0, 
1, TGRM_CALL_PENDING, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
Jul 7 11:31:02.777 EDT: htsp_process_event: [1/0/0, FXOGS_TIP_GROUND, 
E_DSP_SIG_1100]fxogs_ringing_disc
Jul 7 11:31:02.777 EDT: htsp_timer_stop
Jul 7 11:31:02.777 EDT: htsp_timer_stop2
Jul 7 11:31:02.777 EDT: htsp_timer_stop3
Jul 7 11:31:02.777 EDT: TGRM: reg_invoke_tgrm_call_update(1, 0, 0, 0, 1, 
TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)

    These are some symptoms and methods to verify the presence of an AC component on the T&R leads:

    • In the Voice Port Module (VPM) debugs for the outbound call attempt, the port times out waiting for the tip-ground from the CO. This might be accompanied by a false ring detection, which is shown in the debugs by a state change to E_DSP_SIG_0000. The presence of the false ring detection event is a sure sign of an AC component on the T&R leads, but the absence of the detection event in the debugs does not necessarily mean that the line is clean of AC noise.

    • If possible, arrange for a digital storage oscilloscope to be brought out on site to examine the Tip-to-Ground and Ring-to-Ground waveforms on an RJ-11 pair. Any AC component on the lines should be easily visible. If a digital storage oscilloscope is not available, as is often the case, then you can use a true-RMS leavingcisco.com DMM to obtain an estimate of the magnitude of the AC component on the line, if present. Measure the RMS AC voltage between Tip-to-Ground and Ring-to-Ground and—assuming a true sinusoidal 60 Hz waveform—the Vrms measurement can be multiplied by √2 to provide the peak voltage of the AC noise.

  6. If it is determined that there is AC interference on the T&R leads, further tests can be done to determine if the elimination of the AC component on the line will indeed allow the VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, or EVM-HD FXO equipment to make an outbound FXOGS call. For instance, line filters like the L'il Zapper leavingcisco.com can be used to suppress the AC noise component. If the line filter testing proves successful, it would then be prudent to contact the telephony service provider to inquire if there is anything they can do to mitigate the amount of AC noise on the line.

If Problems Persist

If outbound call problems persist and the previous troubleshooting steps have been investigated and exhausted as possible culprits, the next step is to take advantage of software improvements in the latest Cisco IOS software and DSPware releases. There are three enhancements available, further discussed in this section, which may alleviate the FXOGS outbound call issue:

Tip-Ground Detection Enhancements

It is preferable that you see the actual tip-ground acknowledgement from the CO, on outbound call attempts from an FXOGS voice-port. As discussed in earlier sections, however, under conditions of significant AC noise interference on the GS circuit, the Cisco FXOGS voice-port’s ability to detect this tip-ground acknowledgement may be impaired. In an attempt to make the tip-ground detection algorithm more tolerant of AC interference, two enhancements were made to the DSPware:

Address Unstable Tip-Ground Signals

The detection algorithm in the DSPware which attempts to determine whether a tip-ground acknowledgment has been returned from the PSTN after an outgoing ring-ground has been changed such that it can now handle situations where the tip-ground signal is somewhat unstable. For example, the tip-ground acknowledgment signal may appear unsteady due to the oscillating voltages imparted by the 60 Hz AC noise component on the line.

Address False Incoming Ring Signals

Another DSPware enhancement prevents the detection of a false ring event due to the presence of a 60 Hz AC noise component of a relatively large magnitude. As discussed earlier in this document, it is possible that this type of interference be interpreted by the FXOGS voice-port as an incoming ring signal. Such a false detection only takes place in the time interval between the ring-ground event and the tip-ground detection.

Tip-Ground Detection Spoofing Enhancement

As a last resort, if all else fails, it may be necessary to spoof the detection of the tip-ground acknowledgement from the PSTN. A new voice-port command has been introduced in Cisco IOS software which may be issued in an attempt to achieve proper outbound call behavior. This is the syntax of the new command under an analog FXOGS voice-port:

!
voice-port X/Y/Z
 signal groundStart
 groundstart auto-tip delay <1-9999ms>
!

The default tip-ground delay is 200 ms. This default setting can be configured as groundstart auto-tip. The default settings should be adequate for most field situations.

Note: This command requires the voice-port CLI to support the command, and that the Cisco IOS software be paired with DSPware which understands this auto-tip delay setting. These two defect IDs represent the two halves of this necessary combination of software:

If the groundstart auto-tip command is available under the voice-ports, Cisco IOS software will permit you to configure the command, whether compatible DSPware is also present or not. If the DSPware is incompatible with the Cisco IOS software, however, the FXOGS voice-ports will come up in a S_OPEN_PEND state (seen with show voice call summary), which indicates that they have not initialized themselves properly.

IOS and DSPware Requirements for FXOGS Enhancements

This table displays compatible Cisco IOS software and DSPware pairings and where each of the three different tip-ground detection enhancements may be found:

Enhancement Type Cisco 1751, 1760 Cisco 2430, 2600XM, 2691, 2800**, 3600, 3700, 3800**
DSPware* IOS DSPware* IOS
Unstable Tip-Ground Tolerance Enhancement 4.1.42 12.3(11)T31 4.3.24 12.3(7)T72, 12.3(8)T63
4.4.402 12.3(11)T24, 12.3(11)T31
False Ring Ignore Enhancement 4.1.42 12.3(11)T31 4.3.24 12.3(7)T72, 12.3(8)T63
groundstart auto-tip voice-port CLI Enhancement 4.1.42 12.3(11)T31 4.3.24 12.3(7)T72, 12.3(8)T63
4.4.402 12.3(11)T24, 12.3(11)T31
* It is implied that the enhancement also exists in all subsequent releases of DSPware from the same release family. For example, if the enhancement is in the 4.3.x release family beginning with 4.3.24, then release 4.3.25 and 4.3.33 also have the enhancement.
** The Cisco 2800 platform family is supported in IOS 12.3(8)T4 and later. The Cisco 3800 platform family is supported in IOS 12.3(11)T and later.
1—Cisco IOS Software Release 12.3(11)T3 is planned for late January to early February 2005.
2—Cisco IOS Software Release 12.3(7)T7 is planned for late January to early February 2005.
3—Cisco IOS Software Release 12.3(8)T6 is planned for early January 2005.
4—Cisco IOS Software Release 12.3(11)T2 is planned for late November to early December 2004.

Procedure For Using Tip-Ground Detection Enhancements

If all troubleshooting steps have been attempted, and you have determined that only a Cisco IOS software release that has the new tip-ground detection enhancements may alleviate the problem, follow this sequence of steps:

  1. Upgrade to the appropriate Cisco IOS software release.

    Attempt to make outbound calls over the FXOGS voice-port. If the calls are now successful, the tip-ground detection enhancements which are more tolerant of AC noise on the line have performed their task well. No additional work needs to be done; do not configure the groundstart auto-tip command under the voice-port.

  2. If the outbound call attempts still fail after the Cisco IOS software upgrade, then evaluate whether the new groundstart auto-tip command might resolve the issue.

Use LoopStart FXO

If all avenues of investigation and troubleshooting have failed, it may be advisable to inquire with the CO if LoopStart service can be provisioned instead of GroundStart. LoopStart signaling on the VIC2-2FXO, VIC2-4FXO, NM-HDA FXO, and EVM-HD FXO analog voice products has been observed to function well in the field.

Contact Cisco Technical Support

If you have completed all troubleshooting steps and require further assistance, or if you have any further questions regarding this troubleshooting technical document, contact Cisco Systems Technical Support by one of these methods:

Related Information

Revision History

Revision Publish Date Comments
1.0
14-May-2006
Initial Release

Was this Document Helpful?

FeedbackFeedback

Contact Cisco