Skip to main content
JD
Jaron DavisUC Architect • jaron.one
SIP & VoIPPublished • 4 min read

Overcoming the challenges of T.38 for Faxing over SIP

Jaron Davis
Jaron Davis
Unified Communications Architect • Author Profile
Preserved from colla.blog archive
Overcoming the challenges of T.38 for Faxing over SIP

Introduction

Fax over IP (FoIP) is a topic that most collaboration engineers hate. And when I say hate, I don’t mean they just dislike it, they HATE it with the burning rage of hell. One Cisco Live video I watched described fax as “the cockroach that just won’t die.”

Because I work in the healthcare environment, I have to deal with fax far too often. There is always that odd issue where faxes are coming through, but for some reason faxing from a specific company never want to come through properly.

Like most engineers, for a long time I looked at the problem and simply said “look, the calls are coming through for everyone else, I don’t know what else you want me to do? The problem must be on their end.”

So recently I decided to go ahead and dive head first into fax over IP and see if I can determine what the problem might be. I’m going to share some of what I’ve learned. Keep in mind, this is not an end all guide to FoIP, but is more of an introductory guide for Collaboration Engineers. You have to understand a lot of the concepts of voice if you want to understand the rest of this guide, but you don’t necessarily have to be a CCIE to get it, either. (I’m not a CCIE, not even close…)

Faxing Basics

First, let’s understand a little bit about fax. I don’t really feel we need to dive too deep into this, but it’s worth having the knowledge. Fax, on the analog side, uses T.4/T.6 to encode the actual image, and then T.30 for signaling. I’m not going to dig into those protocols, though, because for our purposes, those are relatively irrelevant.

Group 3 (G3) versus Super Group 3 (SG3)

You will sometimes hear G3 and SG3 mentioned. If you’re really interested in this, I highly recommend watching the Cisco Live presentation mentioned in the sources at the bottom, but here are the basics.

While T.4 and T.6 are the protocol used to transmit the encoded image, G3 and G4 are the actual encoding algorithms. G3 = T.4 while G4 = T.6.

Most fax machines are standardized on T.4, which means G3 is used. Here’s the kicker, though: G3 isn’t especially fast. Because of this, Super G3 (SG3) was developed to be carried over the T.4 protocol but to be encoded quicker by the fax machine. The problem? Many fax machines still don’t support SG3, so Cisco’s best recommendation is to stick to standard G3.

Introducing Fax to IP

When we introduce an IP network, however, we have two ways to handle this.

We can handle it like a voice call, and encapsulate that audio in RTP packets using the G.711 codec to sample the audio being played, and then transmit that across the network, including the T.30 and T.4/T.6 protocols within the audio. This method is known as Passthrough.

The other option is to demodulate the analog audio into an image, and then transmit it across the network in image packet form rather than audio form using the T.38 protocol. This does require DSPs at the sending and receiving end of the connection, though, since it will need to modulate it back into an audio signal and add T.30 and T.4/T.6 back to the fax. This method is known as Relay.

Note: In T.38 Fax Relay, UDPTL (UDP Transport Layer, IETF RFC 7345) is utilized to transport the T.38 packets rather than RTP.

Here is a quick table describing the pros and cons of each method:

Characteristic G.711 Fax Passthrough T.38 Fax Relay
Transport Protocol RTP (Audio Stream) UDPTL (Image Data Stream)
Bandwidth Usage ~85 kbps ~30 kbps
Packet Loss Tolerance Very low (< 0.1% — lost audio corrupts fax tones) Higher (supports packet-level redundancy / FEC)
Latency Tolerance Strict (< 150 ms) Tolerates up to 1,000 ms (1 second) delay
ITSP Compatibility Universally supported (treated as standard G.711 call) Requires end-to-end T.38 support from ITSP

As you can see, the key difference above is that G.711 voice calls can accept minor packet loss and still be an intelligible phone call, but cannot handle much delay (and fax over G.711 is extremely sensitive to jitter/loss). T.38, on the other hand, can handle up to 1000ms (1 second) delay for information, and uses UDPTL redundancy (ls-redundancy / hs-redundancy) to protect against packet loss so you don’t lose parts of the faxed image.

How Cisco Handles Fax over IP

Cisco gives us a few options for handling Fax over IP. We can do everything standards-based (protocol-based), or we can do things the Cisco way using Named Signaling Events (NSE).

NSE steps in for SIP as a Cisco-specific method to handle fax passthrough and relay. I’m going to be very honest here: you probably won’t use this primarily because your ITSP won’t support it. So for that reason, I’m not even going to deep dive into this. Stick with standards-based (protocol-based) T.38 or G.711 over SIP.

Passthrough versus Pass-through?

Cisco makes things a little bit tricky with the verbiage, so it’s important to note this difference:

  • Passthrough is the general method of using G.711 and RTP to transmit fax, whereas Relay is the method of using T.38.
  • Pass-through (with a hyphen in IOS CLI) is the standards-based (protocol-based) version of Passthrough, as opposed to the NSE version of Passthrough that is Cisco proprietary.

