Icheb’s blog

Some time ago, I posted at the Asterisk-users mailinglist. I had a problem, with RxFax. It wasn’t working at all anymore. However it had worked before. In this posting, I’ll describe the problem and a possible fix. However I can’t call this a fix, as it’s a feature. Not a bug.
First of all, my original e-mail to the mailinglist:

Hi,

For some time now, I’ve been fighting with RxFax and Asterisk.
I had it working for some time, however, for some reason it just stopped working, I guess someone updated Asterisk or something, don’t know exactly.

At the moment I keep getting errors while entering the RxFax stage of a call.
But due to the fact RxFax does not contain any code to directly interact with an RTP stream, it uses SpanDSP, I guess the problem is somewhere in SpanDSP.

From my logs, I get:
– Goto (macro-faxreceive,s,7)
– Executing RxFAX(“SIP/-ff83″, “/var/spool/asterisk/fax/fax/asterisk-8558-1149842081.2.tif”) in new stack
Jun 9 10:34:56 WARNING[8558]: chan_sip.c:1829 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4)
Jun 9 10:34:56 WARNING[8558]: chan_sip.c:1829 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4)
Jun 9 10:34:56 WARNING[8558]: chan_sip.c:1829 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4)

The basic call setup works perfectly, but whenever I try to enter a fax stage, I get this error.
According to the SIP call initialisation, there are no problems with formats, and the agreed upon format is 4 (aka ulaw).
At the moment I get these errors, there aren’t any SIP transmissions, so were in mid-session…

I guess the problem is somewhere in SpanDSP or a transcoding error between slin and ulaw in chan_sip.

I’ve confirmed this problem on 2 servers so far.
The first server is our fax receiver (production), where this problem started. But it also appeared when I tried to directly connect a fax transmission from a PSTN line with an Sipura 3000 as FXO (forwarding the audio stream over our NAT to our local Asterisk server, with the ulaw codec).
Both servers are Debian Sarge servers.

Confirmed this problem in:
Asterisk 1.0.7 (default .deb packages, being with SpanDSP 0.0.2pre10-3)
Asterisk 1.0.11 (after reading http://lists.digium.com/pipermail/asterisk-users/2006-May/151843.html, SpanDSP 0.0.2pre26)
Asterisk 1.2.8 (from source, with SpanDSP 0.0.2pre26)
Asterisk 1.2.7.1 (from source, with SpanDSP 0.0.2pre25)

Does anyone know of a way to get it working again?

It has worked before, so I know it’s perfectly possible with Debian Sarge.
Furthermore I’ve set this up on Red Hat Enterprise servers without this problem (with Asterisk 1.0.9). So I don’t believe this is an error caused by myself.

Well, some time later, I posted the message again, on the -dev mailinglist. At that time the maintainer of the SpanDSP lib (Steve Underwood) responded to me, it was a user problem. No futher details.

So time after that, Lukas Gaam contacted me, he had the exact same problem. And due to him, a solution has been found now.

Basically, the problem can be best described like:

When SpanDSP is called for RxFax() after audio has been transmitted to the calling party, SpanDSP fails. If RxFax is activated before other audio is transmitted by Asterisk over the channel, it works fine.
So it seems, SpanDSP is having problems when it’s not the first thing that produces audio.
If a extension is build up like:
exten => s,1,Answer()
exten => s,2,Ringing()
exten => s,3,Wait(x)
exten => s,4,Macro(faxreceive…)
It fails.

If however Ringing() is removed, Asterisk will not produce any audio before starting the RxFax, and it works perfectly.

After Lukas discovered this, we tested it with different audio source, like Playback(), which seemed to cause the same issue.

So the fix would be to have perfect silence before calling the RxFax command / macro.

My current home dialplan has been changed to look like:

exten => 1,1,Answer
exten => 1,n,NVFaxDetect(5)
exten => 1,n,Ringing
exten => 1,n,Wait,5

Which makes sure faxes are redirected to the fax extension, however it’s a pain in the ass, the fax detect takes so long, as some callers start talking before getting the Ringing event.

Perhaps someone can use this to fix problems .

Lukas, thanks for providing the final solution .