Troubleshooting fax calls

Applies to VoipNow 3 and higher!

This article aims at guiding you towards a correct approach to fax troubleshooting and fax setting tweaks.

Overview

Not only is troubleshooting fax calls time-consuming, but also quite a complex process. Fax was not originally designed to be transported over IP and be exposed to issues such jitter, packet loss, and delays.

Passthrough is one method to transport fax over IP. Passthrough works like a normal voice call, the fax is encoded via an appropriate codec and the encoded samples are transported using RTP (Real-Time Protocol). Most codecs are using high-compression schema and are optimized for human speech, but they are lousy codecs. The tones used for fax are very different from human speech and it is difficult to find a codec for both fax and voice. Codecs such as G.726 can transport fax, but G.711 is the most frequently used. Therefore, we strongly recommend that you use only G.711 for passthrough. Passthrough is generally sensitive to packet loss and the results are fax failures, retransmissions which use more bandwidth and introduce delays in fax transmissions. Many service providers use G.711 passthrough or old VoIP gateways with only this type of functionality on their network.

T.38 relay is another method to transport fax over IP networks. It is a standard defined by ITU-T and should be the predominant choice for fax transmission. Notions such as UDPTL and IFP should be familiar to anyone debugging T.38 sessions. The UDP payload contains a UDPTL (UDP transport layer) header and a UDPTL payload. The UDPTL payload contains the IFP (internet fax packet) transport for fax information and optional redundancy/FEC (forward error checking) information. The interpretation of the T.38 specification has generated interoperability problems between different vendors.

Mandatory checks

Basic checks and tests

Perform the following basic set of checks:

Check power, connection to network, device error messages, fax machine paper and toner, proper device configuration (e.g. auto answer).
Test voice calls over the fax connection to check the integrity of the call path: call routing, call setup, establishment of audio session, voice quality.
Test calls over PSTN: if the device works over the PSTN, yet fails over IP, you need to make sure that this is a VoIP-related issue.
Review configurations: please check if any change has been recently made to the configuration; check again the configuration; for example, if VoipNow is configured only with G.711 passthrough and the device is using T.38 exclusively, faxing will fail; or, for instance, if only one end is using redundancy, faxing might encounter some problems.

Telephony and IP

Investigate telephony and IP.

Check connection between the fax device and the VoipNow Professional server.
Perform call-leg analysis: call legs between VoipNow Professional nodes (Asterisk-Kamailio), call legs between Kamailio and fax devices.
Check for clock slips on digital T1/E1 in case a span is incorrectly configured; you also need to make sure only one side is providing the clock; if you have issues with DSP clock synchronization, we recommend that you use T.38.
Check statistics about IP packets: packets sent, packets received, delays, jitters, out of sequence packets, dropped packets, bad packets, early packets, late packets, buffer overflow discard packets.
Check playout buffers: it is recommended that you use only fixed-length jitter buffers.

Switchover signaling

Investigate transition from G.711 passthrough to T.38 relay.

Troubleshoot G.711 passthrough/T.38 relay

More on fax troubleshooting

The steps above can require logs analysis or practice with third-party tools such as tcpdump, Ethereal, Wireshark. Some checks are often taken for granted because they might seem obvious. However, performing these tests can only lead to a quick solution.

If the audio path is checked and no result can be established, this means that RTP packets are discarded or corrupted in the network. If you detect echo, robotic voice, choppy voice, please look for network issues such as packet drops, policing, delays, queuing, etc. If the fax call is tested by passing the voice network (e.g. the fax device is directly connected to a regular analog line) and the fax is not transmitted correctly, you might be dealing with a technical fax machine issue.

If the telephony path uses digital spans in a third-party network, checking for errors is even a more complicated process; it involves communication with the third party, asking about devices (CISCO gateways, Catalyst switches, etc.) or logs. The best way to troubleshoot IP is by using packet captures. Please note that it is best to grab a capture as near as possible close to the sending/receiving fax actors (device, VoipNow Professional, etc.). Sometimes it is helpful to gather captures, server/device logs or DSP statistics for the same call in order to speed up the analysis.

