VoIP has to overcome not just the transmissions that don’t sound like a human voice in touch tones (as discussed in the preceding section), but also fax transmissions. Most VoIP topics, and companies deploying VoIP, wholly ignore the need for faxing, despite the fact that it’s a vital transmission medium that people still use every day. By simply scanning documents and e-mailing them, many people transmit documents just as well as they could by faxing, but faxing still has a huge market and demand that any company intent on using a VoIP infrastructure for faxing needs to address.
Faxing over an IP network, or FoIP, has more potential issues that can fail a transmission than DTMF. The analog fax machines that typically receive faxes must synch up with the SIP transmission. FoIP hardware can find synching the simplest, uncompressed call a challenge because the maximum processing speed (or baud rate) of the receiving fax can range from 600 baud to 64 Kbps, where FoIP calls generally begin at 64 Kbps.
Sending uncompressed FoIP with G.711
Unless you’re set up to use specialized fax protocols, your only chance of sending a successful fax with FoIP is by transmitting it with the G.711 codec. But even using that codec can be a challenge because the codec is specifically designed for the transmission of voice, not faxes. The sampling algorithms can’t successfully compress and then reconstitute the squeals and squawks of a fax transmission based solely on the audio representation of those noises.
Even when you use G.711 to transmit your faxes, the calls can still fail because of synch issues with the receiving fax machine. If the receiving fax machine is capable of performing at very high speeds, known as Super G3 level (basically anything over 14.4 Mbps), the transmission will very likely fail. The conversion of the fax to and from G.711, along with the need to synch up to the receiving machine, requires too much time and coordination for a high-speed fax. The whole process rarely works well with these higher-end fax machines, so the transmission is likely to be corrupted and fail.
Latency, jitter, and packet loss can kill a fax call. You must have a high-quality network and connection if you plan on sending fax transmissions over an uncompressed G.711 transmission.
Using T.37
The community of programmers forging ahead into the world of VoIP recognized the challenge of transmitting faxes over an IP network. They realized that the idea of sampling the audio transmission associated with a fax wasn’t going to work, and they needed a new type of transmission mechanism. They decided to collect the fax data, reconstitute it as a completed image, and then save the image in a standard Tagged Image File Format (TIFF). They created a new technology for sending faxes over an IP network called T.37.
T.37 works in a simple manner, as shown in Figure 6-1.
Most fax machines can’t directly receive or send T.37. The analog fax machine you bought a few years back is designed to plug in to the single-line jack on your wall and operate over a normal phone line. Most likely, it isn’t built to receive T.37 and convert the signal into something it can print on a page.
Figure 6-1:
T.37 fax.
The main drawback of T.37 from the perspective of a VoIP carrier is that it demands both processor power and buffer memory. When your local carrier’s VoIP network receives the fax, the call is converted to T.37, meaning that every page of the fax is fully received and converted to a .TIFF.
The proxy performing this work has to devote a lot of effort to converting the fax data. While the fax is converted to .TIFF files, the finished documents are stored on the switch, which takes up valuable memory until the final page is completed and the fax can be transmitted. The quantity of faxes transmitted around the world prevents T.37 from being an acceptable business product. Don’t worry, though — the VoIP carriers created a viable alternative with T.38, which you can read about in the following section.
Getting the fax with T.38
T.38 is a more network-friendly version of T.37 (which I talk about in the preceding section). It resolves the buffer and processor issue by treating the transmission more like a voice call, rather than a fax. T.38 doesn’t store the pages while it spools the entire fax document into a TIFF. It simply converts the fax and sends small packets of it, which represent portions of a fax page.
The main benefit of T.38 is compression. It provides the same eight-to-one compression in fax transmissions that G.729 uses for voice calls. You need a lot of bandwidth when you use VoIP because any bottleneck in your Internet connection is instantly realized as poor call or transmission quality in realtime applications as a result of latency, jitter, and packet loss. If your business sends a large volume of faxes, talk to your VoIP provider about T.38.
T.38 has another complication — it uses a unique format to send the T.38 packets. The transmission is sent with a modified version of UDP called the User Datagram Protocol Transport Layer (UDPTL). It doesn’t use RTP like a normal VoIP call does or TCP like a normal data transmission does.
Figure 6-2 identifies one of the challenges with T.38. T.38 isn’t native to analog fax machines so a network server or gateway is needed to transcode the incoming signal to the fax machine from T.38 to analog.
A T.38 deployment takes time, planning, and a highly competent technician. Your VoIP carrier must design every switch within its network that might encounter the transmission so that it can handle and transmit UDPTL packets. Some carriers have only limited deployment of UDPTL, or it may not yet have fully integrated it. If the VoIP carrier hasn’t proven and tested all these switches with UDPTL, its existing network hardware can make the connection from end to end, but the transmission fails when it tries to send UDPTL packets.
Figure 6-2:T.38 fax.
TIWlTE-mg to T.38
T.38 isn’t an option provided on every VoIP call. The INVITE message sent on a call that concludes as T.38 is straightforward and appears to be nothing more than a normal voice INVITE. After the VoIP server recognizes the call as a fax, it must then re-INVITE the call to T.38. You can re-INVITE a call to T.38 in two ways:
Program your phone system’s Dial Plan for inbound calls. You must add the phone number or toll-free number on which you plan to receive inbound T.38 faxes to the Dial Plan of your phone system to re-INVITE the call to T.38 as soon as it realizes the number/extension dialed belongs to your fax machine. Your programmer or the individual who designed your Dial Plan shouldn’t find programming this very straightforward re-INVITE into your Dial Plan difficult.
Your carrier does all the work on outbound faxes. Your carrier may be able to monitor your outbound calls and identify in the first few milliseconds whether the call is connecting to a fax. In this case, you don’t have to program the re-INVITE into your Dial Plan.
Your carrier can more easily make this distinction in a situation where a remote employee uses the same phone line for both his or her normal phone calls and faxes. An employee or customer with one traditional analog phone line would ignore the incoming call or activate his or her fax machine when he or she needed to receive a fax and disable the fax when he or she wanted to make a call. When the carrier identifies a fax call, the employee can still switch back and forth between types of phone-line usage, and the carrier re-INVITEs only when the employee connects to the fax. If you were to build in an automatic re-INVITE to all outbound calls from your fax line, you’d simply blast a fax tone in the ear of the person every time you called. He or she would eventually figure it out and activate his or her fax machine, but allowing your VoIP carrier to sense the device at the destination is a more diplomatic solution.
If you plan on using T.38 for your fax transmissions, speak to your carrier to figure out whether it handles the re-INVITE to T.38.
Setting up T.38 specifics
T.38 is a more intensive protocol than a normal voice call, and it has additional parameters that the SIP nodes must negotiate. The initial INVITE of a call that’s eventually negotiated as T.38 begins as a VoIP call with only voice options listed.
The magic happens after either your Dial Plan identifies the incoming call as a fax or your carrier auto-senses the remote fax on an outbound call. After that happens, the SIP device aware that the destination is a fax, sends the re-INVITE to the originating VoIP server of the transmission and offers T.38, along with the finer details required to make it all work. The Media Description in the SDP looks like this:
You can find out what normal SDP negotiations look like in topic 3 (that topic also gives you the details about the SDP header that I don’t include in the preceding code).
The preceding code’s first line shows that the transmission is an image using port 43214 sent via udptl and using t3 8 — in other words, a fax. The SDP INVITE needs to present only the rate management, but most fax transmissions also include the other lines in the preceding code, as well. If the parameters do appear in an INVITE, they can appear in any order. These parameters represent
‘ Software version: If the INVITE doesn’t identify a version, it populates this position 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. The preceding example indicates that it requires 9 600.
‘ Fill bit 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 the bandwidth.
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 example indicates with the 0 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 Bi-Level Image experts Group (JBIG) can be used to compress the data used on the fax transmission. This example indicates with the 0 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 has to 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 has to 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. The max buffer in the preceding code allows for 316 bytes before they’re 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, I’ve seen max buffer values of 72.
Max datagram: This value identifies the maximum size of the payload inside an RTP packet. 316 is a common value for this parameter; it’s 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. This section’s example identifies UDPRedundancy, indicating that the SIP device originating the INVITE requests UDP Redundancy Error Correction on the transmission. If the INVITE message preferred FEC over UDPRedundancy, the FEC option would be listed as:
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. Network engineers have used FEC for transmitting data for some time; it’s not specific to T.38.
The values presented for transcoding MMR and JBIG are referred to as Boolean values, named after the 19th-century British mathematician George Boole. Calling them Boolean values is just a fancy way of saying that the values are either 1 or 0, with 1 representing a TRUE response, and 0 representing a FALSE response.