Negotiating with your ITSP

Your ITSP (Internet Telephony Service Provider) is probably going to be your biggest hurdle. Many ITSPs simply don’t support T.38. The problem with this being that for the switchover to happen from G.711 to T.38 (via a SIP re-INVITE), SIP has to negotiate all the way back to the point where the sending fax turns into a SIP signal, which isn’t going to be in your network.

For this reason, always ask your ITSP when deciding which service provider to use if they support T.38. If they don’t, decide if it’s a deal breaker or not, and maybe look at other potential ITSPs.

Configuring T.38 in your CUBE

If you want T.38 to work, you’re going to have to tell your CUBE router that you want it to do that. You have two options: you can do this universally in your CUBE under your voice service voip configurations, or you can tell each individual dial-peer which fax mechanism it should use.

The commands used are as follows:

fax protocol t38 version [0|3] ls-redundancy [0-5] hs-redundancy [0-2] fallback [none|pass-through g711ulaw]

Here we are telling our CUBE that we want to use fax protocol T.38, then we are telling it what level of low-speed and high-speed UDPTL packet redundancy we want, and finally we are telling our CUBE what to do if T.38 negotiation fails—whether it should fail the fax or fall back to pass-through g711ulaw.

Important Note: What I put in my example below includes UDPTL redundancy and G.711 fallback, which I have found works best in real-world ITSP environments. Cisco documentation often cites this baseline command:

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

fax-relay ans-disable

This is so that if the CUBE detects an ANSam signal in the T.30 signal, it will suppress it, disallowing SG3 to initiate and forcing a sending fax to resort to G3. Don’t use this command if you want to utilize SG3. Using this command is Cisco best practice.

fax-relay sg3-to-g3

This command will take out the Call Menu (CM) tone from a sending fax if your CUBE detects it, again to disallow SG3 and resort to G3, which is Cisco best practice.

This next command can ONLY be put on your dial peer:

fax-relay ecm-disable

This command disables the Error Correction Mode (ECM) signal in the T.30 fax tone, if recognized, to disable ECM. ECM is used to correct issues caused by noise on POTS telephone lines. Again, Cisco often recommends disabling it when troubleshooting, though I personally prefer leaving ECM enabled unless a specific carrier route requires disabling it.

HomeLab#config t
Enter configuration commands, one per line.  End with CNTL/Z.
HomeLab(config)#voice service voip
HomeLab(conf-voi-serv)#fax protocol t38 version 3 ls-redundancy 1 hs-redundancy 1 fallback pass-through g711ulaw
HomeLab(conf-voi-serv)#fax-relay ans-disable
HomeLab(conf-voi-serv)#fax-relay sg3-to-g3
HomeLab(conf-voi-serv)#exit
HomeLab(config)#

Important Note: If you configure the fax protocol on your individual dial peers, you must ensure you enable it on both the inbound and outbound dial peers, and you must match configurations for both sides of the call.

Sources

Cisco Live – Understanding, Integrating, and Troubleshooting Fax Communications in Today’s Enterprise Networks – BRKUCC-2021 – https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2017/pdf/BRKUCC-2021.pdf

ITU-T – T-REC-T.38 – https://www.itu.int/rec/T-REC-T.38/en

WhatIs.com – Fax Group – https://whatis.techtarget.com/definition/Fax-Group

t38fax.com – ECM – T.38’s Dirth Little Secret (And Why It Matters) – http://blog.t38fax.com/blog/ecm-t38-dirty-little-secret

Cisco.com – Cisco IOS Voice Command Reference – Chapter F – https://www.cisco.com/c/en/us/td/docs/ios/voice/command/reference/vr_book/vr_f1.html

Jaron Davis
Written & Curated By

Jaron Davis

Unified Communications Architect specializing in enterprise Zoom, Microsoft Teams, Cisco UC modernization, SIP/VoIP infrastructure, and systems architecture.

Articles & Insights Navigation

Explore executive insights, architecture perspectives, and deep-dive engineering guides across AI strategy, Zoom Phone, Cisco UC, SIP trunking, and E911 compliance.

All Articles & Insights→

Related Technical Articles

View All →
Zoom
•4 min read

UCaaS Connectivity: Zoom Phone Architectures

An architectural deep dive into Zoom Phone PSTN and hybrid connectivity models—Native Zoom Phone, BYOC-C (Cloud Peering), BYOC-P (Premises SBC), and BYOP-P (Premises PBX)—evaluated across E911, local survivability (ZPLS), and advanced call routing.

#Zoom Phone#SIP#Architecture & Strategy
Read
SIP & VoIP
•4 min read

The Forgotten Attack Surface: Why UC Is a Major Cybersecurity Concern

Why enterprise Unified Communications infrastructure is frequently overlooked by security teams—and a practical hardening blueprint covering SIPS/TLS, SRTP, SBC access control, toll-fraud prevention, and SIEM visibility.

#Security#SIP#Cisco CUBE
Read