This message is pointed directly to Steve Underwood. I tought it would not be nice to directly email him with a question that interests a good part of the Asterisk community, so here it is. :) Steve, remember a few days ago when we discussed about issues on Asterisk 1.6.1.13 and T.38 fax reception? Well I opened an issue on Mantis (https://issues.asterisk.org/view.php?id=16756) and turns out it might be spandsp-related. What happens is, when I use app_fax to receive a fax using T.38, I get very low transmission rates, and about 30% of the faxes are just not transmitted at all. 2400bps is not uncommon. If instead of T.38 I use an analog landline connected to that very same Asterisk box, app_fax works wonderfully well transmitting at full 9600bps. Just to rule out Asterisk's T.38 handling, I noticed that Fax For Asterisk works perfectly with T.38, also on that same box. I'll be happy to provide you any info that could help solve this issue. Atenciosamente, Vin?cius Fontes Gerente de Seguran?a da Informa??o Canall Tecnologia em Comunica??es Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunica??es Passo Fundo - RS - Brazil +55 54 2104-7000
On 02/05/2010 07:40 PM, Vin?cius Fontes wrote:> This message is pointed directly to Steve Underwood. I tought it would not be nice to directly email him with a question that interests a good part of the Asterisk community, so here it is. :) > > Steve, remember a few days ago when we discussed about issues on Asterisk 1.6.1.13 and T.38 fax reception? Well I opened an issue on Mantis (https://issues.asterisk.org/view.php?id=16756) and turns out it might be spandsp-related. > > What happens is, when I use app_fax to receive a fax using T.38, I get very low transmission rates, and about 30% of the faxes are just not transmitted at all. 2400bps is not uncommon. If instead of T.38 I use an analog landline connected to that very same Asterisk box, app_fax works wonderfully well transmitting at full 9600bps. Just to rule out Asterisk's T.38 handling, I noticed that Fax For Asterisk works perfectly with T.38, also on that same box. >Is the FAX machine you are using only capable of 9600bps, because full speed should be 14400bps? Can you get a packet trace of a problem call, using wireshark, and mail it to me?> I'll be happy to provide you any info that could help solve this issue. > >Steve
There you go: http://www.canall.com.br/wireshark_trace_t38_ffa.gz Atenciosamente, Vin?cius Fontes Gerente de Seguran?a da Informa??o Canall Tecnologia em Comunica??es Passo Fundo - RS - Brasil +55 54 2104-7000 Information Security Manager Canall Tecnologia em Comunica??es Passo Fundo - RS - Brazil +55 54 2104-7000 ----- "Steve Underwood" <steveu at coppice.org> escreveu:> Hi Vin?cius, > > Asterisk + Spandsp is working correctly in that call. > > The other system sends bad training data at V.29/9600bps. Spandsp > rejects it. > The other system sends bad training data at V.27ter/4800bps. Spandsp > rejects it. > The other system sends clean training data at V.27ter/2400bps. Spandsp > > accepts it. > The other system sends a page at V.27ter/2400bps. Spandsp accepts it. > > The bad training data is *really* bad. It should be 1.5s of all zero > bits. It starts off with zeros, but after a few hundred milliseconds > it > changes to complete rubbish. I can't believe the Commetrex engine in > Digium's FAX for Asterisk would accept this. Perhaps something subtle > > means they are sent the correct data. Can you send a wireshark log of > a > call with FAX for Asterisk? > > Steve > > > On 02/06/2010 12:43 AM, Vin?cius Fontes wrote: > > No problem, hosted it on my company's website: > http://www.canall.com.br/wireshark_trace_t38.gz. > > > > > > Atenciosamente, > > > > Vin?cius Fontes > > Gerente de Seguran?a da Informa??o > > Canall Tecnologia em Comunica??es > > Passo Fundo - RS - Brasil > > +55 54 2104-7000 > > > > Information Security Manager > > Canall Tecnologia em Comunica??es > > Passo Fundo - RS - Brazil > > +55 54 2104-7000 > > > > ----- "Steve Underwood"<steveu at coppice.org> escreveu: > > > > > >> On 02/06/2010 12:01 AM, Vin?cius Fontes wrote: > >> > >>> Here's the packet trace I promised: > >>> > >> http://www.zshare.net/download/72186098494e6f8c/. > >> > >>> As this is a production system, there were a few calls along with > >>> > >> the one that interests us. The one you're looking for is that from > >> 5433142499 at 10.150.65.16 to 5421047008 at 10.153.66.146. The provider > has > >> the address 10.150.65.16 and my box has the address 10.153.66.146. > >> > >>> > >>> > >> Can you put the file somewhere that actually works. I've downloaded > it > >> 5 > >> times now, and it has been cutoff at different points each time. > These > >> > >> free file sharing services all seem to do this. Maybe they all run > the > >> > >> same broken software. > >> > >> Steve > >> > >
> > ----- "Kevin P. Fleming" <kpfleming at digium.com> escreveu: > > > Vin?cius Fontes wrote: > > > Will do. You guys will have my feedback on monday. If everything > > goes okay with that change, I'll post a patch on Mantis. > > > > No need for the patch; it's already on my radar, and if you confirm > > that > > it actually solves an interop problem, I'll commit the update to > the > > various branches it belongs in. I'd still like to hear from Steve > > Underwood if I misinterpreted the MMR/JBIG transcoding function > calls > > in > > spandsp that led me to enabling these features in the first > place... > >----- "Vin?cius Fontes" <vinicius at canall.com.br> escreveu:> Unfortunely it didn't solve the problem. Here's the session packet > capture after editing app_fax.c. > http://www.canall.com.br/wireshark_t38_jbig.gz >I've tried everything. EVERYTHING. Almost every combination of maxdatagram sizes, error correction modes, hacking app_fax.c to limit the baudrate to 9600... nothing. Every single time I get rates like 2400, 4800 or if I'm very lucky, 7200. In ALL cases, *every single time*, FFA negotiated the connection at 9600bps and the fax was received cleanly. It's clear to me that the provider should not be blamed on this case. I tried using a Linksys SPA8000 and faxes are also received perfectly. Something, either in Asterisk, SpanDSP or app_fax is just not right. For now I'll have to stick with FFA for my company and my customers. They will not be happy to know that in order to transmit or receive more than one fax simultaneously they will need a US$40 license, but it's still better than quadrupling the phone bills because for some unknown reason the baudrate is 4 times slower than it should be. I'm still willing to solve this. I really want to get app_fax working as intended. I'm sure this is on the best interests of the community as well. Unfortunely I don't have the knowledge or skills on faxing protocols, DSP and C development or else I would have solved this myself. But I'm doing my part on this by providing all necessary info and running every single test I'm asked to. IMHO it would be a shame if we need to rely on a commercial piece of software because the open source equivalent is 4 times slower on some cases. For me it defies the very reason of Asterisk's existence: an open source alternative on a market flooded with proprietary solutions.
----- "Steve Underwood" <steveu at coppice.org> escreveu:> Hi Vin?cius, > > Don't post big things, like wireshark traces, to a mailing list. They > > are likely to ban you. > > The first two calls in your wireshark log decode to the attached > images. > There were no lost packets. The wireshark logs contains exactly what > the > far end sent, and it was not good. The first fax page has 12 bad pixel > > rows. This page was accepted, as minor defects like this are normally > > accepted. The second fax starts out OK, then then just falls apart. I > > think the receive modem in that gateway probably lost sync. The data > looks like complete rubbish beyond the part that decodes to something > > sensible. > > The system you are trying to interwork with seems to have serious > issues. It can be difficult to get providers to sort out T.38 issues, > as > many of them have very little understanding of the systems they have. > > Even big carriers can be very unresponsive, because they just don't > know > what to do. > > Regards, > SteveSo there's no packet loss, but the provider is sending me rubbish, if I understand correctly. I'll try to explain that to them, at least there are people with brains and willing to listen on that company. About the other issues we talked about, is app_fax having the same behaviour as FFA, as expected now? Also (if I'm not asking too much), could you tell me how you decoded the packet stream into a tif file? That would be really useful on showing the problem to the telco guys.
----- "Steve Underwood" <steveu at coppice.org> escreveu:> Hi Vin?cius, > > Don't post big things, like wireshark traces, to a mailing list. They > > are likely to ban you. > > The first two calls in your wireshark log decode to the attached > images. > There were no lost packets. The wireshark logs contains exactly what > the > far end sent, and it was not good. The first fax page has 12 bad pixel > > rows. This page was accepted, as minor defects like this are normally > > accepted. The second fax starts out OK, then then just falls apart. I > > think the receive modem in that gateway probably lost sync. The data > looks like complete rubbish beyond the part that decodes to something > > sensible. > > The system you are trying to interwork with seems to have serious > issues. It can be difficult to get providers to sort out T.38 issues, > as > many of them have very little understanding of the systems they have. > > Even big carriers can be very unresponsive, because they just don't > know > what to do. > > Regards, > Steve > > > On 02/18/2010 12:19 AM, Vin?cius Fontes wrote: > >> Can you try the attached version of spandsp with the T.38 gateway > you > >> > >> are using? It behaves a lot more like FFA, and I want to see if > this > >> makes the gateway behave properly. If it does I will have to > consider > >> > >> some more permanent changes to spandsp to increase its tolerance > of > >> yet > >> another broken T.38 implementation. It really is depressing having > to > >> > >> work around other people's broken systems like this. > >> > >> Steve > >> > > Hi Steve. I installed the spandsp you sent me and made some tests. > > > > Before proceeding, it is important to share with you what I noticed > today. Even before I installed the new spandsp lib I noticed that I > started to receive faxes at 9600 bps, only problem being the fax won't > get received in about 60% of the cases. I'm guessing the provider > changed something at their side, because I don't remember changing any > configs on Asterisk. Also important to say that it is happening to > both app_fax and FFA now. > > > > Anyway, I installed the spandsp you sent me and noticed no > difference on the behaviour. Attached to this message is a capture of > four calls. As usual, you should only consider calls from 5433142499 > to 5421047008. There are four calls, detailed as follows: > > > > 1) app_fax, returned an error. Here's the CLI: > > > > [Feb 17 13:55:16] -- Executing [5421047008 at entrada-e1:1] > Goto("SIP/voxip-00000010", "interno,7008,1") in new stack > > [Feb 17 13:55:16] -- Goto (interno,7008,1) > > [Feb 17 13:55:16] -- Executing [7008 at interno:1] > Goto("SIP/voxip-00000010", "macro-recebefax,s,1") in new stack > > [Feb 17 13:55:16] -- Goto (macro-recebefax,s,1) > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:1] > Set("SIP/voxip-00000010", "DB(fax/count)=92") in new stack > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:2] > Set("SIP/voxip-00000010", "FAXCOUNT=92") in new stack > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:3] > Set("SIP/voxip-00000010", "FAXFILE=fax-92-rx") in new stack > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:4] > Set("SIP/voxip-00000010", "LOCALSTATIONID=5421047008") in new stack > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:5] > ReceiveFAX("SIP/voxip-00000010", > "/var/spool/asterisk/fax/fax-92-rx.tif") in new stack > > [Feb 17 13:56:03] WARNING[3418]: app_fax.c:128 span_message: WARNING > T.30 Page did not end cleanly > > [Feb 17 13:56:09] WARNING[3418]: app_fax.c:178 phase_e_handler: > Error transmitting fax. result=40: Unexpected DCN after requested > retransmission. > > [Feb 17 13:56:09] WARNING[3418]: app_fax.c:767 transmit: > Transmission failed > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:6] > NoOp("SIP/voxip-00000010", "FAXSTATUS = FAILED") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:7] > NoOp("SIP/voxip-00000010", "FAXERROR = Unexpected DCN after requested > retransmission") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:8] > NoOp("SIP/voxip-00000010", "CALLID = 5433142499 ") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:9] > NoOp("SIP/voxip-00000010", "FAXPAGES = ") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:10] > NoOp("SIP/voxip-00000010", "FAXBITRATE = ") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:11] > NoOp("SIP/voxip-00000010", "FAXRESOLUTION = ") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:12] > NoOp("SIP/voxip-00000010", "FAXMODE = T38") in new stack > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:13] > Hangup("SIP/voxip-00000010", "") in new stack > > [Feb 17 13:56:09] == Spawn extension (macro-recebefax, s, 13) > exited non-zero on 'SIP/voxip-00000010' > > > > 2) app_fax, received the fax succesfully. No configs changed. > > > > 3) FFA, error. All I did in order to use FFA was this: > > > > module unload app_fax.so > > module load res_fax.so > > module load res_fax_digium.so > > > > Here's the CLI when the error happened: > > > > [Feb 17 13:56:35] -- Executing [5421047008 at entrada-e1:1] > Goto("SIP/voxip-00000019", "interno,7008,1") in new stack > > [Feb 17 13:56:35] -- Goto (interno,7008,1) > > [Feb 17 13:56:35] -- Executing [7008 at interno:1] > Goto("SIP/voxip-00000019", "macro-recebefax,s,1") in new stack > > [Feb 17 13:56:35] -- Goto (macro-recebefax,s,1) > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:1] > Set("SIP/voxip-00000019", "DB(fax/count)=93") in new stack > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:2] > Set("SIP/voxip-00000019", "FAXCOUNT=93") in new stack > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:3] > Set("SIP/voxip-00000019", "FAXFILE=fax-93-rx") in new stack > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:4] > Set("SIP/voxip-00000019", "LOCALSTATIONID=5421047008") in new stack > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:5] > ReceiveFAX("SIP/voxip-00000019", > "/var/spool/asterisk/fax/fax-93-rx.tif") in new stack > > [Feb 17 13:56:35] -- Channel 'SIP/voxip-00000019' receiving FAX > '/var/spool/asterisk/fax/fax-93-rx.tif' > > [Feb 17 13:56:35] NOTICE[3435]: res_fax.c:712 generic_fax_exec: > Negotiating T.38 for receive on SIP/voxip-00000019 > > [Feb 17 13:56:35] NOTICE[3435]: res_fax.c:779 generic_fax_exec: > Negotiated T.38 for receive on SIP/voxip-00000019 > > [Feb 17 13:56:35] -- Channel 'SIP/voxip-00000019' FAX session > '0' started > > [Feb 17 13:57:26] -- FAX handle 0: [ 051.075619 ], entering > CLOSING state > > [Feb 17 13:57:26] -- FAX handle 0: [ 051.165605 ], entering > CLOSING state > > [Feb 17 13:57:29] -- Channel 'SIP/voxip-00000019' FAX session > '0' is complete, result: 'FAILED' (FAX_FAILURE_PARTIAL), error: > 'NO_ERROR', pages: 1, resolution: '204x98', transfer rate: '9600', > remoteSID: '5421047010' > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:6] > NoOp("SIP/voxip-00000019", "FAXSTATUS = FAILED") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:7] > NoOp("SIP/voxip-00000019", "FAXERROR = NO_ERROR") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:8] > NoOp("SIP/voxip-00000019", "CALLID = 5433142499 5421047010") in new > stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:9] > NoOp("SIP/voxip-00000019", "FAXPAGES = 1") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:10] > NoOp("SIP/voxip-00000019", "FAXBITRATE = 9600") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:11] > NoOp("SIP/voxip-00000019", "FAXRESOLUTION = 204x98") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:12] > NoOp("SIP/voxip-00000019", "FAXMODE = ") in new stack > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:13] > Hangup("SIP/voxip-00000019", "") in new stack > > [Feb 17 13:57:29] == Spawn extension (macro-recebefax, s, 13) > exited non-zero on 'SIP/voxip-00000019' > > > > 4) FFA, received successfully. Again, no change in any configs. > > > > > > That provider delivers a 2mbps SHDSL modem connected to a Cisco 1841 > router with 2 ethernet interfaces. On the first one it's the SIP DID > dedicated service, capped to 1mbps and 15 simultaneous calls. On the > other port there is a business grade Internet access, also capped to > 1mbps. The only thing that changed form last week is that I started to > use that Internet link, but it should not interfere because the > provider configures QoS on both ends. I unfortunely don't understand > the T38 protocol enough to tell if there's packet loss or something > just looking at the capture. Could you take a look at that please? I > think that might be the cause of the sudden unreliability. > > > >
----- "Vin?cius Fontes" <vinicius at canall.com.br> escreveu:> ----- "Steve Underwood" <steveu at coppice.org> escreveu: > > > Hi Vin?cius, > > > > Don't post big things, like wireshark traces, to a mailing list. > They > > > > are likely to ban you. > > > > The first two calls in your wireshark log decode to the attached > > images. > > There were no lost packets. The wireshark logs contains exactly > what > > the > > far end sent, and it was not good. The first fax page has 12 bad > pixel > > > > rows. This page was accepted, as minor defects like this are > normally > > > > accepted. The second fax starts out OK, then then just falls apart. > I > > > > think the receive modem in that gateway probably lost sync. The data > > > looks like complete rubbish beyond the part that decodes to > something > > > > sensible. > > > > The system you are trying to interwork with seems to have serious > > issues. It can be difficult to get providers to sort out T.38 > issues, > > as > > many of them have very little understanding of the systems they > have. > > > > Even big carriers can be very unresponsive, because they just don't > > know > > what to do. > > > > Regards, > > Steve > > > > > > On 02/18/2010 12:19 AM, Vin?cius Fontes wrote: > > >> Can you try the attached version of spandsp with the T.38 > gateway > > you > > >> > > >> are using? It behaves a lot more like FFA, and I want to see if > > this > > >> makes the gateway behave properly. If it does I will have to > > consider > > >> > > >> some more permanent changes to spandsp to increase its tolerance > > of > > >> yet > > >> another broken T.38 implementation. It really is depressing > having > > to > > >> > > >> work around other people's broken systems like this. > > >> > > >> Steve > > >> > > > Hi Steve. I installed the spandsp you sent me and made some > tests. > > > > > > Before proceeding, it is important to share with you what I > noticed > > today. Even before I installed the new spandsp lib I noticed that I > > started to receive faxes at 9600 bps, only problem being the fax > won't > > get received in about 60% of the cases. I'm guessing the provider > > changed something at their side, because I don't remember changing > any > > configs on Asterisk. Also important to say that it is happening to > > both app_fax and FFA now. > > > > > > Anyway, I installed the spandsp you sent me and noticed no > > difference on the behaviour. Attached to this message is a capture > of > > four calls. As usual, you should only consider calls from > 5433142499 > > to 5421047008. There are four calls, detailed as follows: > > > > > > 1) app_fax, returned an error. Here's the CLI: > > > > > > [Feb 17 13:55:16] -- Executing [5421047008 at entrada-e1:1] > > Goto("SIP/voxip-00000010", "interno,7008,1") in new stack > > > [Feb 17 13:55:16] -- Goto (interno,7008,1) > > > [Feb 17 13:55:16] -- Executing [7008 at interno:1] > > Goto("SIP/voxip-00000010", "macro-recebefax,s,1") in new stack > > > [Feb 17 13:55:16] -- Goto (macro-recebefax,s,1) > > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:1] > > Set("SIP/voxip-00000010", "DB(fax/count)=92") in new stack > > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:2] > > Set("SIP/voxip-00000010", "FAXCOUNT=92") in new stack > > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:3] > > Set("SIP/voxip-00000010", "FAXFILE=fax-92-rx") in new stack > > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:4] > > Set("SIP/voxip-00000010", "LOCALSTATIONID=5421047008") in new stack > > > [Feb 17 13:55:16] -- Executing [s at macro-recebefax:5] > > ReceiveFAX("SIP/voxip-00000010", > > "/var/spool/asterisk/fax/fax-92-rx.tif") in new stack > > > [Feb 17 13:56:03] WARNING[3418]: app_fax.c:128 span_message: > WARNING > > T.30 Page did not end cleanly > > > [Feb 17 13:56:09] WARNING[3418]: app_fax.c:178 phase_e_handler: > > Error transmitting fax. result=40: Unexpected DCN after requested > > retransmission. > > > [Feb 17 13:56:09] WARNING[3418]: app_fax.c:767 transmit: > > Transmission failed > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:6] > > NoOp("SIP/voxip-00000010", "FAXSTATUS = FAILED") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:7] > > NoOp("SIP/voxip-00000010", "FAXERROR = Unexpected DCN after > requested > > retransmission") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:8] > > NoOp("SIP/voxip-00000010", "CALLID = 5433142499 ") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:9] > > NoOp("SIP/voxip-00000010", "FAXPAGES = ") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:10] > > NoOp("SIP/voxip-00000010", "FAXBITRATE = ") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:11] > > NoOp("SIP/voxip-00000010", "FAXRESOLUTION = ") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:12] > > NoOp("SIP/voxip-00000010", "FAXMODE = T38") in new stack > > > [Feb 17 13:56:09] -- Executing [s at macro-recebefax:13] > > Hangup("SIP/voxip-00000010", "") in new stack > > > [Feb 17 13:56:09] == Spawn extension (macro-recebefax, s, 13) > > exited non-zero on 'SIP/voxip-00000010' > > > > > > 2) app_fax, received the fax succesfully. No configs changed. > > > > > > 3) FFA, error. All I did in order to use FFA was this: > > > > > > module unload app_fax.so > > > module load res_fax.so > > > module load res_fax_digium.so > > > > > > Here's the CLI when the error happened: > > > > > > [Feb 17 13:56:35] -- Executing [5421047008 at entrada-e1:1] > > Goto("SIP/voxip-00000019", "interno,7008,1") in new stack > > > [Feb 17 13:56:35] -- Goto (interno,7008,1) > > > [Feb 17 13:56:35] -- Executing [7008 at interno:1] > > Goto("SIP/voxip-00000019", "macro-recebefax,s,1") in new stack > > > [Feb 17 13:56:35] -- Goto (macro-recebefax,s,1) > > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:1] > > Set("SIP/voxip-00000019", "DB(fax/count)=93") in new stack > > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:2] > > Set("SIP/voxip-00000019", "FAXCOUNT=93") in new stack > > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:3] > > Set("SIP/voxip-00000019", "FAXFILE=fax-93-rx") in new stack > > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:4] > > Set("SIP/voxip-00000019", "LOCALSTATIONID=5421047008") in new stack > > > [Feb 17 13:56:35] -- Executing [s at macro-recebefax:5] > > ReceiveFAX("SIP/voxip-00000019", > > "/var/spool/asterisk/fax/fax-93-rx.tif") in new stack > > > [Feb 17 13:56:35] -- Channel 'SIP/voxip-00000019' receiving > FAX > > '/var/spool/asterisk/fax/fax-93-rx.tif' > > > [Feb 17 13:56:35] NOTICE[3435]: res_fax.c:712 generic_fax_exec: > > Negotiating T.38 for receive on SIP/voxip-00000019 > > > [Feb 17 13:56:35] NOTICE[3435]: res_fax.c:779 generic_fax_exec: > > Negotiated T.38 for receive on SIP/voxip-00000019 > > > [Feb 17 13:56:35] -- Channel 'SIP/voxip-00000019' FAX session > > '0' started > > > [Feb 17 13:57:26] -- FAX handle 0: [ 051.075619 ], entering > > CLOSING state > > > [Feb 17 13:57:26] -- FAX handle 0: [ 051.165605 ], entering > > CLOSING state > > > [Feb 17 13:57:29] -- Channel 'SIP/voxip-00000019' FAX session > > '0' is complete, result: 'FAILED' (FAX_FAILURE_PARTIAL), error: > > 'NO_ERROR', pages: 1, resolution: '204x98', transfer rate: '9600', > > remoteSID: '5421047010' > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:6] > > NoOp("SIP/voxip-00000019", "FAXSTATUS = FAILED") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:7] > > NoOp("SIP/voxip-00000019", "FAXERROR = NO_ERROR") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:8] > > NoOp("SIP/voxip-00000019", "CALLID = 5433142499 5421047010") in > new > > stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:9] > > NoOp("SIP/voxip-00000019", "FAXPAGES = 1") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:10] > > NoOp("SIP/voxip-00000019", "FAXBITRATE = 9600") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:11] > > NoOp("SIP/voxip-00000019", "FAXRESOLUTION = 204x98") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:12] > > NoOp("SIP/voxip-00000019", "FAXMODE = ") in new stack > > > [Feb 17 13:57:29] -- Executing [s at macro-recebefax:13] > > Hangup("SIP/voxip-00000019", "") in new stack > > > [Feb 17 13:57:29] == Spawn extension (macro-recebefax, s, 13) > > exited non-zero on 'SIP/voxip-00000019' > > > > > > 4) FFA, received successfully. Again, no change in any configs. > > > > > > > > > That provider delivers a 2mbps SHDSL modem connected to a Cisco > 1841 > > router with 2 ethernet interfaces. On the first one it's the SIP > DID > > dedicated service, capped to 1mbps and 15 simultaneous calls. On > the > > other port there is a business grade Internet access, also capped > to > > 1mbps. The only thing that changed form last week is that I started > to > > use that Internet link, but it should not interfere because the > > provider configures QoS on both ends. I unfortunely don't > understand > > the T38 protocol enough to tell if there's packet loss or something > > just looking at the capture. Could you take a look at that please? > I > > think that might be the cause of the sudden unreliability. > > > > > > > > > Another thing I found out: with vanilla FFA, without setting any > options, the baudrate is negotiated at 9600 and the fax may or may not > be transmitted. But if I set the following options: > > exten => s,n,Set(FAXOPT(ecm)=yes) > exten => s,n,Set(FAXOPT(modem)=V28) > > Then the transmission is negotiated at 4800bps and all transmissions > occur perfectly. Unfortunely I didn't find a similar config on > app_fax, so I could not test this on app_fax. > > You said in another email that the provider is sending invalid > training data. I noticed also that the provider always try to > negotiate the baudrate on the SDP to 14400, and that is accepted by > Asterisk. Could it be that's a buffer overflow happening? I mean, is > it possible that the provider is trying to send data faster than > app_fax/spandsp/Asterisk can handle?And by V28 I of course meant V27 on that last email.