Fax Over IP

For the past ten-plus years enterprises have been making the switch from TDM to IP telephony.   For the most part, this has involved replacing older digital telephones with IP equivalents while converting applications such as voice mail and voice response units to a SIP interface.  The benefits of these conversions are significant and you would be hard pressed to find a new PBX going in today without an IP infrastructure.

However, for most of the early 2000’s, trunks to the public switched telephone network (PSTN) remained unchanged with analog and ISDN/PRI trunks as the norm.   Many carriers weren’t ready to deliver IP trunks and those that were didn’t deliver a complete set of features.  All of this is starting to change, though, and enterprises are now replacing their TDM trunks with SIP trunks.

As it was in the case of IP endpoints and applications, there are many benefits in switching to IP trunks.  Unfortunately, there is one issue that tends to be forgotten.  What do you do with all your fax lines?  How do you convert them to IP?  Is it possible to use SIP trunks for both voice and fax?  Before these questions can be answered, a short primer on fax is necessary.

Fax (short for facsimile) has been around in one form or another since the 1920’s, but it wasn’t until the mid 1960’s that the Xerox Corporation introduced the first commercial fax machine.  Faxes began as analog transmissions (Group 1 and Group 2) but that soon gave way to digital transmissions (Group 3 and Group 4) in the late 1960’s.  Fax machines scan documents in the same manner as a frame of analog television, but those scans are then compressed and sent as modem signals across telephone lines.

T.30 is used as the messaging protocol between fax machines.  T.30 also supports a handshake mechanism whereby two fax machines exchange information about their capabilities to ensure that the sending fax machine sends data that the receiving fax machine understands and can ultimately display.

Faxes are sent and received as modem signals and different ITU standards exist for the different transmission speeds.  For instance, V.27 defines faxes sent at 2400 or 4800 bits per second and V.34bis is used for faxes sent at 33600 bits per second.  Modem signals and bit speeds are perfectly acceptable when you consider that an analog telephone line is a dedicated, circuit-switched connection with a consistent data flow.

This is not the case with packet-switched IP which may suffer from jitter, delay, lost packets, and packets arriving out-of-order.  So, how do you deal with this problem as your enterprise replaces analog and ISDN/PRI trunks with SIP trunks?



There are three schools of thought on this.  The first is to create a quality of service network with none of the issues that can wreak havoc on real-time communications — in other words, no packet loss, no jitter, no latency, and no out-of-order packets.   This allows you to run T.30 over a toll-quality, G.711 link and let your PBX convert the G.711 IP stream to the analog connection that your fax machine requires.   This is known as “fax pass-through” and has been successfully used by many enterprises.

However, if your network isn’t nearly as clean as it should be, something else is needed.  Enter T.38 – a Fax over IP (FoIP) protocol designed to packetize those modem signals in a way that overcomes the “flaws” in an IP network.  It is T.38’s job to ensure that the fax packets will arrive in order, on time, and with as little jitter as possible.  In most cases, a fax will begin as T.30 from the sending fax machine, be converted to T.38 by a fax gateway, transmitted across the IP network, and eventually be converted back to T.30 by a gateway (e.g. an Avaya TN2602 board within a G650 gateway) on the receiving end.

Newer T.38 fax machines and fax servers exist which eliminate the need to convert to and from T.30, but since many of the older machines are in wide use today, gateways are still necessary.

The final possibility is to retain some TDM trunks strictly for fax.  When considering the cost of gateways and line provisioning, this may be the best and cheapest solution.

Making the Switch

As your enterprise makes its journey from TDM to SIP trunks, it is imperative that you examine your fax usage before committing to a particular SIP architecture.  If fax is an important part of your business, you may want to look at T.38 from the standpoint of your communications infrastructure as well as your SIP trunks.   Be aware that not all providers support T.38, so don’t fail to add that to your decision making process.  In the end, though, it is possible to create a system that brings together the power of SIP with older, tried and true technologies such as fax.


  1. I think the most importent thing to know about fax T38 support in Avaya is that it limits max transmission speed to 9600kbs. That is right, it is very slow. Much better is just to disable t38 on codec configuration screen and use open g711 clear channel. This will encrease transmission speed to 28000-34000 kbs. Error handling will be done by done by faxes themselves. Aura messaging is supporting 14400kbs, but Avaya MGs G4XX can only process it at 9600kbs using T38. Unfortunatly Avaya doesn’t really advirtise this limitaion – you can only find it yourself the hard way taking traces.😦
    This is understandable – you need to put fax support on Marketing documets, but you don’t really want to tell the users – don’t use this option! I would say Avaya fax support is just ugly.
    Unfortunately only have pictures from the fax SMtrace examples, can provide it here.

    1. You are correct. Avaya MGs are horribly slow when it comes to fax. However, G.711 may not be useable if jitter, latency, and packet loss are high. Fax is not self-correcting in this case. You need T.38 for that.

      Honestly, I would like to see fax disappear. I would much rather email a jpeg.

  2. we are sending faxes from Canada to US using pivate WAN MPLS VPN link with T.38 disabled – works perfectly fine. Faxes are sent at 28000 – 33000 kbps. Earlier had a huge problem trying to connect Avaya to a Mitel system for fax delivery using SIP trunk with T.38 enabled on both systems. There is a compatibilty problem that makes one end reject T.38 settings offered by another system. It was clearly visible in SIP traces.

    No issue with jitter and packet drop. There is a receiving buffer that makes up for some jitter at the expense of some extra packet delay, but this delay is not crititcal for data transmission.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: