The purpose of this document is to provide a basic guide to troubleshoot and resolve Cisco fax relay issues. The technical intricacies of faxes and fax relay are not covered in detail, but you should be able to troubleshoot for a majority of common fax relay issues. An overview of fax and Cisco fax relay is also provided.
Readers of this document should be aware that several techniques are used to pass fax calls across a Packet Telephony network on Cisco IOS® gateways:
In addition, three main Packet Telephony technologies are in use today, collectively referred to as Voice over "X" (VoX):
The primary focus of this document is Cisco proprietary fax relay on Cisco IOS gateways, which operates across VoIP networks. T.38 Fax Relay and the other VoX technologies are also discussed.
The information in this document is based primarily on Cisco IOS Software Release 12.2(5), although most of the information will also be useful for other Cisco IOS Software releases.
Some debug information was taken from a Cisco IOS gateway that ran Cisco IOS Software Release 12.2(7). This point is noted in the Debugging section of this document.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you work in a live network, ensure that you understand the potential impact of any command before you use it.
For more information on document conventions, see the Cisco Technical Tips Conventions.
Most modern fax devices are Group 3 compliant. Fax Group 3 is a standards-based technology that is made up primarily of the T.4 and T.30 ITU recommendations. T.4 pertains to how the fax image is encoded by a fax device, and T.30 details the facsimile negotiations and communication protocol.
Group 3 fax devices were designed to be used over the public switched telephone network (PSTN). Since the PSTN was designed for human speech, Group 3 uses analog encoding or modulated signals as would an analog modem. Both analog modems and fax machines are digital devices that must use a modulated analog signal to pass the digital information over the PSTN. This modulated signal can usually be heard as different audio tones.
Gateways in a VoX network initially treat voice and fax calls the same. Both types of calls cause the gateway to load the configured voice compression codec in the digital signal processor (DSP). For more information about DSPs, see Voice Hardware: C542 and C549 Digital Signal Processors (DSPs).
The voice compression codecs are usually high compression codecs so that less bandwidth is used for each voice call. High compression codecs, such as G729 and G723, are optimized for voice and compress the voice to a low bandwidth (8 kbps, which excludes overhead for G.729) yet maintain good quality, but G.729 and other high compression codecs are not optimized for fax. In fact, the modulated signals of fax transmissions usually do not correctly pass through when these codecs are used, and fax calls fail as a result. For more information about compression codecs, see Voice over IP - Per Call Bandwidth Consumption.
Faxes can be transmitted successfully when codecs with lower compression ratios or no compression at all (such as G.726 and G.711 with no echo cancellation or Voice Activity Detection) are used. This method of fax transmission through the voice codec is usually referred to as inband faxing or fax passthrough. A technique known as upspeeding allows the gateway to initially load the configured voice compression codec into the DSP for voice calls and change it to a low compression codec if fax tones are detected.
With inband faxing, the initial modulated signal is encoded and compressed by the codec on the source router and passed across the VoX network, just as if it was a voice sample. The termination gateway then uncompresses and decodes the sample and plays it out to the termination fax machine. Fax relay functions differently. It is a protocol that terminates the modulated signal, extracts the digital information, and then relays the digital information through the data network with data packets. At the termination side, the digital information is extracted from the packet, modulated, and played out.
A fax call can be divided into two parts: fax negotiation and page transmission.
The half-duplex fax negotiation occurs at the start of a fax call. V.21 modulated High-level Data Link Control (HDLC) data frames are passed at a speed of 300 bps. These data frames are sent in a standard sequence between the origination and termination fax devices. In this exchange, each fax device exchanges its capabilities, and both fax devices agree on the fax session characteristics before the page transmission takes place. This illustration shows a traditional fax call over PSTN.
Some capabilities that are exchanged and negotiated are page transmission speed, Error Correction Mode (ECM), resolution, page coding, and scan time. Page transmission speed (training) is an important negotiation that determines the speed at which the fax will send its information. Faxes try to train at the highest modulation speed possible based on the parameters exchanged initially. Fax devices will retrain to a lower speed if the training at a higher speed fails.
Page transmission occurs when the training part of the fax negotiation phase is complete with the use of the previously agreed upon parameters. The page information is coded into scan lines with a standard resolution of 203H x 98V dots per inch. Fax images are typically compressed and encoded with either Modified Huffman (MH) or Modified Read (MR) encoding. MH usually compresses at a 20:1 ratio. MR encoding typically provides a 20 percent compression improvement over MH but is slightly less resilient to error.
When page transmission occurs, a bit rate is used that is higher than the initial 300 BPS that is used in the call setup negotiation. The bit rate used for the page transmission is confirmed within training. These are some of the common rates used in fax page transmission:
V.27ter – 2400/4800 BPS
V.29 – 7200/9600 BPS
V.17 – 14400 BPS
Note: These V.XX specifications used for page transmission (V.27ter, V.29, V.17) and fax negotiation (V.21) are specifications that define how digital data is to be sent over analog phone lines. Data modems are also able to use these specifications even though most data modems have migrated to much faster speeds.
Fax relay is a technique used to overcome the deficiency in high compression voice codecs (G729, g723, etc.) when these codecs try to pass fax traffic.
Since a fax call is treated as if it is a regular speech call, the DSP in each gateway is put into voice mode, after which human speech is expected to be received and processed. Within the life of the call, if a fax answer (CED) or call (CNG) tone is heard, the DSP does not interfere with the speech processing. It allows the tone to continue across the VoX call leg.
A normal fax machine, after it generates a CED or hears a CNG, transmits a T.30 DIS message as part of a fax handshake. This process usually occurs at the termination fax machine. The DSP of the termination gateway will then detect the HDLC flag sequence at the start of the DIS message and initiate fax relay switchover. This means that it unloads the voice codec and loads a fax codec to handle the fax call that takes place.
Notification is also sent to the DSP on the other side of the VoX network so that the DSPs on each side of the fax call use the fax codec. Dependent on the fax relay protocol used, the notification mechanisms differ. With the fax codec loaded, the DSPs demodulate the T.30 HDLC frames, extract the fax information, and pass it between the routers with one of these fax relay protocols:
Proprietary Cisco fax relay for VoIP – Fax relay is the default mode to pass faxes through a VoIP network, and Cisco fax relay is the default fax relay type. This capability has been supported in Cisco IOS Software Releases 11.3 and later, is widely available, and uses RTP to transport the fax data.
Standards-based T.38 fax for VoIP – T.38 has been available in Cisco IOS Software Releases 12.1(3)T and later on some platforms. It can be enabled with the fax relay protocol t38 command configured under the VoIP dial peer and uses UDP to transport fax data.
Standards-based FRF.11 Annex D for VoFR and VoATM.
It is important to understand that unlike inband faxes or fax passthrough, fax relay breaks down the T.30 fax tones into their specific HDLC frames (demodulation), transmits the information across the VoX network with the fax relay protocol, and then converts the bits back into tones at the far side (modulation). The fax machines on either end send and receive tones and are not aware of a demodulation/modulation fax relay process.
Cisco fax relay and T.38 fax relay also differ from T.37 fax store and forward. T.37 provides a standards-based method to allow a VoIP gateway to receive this:
Most Cisco voice gateways currently support two methods to transmit fax traffic across the IP network
Fax Pass-Through—In fax pass-through mode, the gateways do not distinguish a fax call from a voice call
Cisco Fax Relay— In fax relay mode, the gateways terminate the T.30 fax signaling
Cisco fax relay and T.38 fax relay also differ from T.37 fax store and forward. T.37 provides a standards-based method to allow a VoIP gateway to receive this:
A fax from a fax machine and forward it to an SMTP-capable mail server. The mail server can then deliver the fax to a user as an email message.
An email message from a mail server and modulate it into a fax signal for receipt by a regular fax machine.
This diagram illustrates fax relay over a VoX network. The fax connection to the origination and termination gateways can be directly into FXS ports on the gateway, or can be via a PBX or the PSTN into an E1, Basic Rate Interface (BRI), FXO, or E&M port on the gateway.
Fax relay is on by default on VoIP/VoFR/VoATM platforms such as the Cisco 3810, 2600, 3600, and 5300. If voice calls complete successfully between two routers, fax calls should also work, but when fax relay does not work or performance needs to be improved, there are some fax relay specific commands that you can issue as a precursor to troubleshoot the problem:
The fax rate command is configured under the VoFR or VoIP dial-peer in configuration mode. The default setting is fax rate voice and this does not appear in the configuration under each dial-peer.
| fax rate Command
vnt-3660-23(config-dial-peer)#fax rate ?
12000 FAX 12000 BPS
14400 FAX 14400 BPS
2400 FAX 2400 BPS
4800 FAX 4800 BPS
7200 FAX 7200 BPS
9600 FAX 9600 BPS
disable Disable Fax Relay
voice Highest possible speed allowed by voice rate
The fax rate voice setting restricts the fax rate to the codec bandwidth. This restriction means that, if the dial-peer is configured to use the default G.729 voice codec that compresses voice to 8 kbps, the fax rate voice setting would not allow fax calls to exceed this codec bandwidth. The fax would be limited to a bandwidth of 7200 BPS, even if it tried to initially negotiate at a higher bandwidth of 14400 BPS or 9600 BPS.
A common complaint is that faxes that had completed within a certain time when connected via the PSTN now take twice as long. If a low bandwidth codec such as g729 has been configured with the default fax rate voice setting, this behavior is expected. With the fax rate command, it is possible to configure fax transmissions to use a bandwidth greater than the codec compression. The command fax rate 14400 allows fax calls to negotiate to a maximum of 14400 BPS regardless of the voice codec configured. This configuration resolves the problem of longer completion times.
The main purpose served by the fax rate command within VoX networks is to provide deterministic bandwidth usage per call. The fax rate voice setting is the default because it ensures that both voice and fax calls use the same amount of bandwidth within the VoX network. This consideration should be understood when the fax rate is changed to something greater than that of the codec bandwidth. In addition, some fax machines can operate more stably at a rate different from the default. In this case, the fax rate command can be used to test operation at different speeds.
Note from the router output that fax relay can also be disabled if you issue the fax rate command. A valid troubleshooting technique is to disable fax relay and configure high bandwidth codecs such as G711. This technique is discussed in the "Troubleshooting" section under 6. Disable Fax Relay and Change Codec for Passthrough.
The fax-relay ECM disable command is available for Cisco proprietary fax relay only and is issued to disable Error Correction Mode (ECM) negotiation between a pair of fax machines. ECM ensures that the faxed pages are transmitted error free and is a feature that is usually found on higher end models. Unfortunately, ECM has a low tolerance (approximately two percent) for jitter and packet loss, but when this negotiated feature is enabled, it can result in a higher fax failure rate in lossy VoX networks. Incomplete output on the termination fax is a symptom of failures due to packet loss.
If both fax machines agree within the fax negotiation phase, ECM is enabled, but within fax relay the routers demodulate the fax tones into their true HDLC frame format. As a result, the routers are able to intercept and overwrite the field in the frame that indicates ECM status. If a fax machine transmits that it is capable of ECM, the router can change this parameter so that the other fax machine believes that ECM is not supported. Both fax machines are then forced to disable ECM, which means the fax data must be transmitted with standard T.4 data.
Fax reliability is increased greatly with ECM disabled, even with much higher packet loss (about 10 percent) and delay. In addition, this command automatically enables a Cisco IOS feature called packet loss concealment whereby lost scan lines are repeated to spoof the fax machine to believe that it has received all the data.
Note that, while ECM can improve the success rate of fax transmissions in lossy VoX networks, the basic network problems remain and should be addressed prior to the occurrence of other problems.
A straightforward configuration step performed under the VoIP dial-peer is to disable ECM. As noted in the command reference, this command currently works only for VoIP dial-peers. It can be configurable for VoFR and VoATM, but it does not disable ECM.
| fax-relay ECM disable Command
vnt-3660-23(config-dial-peer)#fax-relay ECM ?
disable Disables ECM mode for fax relay
The fax NSF command is used to prevent the transfer of proprietary fax capabilities. Since the fax relay implementation of the router demodulates and decodes the fax tones based on the T.30 specification, transactions or encoding that are proprietary break fax relay and cause the fax transmission to fail. Certain brands of fax machines use these proprietary encodings to signal the the availability of enhanced capabilities, which help a fax manufacturer distinguish its products from others. This capability notification takes place with the optional Non Standard Facilities (NSF) field within fax negotiation.
When you issue the fax NSF command, the router overwrites the NSF, so only standard fax transactions will occur. Vendor-specific facilities that are beyond the standard Group 3 requirements, and that break Cisco fax relay, will not be usable. Usually the NSF is set to all zeros when this command is issued, and this should fix problems caused by the NSF field.
| fax NSF Command
vnt-3660-23(config-dial-peer)#fax NSF ?
WORD Two-digit country code + four-digit manufacturer code
vnt-3660-23(config-dial-peer)#fax NSF 000000
The fax protocol command is required for VoIP to specify which fax relay protocol (T.38 or Cisco fax relay) will be used.
| fax protocol Command
vnt-3660-23(config-dial-peer)#dial-peer voice 3 voip
vnt-3660-23(config-dial-peer)#fax protocol ?
cisco Use Cisco proprietary protocol
system Use choice specified in global fax protocol CLI
t38 Use T.38 protocol
The cisco option configures Cisco fax relay. The t38 option disables Cisco fax relay and enables T.38. Certain voice platforms such as the Cisco 5350 and 5400 support only T.38. For interoperability, T.38 must be explicitly configured on platforms where Cisco fax relay is the default. The system option allows the dial-peer to inherit the fax relay protocol that is configured globally with the voice service voip command. If nothing is configured under the voice service voip command, the default is Cisco fax relay.
The default setting of the fax protocol command is the system option. Since the system option defaults to Cisco fax relay, VoIP dial-peers always default to Cisco fax relay when nothing is explicitly configured globally.
| fax protocol Command
voice service voip
!--- Note that there is no fax protocol configured so the !--- default is Cisco fax relay. Any dial-peer that points !--- here will use Cisco fax relay as the fax protocol.
dial-peer voice 3 voip
session target ipv4:10.1.1.1
!--- Note that since fax protocol is not configured under !--- this VoIP dial-peer, the default is fax protocol system, !--- which automatically tells this dial-peer to inherit the !--- fax configuration from voice service voip above.
These steps have been shown to resolve the majority of issues that involve fax relay over VoIP, VoATM, and VoFR. Information that is specific to a particular encapsulation type or fax relay type will be noted.
The first step to take when you troubleshoot any fax relay issue is to reduce the problem to its simplest form. Many issues arise in situations where multiple fax machines are not able to pass fax traffic. It is easiest to isolate two fax machines that have problems and concentrate on a simple topology. Determine how these machines are connected to one another and resolve the issue between this pair first. In addition, you should draw a complete picture of the topology and determine how the fax machines are interconnected.
To troubleshoot one issue at a time minimizes confusion and allows for methodical troubleshooting. It is also possible that the solution for this problem will resolve other fax relay problems in the network. Most fax relay problems result from poor VoX configuration or network design. These lead to basic connectivity problems and physical line or packet loss and jitter problems.
After you have identified and isolated the problem, the next steps are to verify the basic VoX configuration and monitor the health of the network.
Basic fax connectivity issues can be the result of these factors:
Normal voice connectivity problems.
Confirm that normal voice calls can be completed before you investigate fax connectivity. If there is no telephone attached, unplug the fax machine and connect a regular telephone. If normal voice calls do not connect, the issue may be VoX-related, and you can troubleshoot the problem as a normal voice connectivity issue before you proceed with fax troubleshooting.
Configuration problems related to dial peers such as these:
Wrong dial peer matched.
After you ensure that voice calls can be successfully completed in both directions through the VoX network, issue the show call active voice brief command and note the dial peers that are matched with each voice call.
Note: When you have VoIP trunks, you should be able to see all the call legs with the show call active voice brief command. In some versions of Cisco IOS Software Release 12.2, there is a bug in the show call active command and a fax call that comes through a VoIP trunk no longer appears. When you issue a show call active fax brief command, the call is now listed. For more information about this bug, see Cisco bug IDs CSCdx50212 (registered customers only) and CSCdv02561 (registered customers only)
Note: Ensure that the configured dial peer is the peer that is matched.
In this command output, you can see that the outbound VoIP call leg uses peer ID 100.
| show call active voice brief Command
ms-3640-13b#show call active voice brief
Total call-legs: 2
1218 : 51710253hs.1 +415 pid:400 Answer 400 active
dur 00:01:08 tx:3411/68220 rx:3410/68200
Tele 3/0/0:43: TX:68200/6820/0ms g729r8 noise:0 acom:2
1218 : 51710396hs.1 +272 pid:100 Originate 100 active
dur 00:01:09 TX:3466/69320 rx:3467/69340
IP 18.104.22.168:17092 rtt:56ms pl:64730/0ms lost:0/1/0
Total call-legs: 2
A common cause of fax relay problems is that the correctly configured dial peer is not the one that is matched. It is also common that there is no particular inbound VoIP dial-peer configured on the termination gateway, and Cisco IOS Software selects the first appropriate (and default) VoIP dial peer as the inbound dial peer. The parameters for this inbound dial peer may not match those of the outbound dial peer on the origination gateway.
It is not always required that you have identical configurations on the outbound and inbound VoIP dial-peers. When you have a fax relay problem, though, make sure you have a dedicated inbound VoIP dial-peer on the termination router and that its configuration matches the configuration of the outbound VoIP dial-peer on the origination router. This configuration for ISDN-connected routers is an example of specific, matched VoIP dial peers for the destination pattern "5..." outbound on the origination gateway and inbound on the termination gateway.
| Originating Gateway
|| Terminating Gateway
!--- Incoming POTS peer:
Dial-peer voice 1 pots
Incoming called number.
!--- Outgoing VoIP peer:
Dial-peer voice 2 voip
Session target ipv4:22.214.171.124
Fax rate 14400
fax protocol t38
!--- Outgoing POTS peer
Dial-peer voice 10 pots
!--- Incoming VoIP peer:
Dial-peer voice 20 voip
Incoming called-number 5…
Fax rate 14400
fax protocol t38
More information on matched dial peers both inbound and outbound, VoIP, and POTS can be found in Voice - Understanding How Inbound and Outbound Dial Peers are Matched on Cisco IOS Platforms.
Another method you can use to check dial peer matches is to issue the debug voip ccapi inout command. The debug output from this command will show an ssaSetupPeer message that lists all the dial-peers that match the called number. A ccCallSetupRequest message follows with the outbound peer option that indicates the outbound VoIP dial-peer selected. When multiple VoIP dial peers are configured for the same destination, it is possible that the initial call setup will fail and another dial peer tried. In this case another ccCallSetupRequest will appear in the debug.
| debug voip ccapi inout - Originating Gateway
.Jun 4 21:06:43.461: ssaSetupPeer cid(19)
peer list: tag(400) called number (5074)
.Jun 4 21:06:43.461: ccCallSetupRequest
(Inbound call = 0x13, outbound peer =100,
dest=, params=0x62F1CC70 mode=0, *callID=0x62F1CFD8,
prog_ind = 0)
On the termination voice gateway the first line of the debug voip ccapi inout call trace as shown below will be a cc_api_call_setup_ind message with a peer_tag option that refers to the inbound VoIP dial peer on the termination gateway.
| debug voip ccapi inout - Terminating Gateway
.Jun 4 21:06:43.461: cc_API_call_setup_ind
Incorrectly configured dial peers on one or both sides
After you confirm that the correct dial peer is matched (in this case dial-peer 100 for the origination gateway and dial peer 400 for the termination router), confirm in the configuration that the dial-peer is configured correctly for fax. Some common errors to check for on both sides of the call are these:
Fax relay is disabled (that is, the fax rate disable command has been issued on the dial peer) while a low bandwidth codec has been in use.
The dial peer on one voice gateway is configured for Cisco fax relay, but the other voice gateway is a Cisco 5350/5400. The Cisco 5350/5400s only support T.38, so the negotiation will fail.
The default dial peer that is used inbound on the termination gateway and default parameters do not match with the outbound dial peer on the origination gateway.
Incorrect Compand Type
The companding type for the US is µ-law; for Europe and Asia, it is a-law. You can issue the show voice call command to see which value is currently configured. If on a BRI or E1 port, the companding type on the router does not match the one on the connected device, and calls sometimes fail and sometimes connect, but the voice becomes heavily distorted so that the person becomes unrecognizable and a high low-pitch noise level appears.
In Cisco IOS Software Release 12.2(3), the compand-type command is not on on the BRI ports, and the companding type is the default value. For more information about this bug, see Cisco bug IDs CSCdv00152 (registered customers only) and CSCdv01861 (registered customers only) .
Other basic connectivity problems not related to dial peers include these:
Cisco IOS Software incompatibilities on gateway pairs.
Again, it is not always required that Cisco IOS Software releases match, but it is recommended to check releases when problems occur.
Compressed Real-Time Transport Protocol (cRTP).
There are several known problems associated with cRTP. Fixes are available for these problems, and it makes sense to disable cRTP when problems occur to check whether a Cisco IOS Software upgrade is an appropriate course of action.
On Cisco AS5300 voice gateways, ensure that the VCWare and Cisco IOS Software are compatible.
Fax connectivity problems across the PSTN.
If voice calls work in both directions but fax calls fail in at least one direction, check that normal faxes between these two machines works across the PSTN. In other words, ensure that the fax machines successfully transmit faxes to each other with the PSTN without traversing the VoX network. If they do not, the fax machines can have problems that need to be addressed before you consider fax relay problems.
If there are any T1 or E1 digital connections used by the routers that perform fax relay, make sure that they are error free. Fax relay is very sensitive to errors on digital interfaces, especially slips. The errors will not be noticeable on voice calls but they can cause faxes to fail.
| show controller T1(E1) 1/0 Command
vnt-3660-23c#show contr t1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20010805, FPGA: 15
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
Data in current interval (132 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs,
0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
0 Unavail Secs
The T1 or E1 controllers at both origination and termination gateways should be error free. If errors occur, repeat the show controller (T1, E1, and 1/0 will vary) command several times within the call to see if the number of errors increases. The most common problem of slips is a synchronization problem that results in clocking errors.
In packet voice networks, it is usually sufficient to confirm that the router clocks from the line. If it does not, ensure the clock source line command is entered at the controller level, but in VoATM or TDM networks, where a clocking hierarchy is established and the routers need to pass clock through the network, additional considerations need to be made. The Clocking Plan document provides more information about synchronous clocking.
On 26xx / 366x routers, when you use the AIM VOICE card, the controller will show "controlled slips" unless you add the network-clock-participate and network-clock-select commands.
On the Cisco MC3810 platform, you need to configure the network-clock-select command and issue the show network-clock command to make sure the configuration has taken effect.
On the Cisco 7200VXR platform, the frame-clock-select command is required for the voice cards. This command is particularly important for the 7200VXR voice gateways because, by default, the internal TDM bus is not driven by the local oscillator. Since the E1 trunks are normally synchronized to the telephony network, the result is hidden clocking errors and intermittent fax transmission problems. More detail is available in Cisco bug ID CSCdv10359 (registered customers only) .
On the C4224 MFT cards, when they are to accept the clock from the line, under the controller t1 x/y you need to issue the clock source loop-timed command. This setting decouples the controller clock from the system-wide clock. It is then required to set the network-clock-select command. In this case, it would be network-clock-select 1 t1 x/y.
On some platforms, which include the Cisco 3660, 5300, 5350, 5400, and 5800, the router defaults to fax interface-type modem. The fax interface-type modem global configuration command forces fax calls to a modem (usually for T.37 Store and Forward fax) and not to a DSP. For Cisco fax relay to work, the fax call must be sent to a DSP, which means it must be configured with the fax interface-type vfc command.
| fax interface-type Command
vnt-3660-23c(config)#fax interface-type ?
modem Use modem card
vfc Use Voice Feature Card
vnt-3660-23c(config)#fax interface-type vfc
You must reload the router
Make sure you reload the router, or the command will not take effect. Fax calls will fail on the platforms with Cisco fax relay (or T.38), so this is an important command to check.
The fax interface-type vfc command was not necessary in Cisco IOS Software releases prior to 12.2. The problem is commonly seen when one of the voice gateways is upgraded to Cisco IOS Software Release 12.2 or later.
Each fax machine displays the remote fax machine ID on its LCD screen at the completion of the fax negotiation phase. It is unlikely that the fax machines could complete negotiation if the fax codec had not been successfully downloaded. On the other hand, if no remote fax machine ID is displayed, further debugging in this area is appropriate.
There are two ways to make sure that the voice gateways detect the fax transmission and successfully load the fax codec.
Issue the debug vtsp all command and the debug voip ccapi inout call trace. These debugs are discussed in detail in the Debugging section of this document.
Issue the show voice trace command. Show commands are less resource intensive on the router than debug commands and are preferable in production networks. This is an example output from a show voice trace command on an ISDN interface.
| show voice trace Command
BrisVG200gwy01#show voice trace 1/0:15
1/0:15 10 State Transitions: timestamp (state, event) -> ...
63513.792 (S_SETUP_REQUEST, E_TSP_PROCEEDING) ->
63515.264 (S_SETUP_REQ_PROC, E_TSP_ALERT) ->
63515.264 (S_SETUP_REQ_PROC, E_CC_BRIDGE) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63518.656 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63521.028 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63524.128 (S_SETUP_REQ_PROC, E_TSP_CONNECT) ->
!--- Fax tone detected:
63529.352 (S_CONNECT, E_DSP_TONE_DETECT) ->
63529.356 (S_LFAX_WAIT_ACK, E_PH_CODEC_ACK) ->
!--- Fax codec being downloaded to DSPs:
63529.356 (S_LFAX_DOWNLOAD, E_pH_CODEC_FAX) ->
63529.356 (S_LFAX_DOWNLOAD, E_DSPRM_PEND_SUCCESS) ->
In the previous steps, you established that voice calls work, faxes work through PSTN, and all digital interfaces in the fax relay path are free from errors. This step determines whether faxes can go through with fax relay disabled. Under the VoIP/VoATM/VoFR dial-peers, enter this:
| fax rate disable Command
vnt-3660-23(config-voiceport)#no echo-cancel enable
vnt-3660-23(config)#dial-p voice 3
vnt-3660-23(config-dial-peer)#fax rate disable
Make sure these commands are entered on both gateways. These commands disable fax relay, disable echo cancellation, and force the call to use a high bandwidth codec without VAD. The router then samples the tones like a normal voice call, and, with the high bandwidth codec (G.711), the most precise sample possible is captured. The tone to be replayed on the other side will be as accurate as possible. The caveat to this step is that, since G.711 is a 64 kbps bandwidth codec, each call will consume up to 80 kbps (for VoIP) when additional transport protocol overhead is added.
If this test is positive, two things have been accomplished. First, if per call bandwidth consumption is not a major issue for the network, there is now a potential fax passthrough workaround for the fax relay problem. Second, and more significantly, if bandwidth consumption is an issue, the problem has been isolated to the fax relay software, and you should open a TAC case.
If this test fails, it is likely that whatever causes the fax calls to fail with fax relay also causes the failures with this test. What comes to mind first is that the network can have a large amount of jitter or packet loss.
The easiest and most accurate way to determine if there is a packet loss is to do this:
Disable VAD on the VoX dial-peers.
Make a voice call between the same ports where the fax machines are connected. (Fax machines can serve as ordinary phones, or you can connect the handsets to the same ports where the fax machines are connected).
When the call is connected, do this:
Issue the show voice dsp command. You can see in the output that one of the DSP channels has the configured codec loaded. Usually the column "TX/RX-PAK CNT" shows that the transmit and receive packet counters are equal, which means that no packets are lost. If the counters are not equal, packets may get lost. Type the show voice dsp command several times at 30-second intervals to determine if the difference increases and packets are lost.
Issue the show voice call summary command to see which port (and time slot if applicable) is allocated to the voice call. Type terminal monitor and then issue the show voice call command with the voice port (and time slot if applicable) to get the detailed DSP statistics. In the "***DSP VOICE VP_ERROR STATISTICS***" section of the output, look for the counters. They are usually 0 or below 20. If the counter(s) is higher than 20, investigate the packet loss.
If the network appears to be lossy, it is not reasonable to expect fax relay to work reliably. It is possible to disable ECM, but further investigation is probably needed to ensure that QoS is provisioned end-to-end so that the Voice and Fax relay traffic has priority and is never lost within the congestion. The Related Information