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.
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
RJ-11 or RJ-45 cable extenders
Digital Multi Meter (DMM) with true Root Mean Square (RMS) capability
Oscilloscope, if available
Regular analog telephones
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:
VIC-2FXO—Voice/Fax Network Modules for the Cisco 2600/3600/3700 Routers, Data Sheet
VIC2-2FXO and VIC2-4FXO—Cisco IP Communications Voice/Fax Network Modules for the Cisco 2600XM Series, 2691, 3600 Series, and 3700 Series Voice Gateway Routers, Data Sheet
NM-HDA FXO—High-Density Analog Voice/Fax Network Modules for the Cisco 2600, 3600, and 3700 Series, Data Sheet
EVM-HD FXO—Cisco High Density Analog and Digital Extension Module for Voice and FAX, Data Sheet
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
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.
Use these steps to troubleshoot GS call failures:
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 !
! dial-peer voice X pots destination-pattern 1234.... port 1/0:0 no digit-strip !
! 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.
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).
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:
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:
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.
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.
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:
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
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.
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.
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]
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 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.
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 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 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:
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:
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.
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.
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.
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**|
|Unstable Tip-Ground Tolerance Enhancement||4.1.42||12.3(11)T31||4.3.24||12.3(7)T72, 12.3(8)T63|
|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|
|* 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.|
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:
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.
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.
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.
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:
- Voice Hardware Compatibility Matrix (Cisco 17/26/28/36/37/38xx, VG200, Catalyst 4500/4000, Catalyst 6xxx)
- IP Communications Voice/Fax Network Module
- High-Density Analog (FXS/DIDFXO) and Digital (BRI) Extension Module for Voice/Fax (EVM-HD)
- Cisco High Density Analog Voice and Fax Network Module
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.