Troubleshooting a Fax from Cisco UC to an Isolated Destination

Your company is an avid Cisco Unified Communications user and you recently successfully integrated a fax server using H323. The fax server is configured and working fine, however, you see an issue when sending a fax to a specific destination. Why are other fax destinations working, but not this one? How can I identify the source of the problem? What can I do to fix the issue?

Often our first impression is to think that the issue resides with the destination. However, through investigation, when this issue came up with many of our customers, we often found that not to be the case; the issue actually resided at the origin and not the destination.  We will explore the most probably causes to the problem and outline steps to resolving them.

PROBLEM

Unable to fax to an isolated destination number;  the other fax answers, but the transmission does not complete.

SOLUTION

There are 3 probable causes for this issue that we have encounter through our troubleshooting; we will discuss each one along with steps to resolving them.  For optimal results, troubleshoot them in the order they are listed.

Before we begin, place a call to the faulty fax number from a phone, see how it responds, listen for anything unusual, like a possible delay before it answers, this will help with the following steps.

Now the first step is to enable the following debugs on your Cisco Voice Gateway:

debug voip ccapi inout
debug isdn q931
debug h225 asn1
debug h245 asn1
debug cch323 h225
debug cch323 h245

and enable the following debugs on your Cisco Unified Communications Manager (CUCM):

Once you have changed these configurations, place a test call to the destination to which you are encountering the problem. Once this is done, you will be able to obtain the traces from the Cisco Voice Gateways logs from CLI (“show log” command) and from the CUCM logs extracted from RTMT. Now let’s start looking for the probable cause of the issue.

Probable Cause 1. Fast Start

Troubleshooting

We want to validate if  fast start is enabled and if it is causing the call to connect too soon on an outbound fax.

1. Verify if fast start is enabled on the fax server, the call manager trunk for the fax server (voice gateway – if using a fax machine) and on the Gateway.
   If fast start is enabled, we can quickly assess the likelihood that this causing our issue.
2. Call the destination fax; does it take more than 10 seconds for it to answer? If so, we probably found the issue.
3. You can confirm this theory by using the output of debug isdn q931.

Notice the time difference? The fax may be hanging up the call locally before the other side ever answers.

Resolution

1. Disable fast start on this fax.

Note: This generally should not cause any additional issues with this fax, however, if you are using a fax server, you will need to explore the following probably “Cause 2” as well, as you will likely need to apply both.

Probable Cause 2. H245 Tunneling and H245 Media exchange failure

Troubleshooting

In order to successfully identify, if this is the cause, you will need to jump straight into the logs.

1. Call Manager logs:047941843 |2015/10/20 14:49:12.717 |100 |SdlSig-I  |MXErrorReport                          |waitInterfacesCapabilities     |MediaExchange(1,100,135,6641)    |H245Interface(4,100,180,186222)  |4,100,13,412834.2^*^*                    |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] error=0
2. Voice Gateway logs (debug cch323 h245):2225069: Oct 22 09:34:38.443: %VOICE_IEC-3-GW: H323: Internal Error (TCS ack wait timeout): IEC=1.1.183.5.63.0 on callID 1710005

This is an error that is due to the H245 media capabilities exchange not being completed successfully.

Resolution

1. First, we need to disable H245 tunneling on the fax server for any of our H245 changes to take effect here.
   The interface may differ depending on the server, however, you should have similar options to what is seen above in the server’s advanced options.
2. Change from option “3” to option “0” for optimal compatibility.
   Check the documentation of your fax server in order to identify the proper settings for your server.

Note: This issue is very similar to the fast start issue in “Cause 1”. In this case, the fax waits for the call to connect before sending the capabilities, this exceeds the maximum timer in Call Manager for media capabilities exchange.

Probable Cause 3. Call not end-to-end ISDN – Cause Value 127

Troubleshooting

To identify if you are running into this issue, you will need the Gateway trace.

1. Extract the Gateway trace (debug ISDN q931):2201105: *Oct 19 17:07:22.055: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8  callref = 0xDD71 
   Cause i = 0x82FF – Interworking error; unspecified
   Progress Ind i = 0x8281 – Call not end-to-end ISDN, may have in-band info
   2201106: *Oct 19 17:07:22.059: //1690960/80998E7BDB5B/CCAPI/cc_api_call_cut_progress:
   Interface=0x4A5B272C, Progress Indication=NOT END TO END ISDN(1), Signal Indication=INTERCEPT(2),
   Cause Value=127
2.  Compare the setup of a functional call to the setup of a bad call. In our case, the comparison proved results:

Functional call

2201084: *Oct 19 17:07:20.347: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x5D72
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98390
                Exclusive, Channel 16
        Calling Party Number i = 0x2181, ‘1XXXXXXXXXX’
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, ‘1XXXXXXXXXX’
                Plan:ISDN, Type:National

Bad call

208879: *Oct 20 15:20:28.396: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x6331
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98393
                Exclusive, Channel 19
        Calling Party Number i = 0x0081, ‘1XXXXXXXXXX’
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0xA0, ‘1XXXXXXXXXX’
                Plan:Unknown, Type:National             

Resolution

This issue is due to the PSTN not accepting the information you are sending.

1. Modify this information on the gateway by changing the values in the following command:isdn map address .* plan isdn type unknown
2. Apply this command to your serial interface.

Now that you have completed your troubleshooting and have taken the necessary steps to resolve. Try sending the fax once again; at this point, the fax should be transmitted properly without any issues.

Interested in learning about the types of solutions we offer or discussing how we can help you with these and other types of Cisco Unified Communications issues, reach out we look forward to exploring personalized solutions with you.