2012-07-10

The proliferation and ubiquity of the internet have brought about an upending of several industries.  For example, many newspapers and magazines have been completely replaced by on-line versions.  The postal service has transitioned away from being strictly a letter carrying service and expanded package and advertisement delivery services.  Music distribution has moved away from physical media towards on-line download services.  Likewise, movies and television distribution are transitioning towards internet media.

Telephone services are no different.  From its popular introduction beginning with "voice-chat" in network games and text+voice chat clients such as Yahoo! Messenger, consumers very quickly began to see the internet as an appropriate medium for voice communications.  And despite legal fighting by US telecommunication companies Voice-over-IP communications rapidly became a viable alternative to traditional PSTN telephone services.  Unfortunately, fax and data do not operate well on VoIP channels.  This was discussed in the previous Mainpine blog entry.

In an attempt to mitigate problems with fax on VoIP channels a new Fax-over-IP (FoIP) method, called T.38, was developed.  The internet is a good medium for communicating raw data, and so on a T.38 session the fax image would be communicated as raw data instead of encoding that data into an audio waveform as with traditional PSTN fax.  This, alone, is not a problem.  However, the problems associated with T.38 fax are associated with the implementation of that specification into real-world applications.  Most of these problems have to do with the continued association under T.38 implementations of fax communications with voice communications.

A typical FoIP communication path may go as follows:  the phone line for the sender's fax machine is connected to some T.38-capable equipment.  That T.38-capable equipment communicates through a series of FoIP/VoIP switches until reaching a VoIP provider where a T.38 gateway on their end converts the T.38 signalling into traditional audio fax to reach the receiver's fax machine.

The first problem with that implementation is that in most circumstances the T.38-capable equipment to which the sender's fax machine is connected will not begin a call with T.38, but rather will begin a call in voice-mode (e.g. G.711) and will switch to T.38 at some point in the call when it detects that the call is actually a fax.  Preferably that happens very early-on in the call.  That switch from voice-mode to T.38 is difficult to make go smoothly simply because of the variability in the fax-detection timings.  It is generally critical that the switch to T.38 occur before the receiver signals DIS - which is a signal that the receiver transmits immediately after answering the call.

The next problem has to do with the internet medium, itself.  VoIP traditionally is performed with a protocol called SIP or alternatively with a protocol called H.323.  Both of these protocols traditionally operate on an internet protocol called UDP.  UDP is a "streaming" protocol, and as discussed in the previous blog entry this is the culprit behind VoIP jitter which is a big problem for fax.  T.38 attempts to mitigate jitter by allowing the sender to transmit data packets in duplicate, triplicate, or quadruplicate - the idea is to reduce the likelihood that UDP packet loss would affect all of the repetitions of the data packet.  However, on congested network connections this behaviour has only a limited degree of success.  Jitter still plays a problem, depending on how busy the network is.

In response to UDP packet loss, some SIP implementations can operate on TCP instead of UDP.  This prevents network congestion from playing a factor in packet loss.  However, using T.38 on TCP then introduces the real possibility on networks experiencing congestion that timing sensitivities within the fax protocol, itself, will be affected and cause problems with the endpoint fax machines which are dependent upon those timings in order to avoid errors.

The next problems can be highlighted by how the T.38 gateway devices must cope with line noise on the PSTN-side of the call.  If there is enough line noise on the PSTN-side of the call, then if the T.38 gateway is to permit ECM (error correction) to occur then the T.38 gateway device must perform ECM procedures with the fax machine until the data block is received completely while somehow keeping the fax machine on the other end of the call to stay around.  There are various methods whereby this can be accomplished (for example, simply relaying the corrupt data to the other side is one possibility).  But this problem with line noise on the PSTN-side of the call highlights the disjunction that exists between fax endpoints on a T.38 call.  That disjunction requires a lot of cooperation on the T.38 path in order to mirror-well the activity on one end of the call to the other.  As different T.38 implementations approach this problem differently there are many interoperability issues that have a bearing on reliability.

So there are problems with transparency to the endpoints and compatibility between the various T.38 gateways.

The last issue worth mentioning at this time is that of how fragile the T.38 call environment is.  Any change in any of the devices or in the call path can disrupt communications.  This is no different than in traditional PSTN faxing except that the number of components in a T.38 call is at least double that of the PSTN counterpart.  When experiencing fax troubles on a traditional PSTN environment the troubleshooting focuses on either the sender, the receiver, or the telephone lines.  However, when experiencing troubles on a T.38 fax environment the troubleshooting must also consider the two T.38 gateways and the internet connection.

In other words, elevating reliability in the T.38 environment is substantially more-difficult and is additional to elevating reliability in the PSTN environment.

In order to achieve reliable fax operations over the internet the fax communications must be decoupled from voice communications.  T.38 FoIP is not the answer as it can never be as-reliable as traditional PSTN faxing.  The way forward for faxing through the internet must be to improve reliability beyond what is already available with the PSTN.  There is a better way.

More to come...