"WARNING T.30 Page did not end cleanly"?


#1

I am setting up Asterisk 1.8 using spandsp and I keep seeing this message when receiving faxes even if T.38 was negotiated. One of the problem I am facing is that almost all of my incoming faxes are missing pages. I am having better results when sending.

I am using ECM at 9600 bauds, and:

timert1=600
timerb=38400
directmedia=no
t38pt_udptl=yes,redundancy,maxdatagram=400

  • What does this error generally mean?
  • Can we fix it?

Thank you!


#2

Fax nowadays comes in various colors and flavors and one need to be aware of that. In case everything is analogue (or ISDN), the internal fax engine based on spandsp is fine and everything works out great. You can turn on and off ECM according to your mood.

In case you get your transmissions via SIP things change a bit. Theoretically, T.38 helps, but I have never seen a Telco or ISP (in Europe) actually supporting it, despite they advertise it. When you increase the CLI verbosity you get warnings about the other side refusing to negotiate the T.38 protocol. You can still do facsimiles without T.38.

Let me first describe some technical things, before I describe the parameters that most of the time work for me and I deem to be important. Line switching and packet switching have entirely different ways to deal with transmission problems. Line switching implies very fast reactions (essentially speed of light) with possibly distorted signals. Packet switching implies repeated sending of packages in case the other side gets junk, but SIP/RTP is mostly used and nothing gets checked before Asterisk sees the data. T.38 has ways to repeat elements, but that’s pointless when you get everything wrapped up in parcels. Furthermore, dropped packets might contain vital information which can easily leads to a sudden death of the transmission attempt.

Assuming that the internet connection is good enough, one should turn off all types of error connection, especially ECM and try to run everything at a rate of 14400. Slower speeds mean a larger transmission time and time is your enemy here. By the same token, I prefer normal resolution whenever possible. The jitter buffer should be of a fixed size, typically maybe holding sound for about 100ms. If a transmission starts and a dynamic buffer gets adjusted a short delay could make the other side say bye-bye. The codec should be lossless, either G.711 of G.722. G.722 is better, but that can typically not be negotiated. E.g. GSM leads to hair loss and painful feet, so don’t do it. Lossy codecs change the frequency patterns in such a way that the resulting signal can no longer be decoded.

The basic idea is to keep everything floating without any interruptions. Then you depend only on the quality of the internet connection and what the other sides wants to get enforced. This largely excludes spandsp based solutions as they are typically too strict. It seems that some ATA devices do not strictly enforce the protocol and focus on printing whatever arrives. This might lead to one or the other visual defect, but that’s better than nothing in this case.


#3

If we’re dealing with a fax machine, which is connected to some sort of analog interface speaking either u-law or a-law, why would changing the codec to G.722 for digital transmission improve things?


#4

Because the other side may also be a SIP line and the G.722 signal is of better quality and more dynamic headroom.

I have used G.711 all the time myself before I got my hands on a so-called German Telecom “Digibox” (basically a bintex elmeg Smart box). The internal codec order starts with G.722 and the technician said that they should not change this. I guess it could make a difference with slightly overmodulated G.711 transmissions, where the granularity of the digitization gets coarser which could more easily lead to transmission errors.


#5

I’ll link to Steve Underwood’s excellent page on the topic of Fax, the Internet, and T.38:

https://www.soft-switch.org/foip.html

He doesn’t reference G.722. I’m not sure that any additional headroom in a digital codec matters where an actual analog fax machine is involved. And while faxing inband involving G.722 probably works just fine, I’d be wary that the codec’s coding involves a filter that’s splitting the signaling into two bands. You’d most likely end up fine, because everything on the analog side is going to be in the same band.

I don’t see any good guidance from other sources on the topic.


#6

Are you sure that Asterisk G.722 is not G.722.1 or G.722.2, which are totally unsuitable for fax. Even if it really is G.722, the way that works may well be worse than G.711, for band limited signals optimised for normal telephone circuits


#7

Reasonably? codec_g722.c:

/*! \file
 *
 * \brief codec_g722.c - translate between signed linear and ITU G.722-64kbps
 *
 * \author Matthew Fredrickson <creslin@digium.com>
 * \author Russell Bryant <russell@digium.com>
 *
 * \arg http://soft-switch.org/downloads/non-gpl-bits.tgz
 * \arg http://lists.digium.com/pipermail/asterisk-dev/2006-September/022866.html
 *
 * \ingroup codecs
 */

and from non-gpl-bits.tgz:

/*
 * SpanDSP - a series of DSP components for telephony
 *
 * g722_encode.c - The ITU G.722 codec, encode part.
 *
 * Written by Steve Underwood <steveu@coppice.org>
 *
 * Copyright (C) 2005 Steve Underwood
 *
 * All rights reserved.
 *
 *  Despite my general liking of the GPL, I place my own contributions
 *  to this code in the public domain for the benefit of all mankind -
 *  even the slimy ones who might try to proprietize my work and use it
 *  to my detriment.
 *
 * Based on a single channel 64kbps only G.722 codec which is:
 *
 *****    Copyright (c) CMU    1993      *****
 * Computer Science, Speech Group
 * Chengxiang Lu and Alex Hauptmann
 *
 * $Id: g722_encode.c,v 1.14 2006/07/07 16:37:49 steveu Exp $
 */

G.722.1 and G.722.2 came from PictureTel.


#8

If it is 64kbps, even if ADPCM, rather than CELP, it is going to be worse that G.711 for 3.1kHz audio data modulation modes, because it will trade increased distortion of low frequencies for unused high frequency capabilities.