For fax calls with RTP encapsulation, Wiresharsk offers a RTP stream analysis feature. Due to the fact that T.38 relay uses UDPTL, this type of call flow should be analyzed manually. As far as the RTP analysis, you need to quickly check jitter, lost packets, out of sequence packets. Usually G.711 passthrough packets are sent every 20 ms. In case you're manually searching for excessive jitter, please make sure the Time Display Format is set to Seconds Since Previous Packet.

If the VoipNow Professional server is receives the fax, if possible, it will try to immediately switch to T.38. The switching-based mechanism is using Re-Invites SIP messages which contain bodies with T.38 SDP information. Within the re-INVITEs there are SDP parameters that define the settings for the media stream. For example, the SDP line m=audio 17900 RTP/AVP 0 defines the UDP port number of 17900 that will be used for media stream and an RTP payload type of 0 which is G.711 u-law codec. Silence suppression or voice activity detection (VAD) is disabled if you see something like a=silenceSupp:off. After a re-INVITE the switchover is complete, if a 200 OK SIP message is received indicating the media capabilities of the other end. The T.38 parameters are also contained in the SDP part of a the SIP INVITE or re-INVITE SIP message (e.g. m=image 18346 udptl t.38).

When packet-loss problems and other IP impairments are detected, you need to resolve them immediately. If it is not possible, you can try disabling the Error Correction Mode (ECM) feature. Sometimes 2-percent packet loss will cause ECM faxes to fail. If ECM is enabled, the receiving fax will request any fax page received with errors to be re-sent until the page is error-free. On account of this property, even minor network errors can cause ECM faxes to take a long time to complete or fail. If you want to achieve a higher fax-completion rate with the possibility of occasional page imperfections, you can disable the ECM feature. For VoipNow, this setting can be modified in extensions.conf: if variable FAXECMENABLE is equal with "e" then the ECM is enabled; otherwise the ECM is disabled.

Another method for handling packet loss for T.38 traffic is redundancy which is more efficient than disabling the ECM. One drawback is that additional bandwidth will be consumed for redundant packets. In VoipNow Professional, the redundancy can be set in the filesip.conf using the value redundancy in the t38pt_udptl parameter.

Generally fax machines have a high tolerance for delays, but high-delay situations, such as multiple VoIP networks, can cause fax failures. To recognize such scenarios, it is best that you look at two critically mandatory T.30 packets: DIS and DCS. If such messages are repeating themselves instead of proceeding with confirmation, you are experiencing a high-delay scenario. The answering machine is sending DIS and the originating one is answering with DCS and a training sequence. The answering machine should send a confirmation (CFR), but if the DCS message is not received in approximately 3 seconds, it will send the DIS again because the DCS was not received in time. If the delay is not too big (no longer than a half a second, for example), adjusting the jitter buffer can help. Adjusting jitter buffers can expose your calls to jitter problems. Modify this setting only if you are familiar with the jitter characteristics of your network. For example, a 300-ms jitter buffer implies 600 ms of round trip additional delay per call.

Sometimes fax performance can be affected if the jitter buffer is dynamic, even though it has the advantage of immediately transmitting packets if there are no errors.

The T.38 parameter T38FaxMaxBuffer was not clarified by the T.38 specification and independent vendors have different opinions about the definition: buffer space for UDPTL packet, buffer space for IFP message, etc. This parameter should specify how much buffer space the other end has. Therefore, if some devices are using small buffers, it is important not to flood them with data. In VoipNow, this scenario can be noticed in the Asterisk log. e.g. "WARNING[15878]: udptl.c:1087 ast_udptl_write: (SIP/faxsend-0003*002-0003*001): UDPTL asked to send 59 bytes of IFP when far end only prepared to accept 58 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.". In sip.conf you can modify the value of the t38pt_udptl parameter to override the size for the T38FaxMaxDatagram sent by the remote fax device. e.g. t38pt_udptl=yes,redundancy,maxdatagram=400.

If you want to disable T38 in VoipNow (maybe you are connecting VoipNow to a gateway handling T.38), this can be done by modifying the value of t38pt_udptl parameter in sip.conf. e.g. t38pt_udptl=no

Show all results

Space shortcuts

Page tree