Hi All,
We do face common FAX issues like “FAX calls not working”, “FAX works but only a part of the page gets printed”, or “We get distorted FAX”. Here are some examples of incomplete and distorted FAX.
There is a basic protocol that you may follow in order to resolve FAX issues.
++ First we need to identify in which phase does the FAX fail. For that we need to have a clear understanding of the FAX phases.
> The Voice Call phase – This is a normal call that needs to complete(between the FAX endpoints) before the endpoints can tell each other that they are FAX machines.
> The Switchover phase – This is the phase where we have the FAX tone exchange so that the endpoints can share their capabilities with each other.
> The FAX Call – where a copy the pages are transferred from one endpoint to the other.
++ Normally if the voice call itself fails we need to troubleshoot in the normal way as if normal phone calls do not work. Specially in case of FAX we(at times) encounter a strange scenario where in inspite of same codec been attempted to negotiate, they do not negotiate. The Payload is at times a major concern, if they do not match, it fails in the voice call phase itself(might be with silence over call or fast busy at times). This behaviour does not allow the Switchover phase to start.
In such a scenario the command “rtp payload-type <word> <index>” is a help. Apart from that you need the normal troubleshooting like seeing the route, codecs, etc.
++ In the switchover phase what we normally look for is the codec. As per normal understanding we need to check the “show call active voice brief” and see what kind of FAX is it triggering and the codec negotiated for. (Remember: Codec is an important point of consideration during this phase).
Remember Passthrough switchover needs Codec up speed along with VAD being disabled and jitter buffered from adaptive to optimum. Plenty of switchover issues get resolved by the VAD consideration.
Apart from this what you might find real useful is the tool FAX Analyzer tool.(http://10.76.77.155/FAX/). You should bookmark this page. All what you need to do is collect PCM or WAV forms of the interaction and paste it over there and this tool analyzes everything for you. You can also compare working scenarios from the LAB. You need to understand the switchover phase in different scenarios. Please refer to the document: http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Fax_Call_Flow . It is a wonderful document giving you a clear understanding of how switchover happens and how and where DSPs are utilized and what all to expect in what scenario. Once you are able to identify where the problem is we can always go ahead with the appropriate troubleshooting steps. It may involve a DSP troubleshoot, and appropriate Up speed and Down speed. Remember Auto negotiate or hard-coding speed to 14400 bps at times may create a lot of problems. Also scenarios have been seen when
Note: I have faced issues where Fax Relay fails due to use of Compressed Real-Time Transport Protocol(cRTP) as they have several known issues, so disabling the cRTP(if used) is always a good bet.
For PSTN facing one-way FAX(one of my SRs): If voice calls work in both directions but fax calls do not in both direction(may be one way FAX), ensure that the fax machines successfully transmit faxes to each other using the PSTN without travelling over the PSTN. If they do not, the fax machines may have problems that need to be addressed before you consider fax relay problems.
Also make sure that T1/E1 controllers if used and if they have slips and other errors, that may at times lead to switchover failure and at times lead to distorted page outputs. Infact the snap pasted above is an example when the controller had slips. Resolving them by appropriate network clocking, etc resolved the issue of distorted FAX.
In certain platforms the fax interface-type is by default set to modem. In one of my SRs because of the fact that FAX relay to work, because you need to send it to DSP, you need to change this. VFC is used for utilizing the DSP in FAX relay. Use the command “fax interface-type vfc”
For the Last phase to work in case of FAX relay one important thing to consider would be to ensure that the codec is been downloaded to DSPs. For that you may use the command “show voice trace x/y:z”
Example:
BOSE# show voice trace 1/0:15
1/0:15 1
1/0:15 2
1/0:15 3
1/0:15 4
1/0:15 5
1/0:15 6
1/0:15 7
1/0:15 8
1/0:15 9
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:
That is all I can think of at the moment. These are some of the FAX SRs I have faced till date. Hope this helps you.
Still more to come.
Cheers,
Swagata Bose