Santiago Gimeno
2009-May-20 10:58 UTC
[asterisk-users] Problems receiving some faxes in T.38
Hello, We have been working with the ReceiveFax application for some weeks now in order to receive faxes in T.38 and it works fairly well, but there are some faxes that for some reason we are not able to receive correctly. The asterisk version we are using is 1.6.0.6 with spandsp-0.0.5pre4 and the asterisk machine is behind a CISCO mediaGW to be able to communicate with the PSTN. The SIP call flows are different between the faxes we receive correctly and the ones that fail. In the case of successfully received faxes, after establishing the audio session between de CISCO and Asterisk, CISCO sends a re-INVITE with the T.38 SDP. The T.38 setup succeeds. CISCO Asterisk | | | | | | |INVITE (SDP alaw) |------------->| |200 OK (SDP alaw) |<-------------| |ACK | |------------->| |Re-INVITE (SDP T.38) |------------->| |200 OK (SDP T.38) |<-------------| |ACK | |------------->| | | |..............| |T.38 | |..............| |[t.38]no signal |<-------------| |[t.38]no signal |------------->| |[t.38]CED | |<-------------| |[t.38]V21-preamble |------------->| | | | | On the other hand, with some faxes, the re-INVITE is sent by Asterisk and it looks that there is something wrong in the T.38 setup that makes the fax reception fail after the permitted retries. The FAXERROR variable is set to: "Disconnected after permitted retries". What I can see from the traces is that it gets to a point that asterisk is sending T.38 data to the CISCO but the CISCO doesn't answer. CISCO Asterisk | | | | | | |INVITE (SDP alaw) |------------->| |200 OK (SDP alaw) |<-------------| |ACK | |------------->| |Re-INVITE (SDP T.38) |<-------------| |200 OK (SDP T.38) |------------->| |ACK | |<-------------| | | |..............| |T.38 | |..............| |[t.38]no signal |<-------------| |[t.38]no signal |------------->| |[t.38]CED | |<-------------| |[t.38]no signal |------------->| |[t.38]V21-preamble |<-------------| |[t.38]hdlc | |<-------------| |[t.38]no signal |<-------------| |[t.38]V21-preamble |<-------------| |[t.38]hdlc | |<-------------| |[t.38]no signal |<-------------| |[t.38]V21-preamble |<-------------| |[t.38]hdlc | |<-------------| |[t.38]no signal |<-------------| |[t.38]V21-preamble |<-------------| |[t.38]hdlc | |<-------------| |[t.38]no signal |<-------------| |[t.38]V21-preamble |<-------------| |[t.38]DCN | |<-------------| |BYE | |<-------------| |200 OK | |------------->| Any idea of what might be happening? Thanks in advance. Best regards, Santiago Gimeno The relevant information in the asterisk configuration files is: extensions.conf [fax-in] exten => 99999,1,Set(INCOMING_FAXFILE=/root/santi/fax/incoming.tif) exten => 99999,n,Answer() exten => 99999,n,Wait(3) exten => 99999,n,ReceiveFax(${INCOMING_FAXFILE}) sip.conf [general] canreinvite=no t38pt_udptl=yes disallow=all allow=alaw context=fax-in The CISCO peer configuration: dial-peer voice 6 voip destination-pattern 88T session protocol sipv2 session target ipv4:10.100.0.51 session transport udp dtmf-relay rtp-nte codec g711alaw fax-relay ecm disable fax nsf 000000 fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback none no vad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090520/af07d09e/attachment-0001.htm
Steve Underwood
2009-May-20 12:33 UTC
[asterisk-users] Problems receiving some faxes in T.38
Hi Santiago, Santiago Gimeno wrote:> Hello, > > We have been working with the ReceiveFax application for some weeks > now in order to receive faxes in T.38 and it works fairly well, but > there are some faxes that for some reason we are not able to receive > correctly. > > The asterisk version we are using is 1.6.0.6 with spandsp-0.0.5pre4 > and the asterisk machine is behind a CISCO mediaGW to be able to > communicate with the PSTN. > > > The SIP call flows are different between the faxes we receive > correctly and the ones that fail. > > In the case of successfully received faxes, after establishing the > audio session between de CISCO and Asterisk, CISCO sends a re-INVITE > with the T.38 SDP. The T.38 setup succeeds. > > CISCO Asterisk > | | > | | > | | > |INVITE (SDP alaw) > |------------->| > |200 OK (SDP alaw) > |<-------------| > |ACK | > |------------->| > |Re-INVITE (SDP T.38) > |------------->| > |200 OK (SDP T.38) > |<-------------| > |ACK | > |------------->| > | | > |..............| > |T.38 | > |..............| > |[t.38]no signal > |<-------------| > |[t.38]no signal > |------------->| > |[t.38]CED | > |<-------------| > |[t.38]V21-preamble > |------------->|Did you draw that arrow in the wrong direction? The side answering the call should send the first V.21 signal.> | | > | | > > On the other hand, with some faxes, the re-INVITE is sent by Asterisk > and it looks that there is something wrong in the T.38 setup that > makes the fax reception fail after the permitted retries. The FAXERROR > variable is set to: "Disconnected after permitted retries". > What I can see from the traces is that it gets to a point that > asterisk is sending T.38 data to the CISCO but the CISCO doesn't answer. > > > CISCO Asterisk > | | > | | > | | > |INVITE (SDP alaw) > |------------->| > |200 OK (SDP alaw) > |<-------------| > |ACK | > |------------->| > |Re-INVITE (SDP T.38) > |<-------------| > |200 OK (SDP T.38) > |------------->| > |ACK | > |<-------------| > | | > |..............| > |T.38 | > |..............| > |[t.38]no signal > |<-------------| > |[t.38]no signal > |------------->| > |[t.38]CED | > |<-------------| > |[t.38]no signal > |------------->| > |[t.38]V21-preamble > |<-------------| > |[t.38]hdlc | > |<-------------| > |[t.38]no signal > |<-------------| > |[t.38]V21-preamble > |<-------------| > |[t.38]hdlc | > |<-------------| > |[t.38]no signal > |<-------------| > |[t.38]V21-preamble > |<-------------| > |[t.38]hdlc | > |<-------------| > |[t.38]no signal > |<-------------| > |[t.38]V21-preamble > |<-------------| > |[t.38]hdlc | > |<-------------| > |[t.38]no signal > |<-------------| > |[t.38]V21-preamble > |<-------------| > |[t.38]DCN | > |<-------------| > |BYE | > |<-------------| > |200 OK | > |------------->| > > > Any idea of what might be happening? > > Thanks in advance. Best regards, > > Santiago Gimeno > > > > > The relevant information in the asterisk configuration files is: > > extensions.conf > > [fax-in] > exten => 99999,1,Set(INCOMING_FAXFILE=/root/santi/fax/incoming.tif) > exten => 99999,n,Answer() > exten => 99999,n,Wait(3) > exten => 99999,n,ReceiveFax(${INCOMING_FAXFILE})Try changing that Wait(3) to Wait(6). It seems some T.38 boxes act strangely if the T.38 negotiation occurs too soon after the call starts. I am not clear why, though I have tried to find suitable test cases to pin this down.> > sip.conf > > [general] > canreinvite=no > t38pt_udptl=yes > disallow=all > allow=alaw > > context=fax-in > > > The CISCO peer configuration: > > dial-peer voice 6 voip > destination-pattern 88T > session protocol sipv2 > session target ipv4:10.100.0.51 > session transport udp > dtmf-relay rtp-nte > codec g711alaw > fax-relay ecm disableWhy turn off ECM?> fax nsf 000000 > fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback none > no vadRegards, Steve
David Backeberg
2009-May-21 11:19 UTC
[asterisk-users] Problems receiving some faxes in T.38
On Wed, May 20, 2009 at 6:58 AM, Santiago Gimeno <santiago.gimeno at gmail.com> wrote:> We have been working with the ReceiveFax application for some weeks now in > order to receive faxes in T.38 and it works fairly well, but there are some > faxes that for some reason we are not able to receive correctly. > > The asterisk version we are using is 1.6.0.6 with spandsp-0.0.5pre4 and the > asterisk machine is behind a CISCO mediaGW to be able to communicate with > the PSTN.That's very similar to a setup I made. And I was troubleshooting similar problems. Let me ask you a question: Are you quite confident that the inbound faxes that fail are going to succeed on an ordinary fax machine? In my case I was able to crank through my logs, and trace that the failing calls were people who were calling a fax line by mistake, or wardialers, or clients with lousy fax configurations where those faxes also fail to our 'real' fax machines. When we stopped counting the 'never going to work anyway' faxes in our fax success calculations we had nearly perfect success rates. And here's my debugging tip. Pick a number that always fails, change the Cisco dialpeer to send those as ordinary audio fax passthrough, no t.38, use asterisk with monitor to record them, and watch whether they ever succeed. I'm willing to be my two cents that they don't.