T38

Open

Introduction

T.38 is a protocol used in VoIP Telephony to successfully transmit faxes over the Internet. Since faxes can fail using this method it is important to understand what is occurring during a T.38 fax call to troubleshoot the failures. The best tool one can use to assist in diagnoses and analysis is a PCAP in that it provides insight into the call flow of a fax. A basic understanding of how to obtain, filter, and interpret a PCAP is necessary when analyzing T.38 calls. This article assumes you have that basic understanding. If you do not, click here. Fax calls obviously have more detailed dialogue between the SIP gateways than a normal voice call and the purpose of this article is to offer clarification regarding this dialogue.

Overview of a T.38 VoIP Call

All fax calls begin as voice calls. Upon detection of a fax modem tone a ReINVITE is issued for T.38 (either side can ReINVITE for T.38 and is typically the side that detects the fax tone first. There is no RFC regarding which side issues the ReINVITE). Once the ReINVITE is accepted the T.38 protocol is used until the end of the transmission. VoIP fax calls can end one of two ways: either the call switches back to the original voice codec (via a ReINVITE), or a disconnect message is sent. This is usually dependent on the end fax terminal. If the end fax terminal is set for fax mode only, it will immediately disconnect the call after sending the disconnect message. It should be noted that the sending side can also disconnect without switching back to a voice codec. Several things MUST occur for successful T.38 faxing over VoIP:
A ReINVITE for T.38 must be offered and accepted

A handshake between faxing clients must occur and be successful (the handshake is when the faxing clients communicate and agree upon the terms of the transmission)

Proper messaging between faxing clients must occur (A detailed description of proper messaging is presented in this document)
 

T.30 Fax Tones
The fax tones for VoIP calls are in three varieties:
CNG: Origination Fax Calling Tone
CED: Fax Answering Tone
V.21 Preamble: Series of HDLC flags


Fax Detection
Three methods of fax detection are available and are based on the T.30 Fax tones (Note that both
CNG and CED tones are optional and not required):
The sending fax detects a CNG tone (Originating Fax Calling Tone) and triggers the T.38 ReINVITE.
The receiving fax generates a CED tone (Fax Answering Tone) and triggers the T.38 ReINVITE

On the receiving fax gateway, no CED is present so the Preamble flag sequence initiates the ReINVITE. The Preamble is always present and follows the CED tone when present. This method therefore exists because the CED is optional and the Preamble is always present.
 

T.30 Fax Signaling Messages

In a VoIP fax call, T.38 packets are preceded and succeeded by T.30 fax signaling messages. These messages include:
DIS: Digital Identification Signal indicating terminating fax capabilities (for example, data rate)

DCS: Digital Command Signal indicating transmission mode that will be used by originating fax (for example, transfer rate)
TCF: Training Check Sequences (sent for 1.5 seconds)
CFR: Confirmation to Receive indicating the receiving fax is ready to receive the document
MPS: Multipage Signal (sent after each page if more than one page is sent)
MCF: Message Confirmation indicating the page was received
EOP: End of Procedure message indicating there are no more pages to be sent
DCN: Disconnect message
Additional optional messages:
CSI: Called Subscriber Identification
TSI: Transmitting Subscriber Identification
 

Typical Fax Call

The following diagram illustrates a typical fax call. The call begins with an INVITE to the number, the voice channel is set up and a ReINVITE for T.38 is issued. The receiving fax sends it CED followed by the sending side returning the CNG. The handshake begins with the receiver sending its DIS and the other side responding with DCS. Training follows preamble and a confirmation to receive (CFR) message is sent. Additional training occurs and the fax page is transmitted. This illustration sends multiple pages and you can follow that in the diagram. After all pages are sent and received, the sending side sends the EOP message indicating it is finished with the transmission. The receiver follows up with another message confirmation (MCF). The call ends with the sender sending the disconnect message and a BYE. Please note, as outlined above, CED
and CNG are optional control messages; for this reason, they are not numbered in the diagram on the next page.

 

Troubleshooting Failures

If you are seeing failures when sending or receiving T.38 fax you can begin the troubleshooting process by obtaining a PCAP of an affected call. Use the above diagram as general guide to determine if you are getting proper flow and investigate where the breakdown might be. Most faxes fail due to improper handshake. This is usually identified by the receiving side not sending the CFR. You will see DIS and DCS messaging, preambles and training but no CFR. It is common to see preambles and training up to three times to negotiate the handshake. If you are seeing this type of behavior in your T.38 faxes you will want to tweak your settings if possible to alleviate the problem. Begin by slowing down the sending or receiving speed of the fax. Slowing down the speed to 9600-bit rate is a good starting point. You can also attempt to turn off error correction mode (ECM) as this is also known to cause failures. You may also want to look at your PBX settings for T.38. For example, in Asterisk, you would want to add the following in your sip.conf file:
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no

You will need to experiment to find out what works best for your specific set up. Another place to look is in the ReINVITE for T.38. View the media attributes in the capture to ensure there is nothing there causing the failure. Following is a snapshot of these attributes and an explanation of each.
Message Body
Media Description, name and address(m)=image 4517 udptl t38
Media Attribute (a):T38FaxVersion:0
Media Attribute (a):T38MaxBitRate:9600
Media Attribute (a):T38FaxFillBitRemoval:0
Media Attribute (a):T38FaxTranscodingMMR:0
 

Media Attribute (a):T38FaxTranscodingJBIG:0
Media Attribute (a):T38FaxRateManagement:transferredTCF
Media Attribute (a):T38FaxMaxBuffer:316
Media Attribute
(a):T38FaxMaxDatagram:316
Media Attribute (a):T38FaxUdpEC:t38UDPFEC
Beginning with the first attribute these are defined as:


Software/Fax version: If the INVITE does not identify a version, this will be populated with 0. If it does note a version, that version identifies the specific release of T.38 used.
Max bit rate: This line identifies the bit rate needed for the fax transmission.

Fill but removal: This line identifies whether the transmission requires additional data to identify blank sections of the fax (called fill bits) or if they can be removed to reduce bandwidth (Boolean value).
Transcoding MMR: This line identifies whether the Modified Media Read (MMR) compression format for faxes can be used to reduce the bandwidth of the transmission. This Boolean value 0 in this example indicates that the SIP device initiating the INVITE can't use the MMR transcoding.
Transcoding JBIG: This line identifies whether the compression technique for fax developed by the Joint Hi-Level Image Experts Group (JBIG) can be used to compress the data used on the fax transmission. The Boolean value 0 in this example indicates that the SIP device initiating the INVITE can't use the JBIG transcoding.
Rate management: This line indicates the T.38 fax rate management model that the transmission uses to ensure that both fax machines are functioning at the same speed. The two options are:
LocalTCF: A Training Check Frame (TCF) message from the receiving machine or gateway identifies the Bit Error Rate (BER) of the transmission.
 

TransferredTCF: A TCF message transmitted between endpoints identifies the BER; the receiving machine or gateway must use the TCF sent by the originating device.

Max buffer: This number identifies the maximum number of bytes of data that the INVITE-ing server can store before it must overwrite that data. After the responding SIP node negotiates this parameter, it helps the transmitting end of the call regulate the transmission to prevent the receiving buffer from being overrun. For example, if the max buffer = 316, this means the code allows for 316 bytes before
they are overwritten. The max buffer value you see in a packet capture probably won't be 316 as this field varies, and on the low end (for example, as low as 72).
Max datagram: This value identifies the maximum size of the payload inside an RTP packet. A common value for this parameter is 316.Take note that it is unwise to overload an individual RTP packet. UdpEC: UDP Error Control modes that allow options to provide some sort of redundancy. That's difficult on a transmission where you can't resend lost packets. One option is Forward Error Correction (FEC), which sends additional information in the initial packets sent identifying the number of packets to be sent. The two media attributes you would see here are:
Media Attribute (a): T38FaxUdpEC:t38UDPFEC
Or
Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy

(This attribute indicates which option the originating SIP device prefers) If you are not getting failures, a good place to start with is the Max datagram attribute. You may be overloading the UDP packets and thus causing the failures. If your PBX is in control of the ReINVITE, you should be able to configure a change. Additionally, you may want to disable the ReINVITE from your side to determine if the other side will issue the ReINVITE to see if that resolves the issue.
Additional Facts
T.38 is a real-time application with no time for retransmitting. But you can increase your chances of a successful transmission. Forward Error Correction (FEC) sends additional redundant data in the transmission that provide guidelines to replace lost data during the transmission. As previously stated, you may need to turn error correction off depending on your configuration.
 

T.30 packets set up the structure of the fax transmission, but do not interact with the outside world—that is the job of T.38; T.30 instead establishes the parameters, requiring an answering fax machine to send the CED (CallED station iDentification) tone for approximately three seconds. CED is generally sent prior to the re-INVITE for T.38.
(Remember again that CED and CNG are optional control messages).

T.38 version numbers are 0, 1, 2, and 3. IFP over TCP support is added in version 1. The abstract syntax notation.1 (ASN.1) notation is modified in version 2 with TCP support. The modified ASN.1 notation in version 2 and previous notations in version 0 or 1 cannot interoperate with each other. Version 3 supports V.34 fax. In the field, most initial deployments support version 0, and it recommends that version numbers are a mandatory field in T.38 to indicate which ASN.1 syntax is used. If no version number is provided, the default version 0 is assumed.



Conclusion

T.38 is a viable option to meet faxing needs over a VoIP network. In simply viewing a packet capture of a T.38 call, one can easily understand the intricacies involved with this method as many things must occur to be successful. Using this article as a guide should serve to that end.