Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/08/2011 04:04 AM, Kevin P. Fleming wrote: On 10/07/2011 02:20 PM, James Sharp wrote: On 10/07/2011 12:27 AM, Nasir Iqbal wrote: Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on No NAT involved and I shut off IPTables. Still no luck. Debug shows the SIP invite, RTP frames going in out, the SIP reinvite, and then UDPTL frames coming in until timeout. See the entire transaction at http://pastebin.ca/2087758 Thanks for that; it helps. First, we can see that Gafachi's T.38 implementation still has some breakage in it (although the problems are ones that Asterisk has been taught to deal with). In its 200 OK to the T.38 re-INVITE, it has a=T38FaxRateManagement:transferredTCFlocalTCF; this is not valid (the valid values for this are 'transferredTCF' and 'localTCF'). In addition, even though Asterisk sent a=T38FaxUdpEC:t38UDPRedundancy, Gafachi replied with a=T38FaxUdpEC:t38UDPFEC. For T.38 version 0 (which is in use here), the only valid response was either what Asterisk sent, or no T38FaxUdpEC value at all. t38UDPFEC is perfectly valid for version 0 of T.38. It works badly, so it makes no sense to use it, but it is valid. However, it is unlikely those are causing the call failure here. It's hard to say for sure without seeing the contents of the UDPTL packets, but based on their sizes, they are very likely t38-nosignal packets, and if that's all the FAX stack in Asterisk ever received, it would not trigger a FAX transaction to begin. Another possible problem is the repeated 'seq 0' in all the UDPTL packets, but this could be a problem with the UDPTL stack debugging messages themselves (this was just fixed in the Subversion branches for Asterisk 1.8 and later a couple of days ago). If you would, please retry this with the HEAD of the Asterisk 10 branch instead of 10.0.0-beta1, and also capture the UDPTL packets themselves so we can see what they contained. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/08/2011 05:21 AM, Steve Underwood wrote: On 10/08/2011 04:04 AM, Kevin P. Fleming wrote: On 10/07/2011 02:20 PM, James Sharp wrote: On 10/07/2011 12:27 AM, Nasir Iqbal wrote: Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on No NAT involved and I shut off IPTables. Still no luck. Debug shows the SIP invite, RTP frames going in out, the SIP reinvite, and then UDPTL frames coming in until timeout. See the entire transaction at http://pastebin.ca/2087758 Thanks for that; it helps. First, we can see that Gafachi's T.38 implementation still has some breakage in it (although the problems are ones that Asterisk has been taught to deal with). In its 200 OK to the T.38 re-INVITE, it has a=T38FaxRateManagement:transferredTCFlocalTCF; this is not valid (the valid values for this are 'transferredTCF' and 'localTCF'). In addition, even though Asterisk sent a=T38FaxUdpEC:t38UDPRedundancy, Gafachi replied with a=T38FaxUdpEC:t38UDPFEC. For T.38 version 0 (which is in use here), the only valid response was either what Asterisk sent, or no T38FaxUdpEC value at all. t38UDPFEC is perfectly valid for version 0 of T.38. It works badly, so it makes no sense to use it, but it is valid. Yes, it's a valid option in an offer, but it's not a valid option in answer unless that's the value that was in the offer; in all T.38 recommendations until the most recent, the answer must include either the same T38FaxUdpEC value as the offer did, or no value at all. The most recent version allows the answer to include a different value from the offer, because it was always reasonable, just not allowed by the recommendation. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
Interesting. I just signed up with Gafachi (haven't even tested the service yet) but I planned to make use of their T38 support since they are listed at voip-info as being one of the ITSP's that _do_ support T38. Have you tried contacting Gafachi with these results about their broken implementation? I would hope/expect them to try to fix this, instead of trying to force Asterisk to violate RFCs. It sounds like that Gafachi's T38 implementation is horribly, horribly broken I'm not tied to them at all, so if their stuff is broken, I'll go somewhere else. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On Sat, Oct 8, 2011 at 10:41 AM, Luke Hamburg l...@solvent-llc.com wrote: Interesting. I just signed up with Gafachi (haven't even tested the service yet) but I planned to make use of their T38 support since they are listed at voip-info as being one of the ITSP's that _do_ support T38. Have you tried contacting Gafachi with these results about their broken implementation? I would hope/expect them to try to fix this, instead of trying to force Asterisk to violate RFCs. It sounds like that Gafachi's T38 implementation is horribly, horribly broken I'm not tied to them at all, so if their stuff is broken, I'll go somewhere else. I signed up with Gafachi a few weeks ago to use them for T38 as well. I haven't had any luck getting it to work. I have been mainly trying to use Asterisk in T38 pass through mode and have tested with a Linksys SPA2102 and Zoiper. Gafachi basically told me they have many customers utilizing their T38 implementation and that it works. When asked for a list of compatible devices they said there were too many combinations and it was up to me to find a working solution. I am still looking a PAYG service provider that has a working T38 implementation. It seems like these are impossible to find. Ryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/08/2011 02:38 PM, Ryan Wagoner wrote: I signed up with Gafachi a few weeks ago to use them for T38 as well. I haven't had any luck getting it to work. I have been mainly trying to use Asterisk in T38 pass through mode and have tested with a Linksys SPA2102 and Zoiper. Gafachi basically told me they have many customers utilizing their T38 implementation and that it works. When asked for a list of compatible devices they said there were too many combinations and it was up to me to find a working solution. I wonder how many of these customers are just getting fallback to G711 when the T38 stack falls over. Heck, I thought I was getting T38 until I realized that I had SendFAX running with the audio fallback option. Turned that off, and fax fails 100% of the time. I am still looking a PAYG service provider that has a working T38 implementation. It seems like these are impossible to find. I found t38faxing.com. I was going to try them until I saw that their opening credit is $10. More than I want to spend to try for just home faxing. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On Sat, Oct 8, 2011 at 3:51 PM, James Sharp ja...@fivecats.org wrote: On 10/08/2011 02:38 PM, Ryan Wagoner wrote: I signed up with Gafachi a few weeks ago to use them for T38 as well. I haven't had any luck getting it to work. I have been mainly trying to use Asterisk in T38 pass through mode and have tested with a Linksys SPA2102 and Zoiper. Gafachi basically told me they have many customers utilizing their T38 implementation and that it works. When asked for a list of compatible devices they said there were too many combinations and it was up to me to find a working solution. I wonder how many of these customers are just getting fallback to G711 when the T38 stack falls over. Heck, I thought I was getting T38 until I realized that I had SendFAX running with the audio fallback option. Turned that off, and fax fails 100% of the time. I am still looking a PAYG service provider that has a working T38 implementation. It seems like these are impossible to find. I found t38faxing.com. I was going to try them until I saw that their opening credit is $10. More than I want to spend to try for just home faxing. I tried to sign-up with them a week ago, but received an error message. I went to their contact page and saw the grnvoip.com email. It turns out grnvoip and t38faxing are both owned by ez call service. I signed up for grnvoip.com, but was unable to get the t.38 faxing to work. Additionally ez call service's administration panel is not laid out the best and doesn't let you change the static IPs that are allowed to send calls to them. I have tested T38 faxing and pass through with Asterisk 1.8 and combinations of the Linksys SPA2102 ATA, Zoiper, and Asterisk. The faxes are sent and received successfully. Analyzing the packet traces with Wireshark shows they were sent with T38. I just need to find a provider that has a working T38 implementation. Ryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/09/2011 02:38 AM, Ryan Wagoner wrote: On Sat, Oct 8, 2011 at 10:41 AM, Luke Hamburgl...@solvent-llc.com wrote: Interesting. I just signed up with Gafachi (haven't even tested the service yet) but I planned to make use of their T38 support since they are listed at voip-info as being one of the ITSP's that _do_ support T38. Have you tried contacting Gafachi with these results about their broken implementation? I would hope/expect them to try to fix this, instead of trying to force Asterisk to violate RFCs. It sounds like that Gafachi's T38 implementation is horribly, horribly broken I'm not tied to them at all, so if their stuff is broken, I'll go somewhere else. I signed up with Gafachi a few weeks ago to use them for T38 as well. I haven't had any luck getting it to work. I have been mainly trying to use Asterisk in T38 pass through mode and have tested with a Linksys SPA2102 and Zoiper. Gafachi basically told me they have many customers utilizing their T38 implementation and that it works. When asked for a list of compatible devices they said there were too many combinations and it was up to me to find a working solution. I am still looking a PAYG service provider that has a working T38 implementation. It seems like these are impossible to find. Ryan Gafachi was one of the few service providers to support T.38 when we first started providing T.38 support in Asterisk and Callweaver. We did get things working reliably with them, by making our software tolerant of a few weird things Gafachi do. Any practical T.38 has to be made to tolerate a lot of weird things other implementations do. So Gafachi has worked in the past, but its entirely possible they have now broken their service further. Steve -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 12:27 AM, Nasir Iqbal wrote: Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on No NAT involved and I shut off IPTables. Still no luck. Debug shows the SIP invite, RTP frames going in out, the SIP reinvite, and then UDPTL frames coming in until timeout. See the entire transaction at http://pastebin.ca/2087758 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 02:20 PM, James Sharp wrote: On 10/07/2011 12:27 AM, Nasir Iqbal wrote: Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on No NAT involved and I shut off IPTables. Still no luck. Debug shows the SIP invite, RTP frames going in out, the SIP reinvite, and then UDPTL frames coming in until timeout. See the entire transaction at http://pastebin.ca/2087758 Thanks for that; it helps. First, we can see that Gafachi's T.38 implementation still has some breakage in it (although the problems are ones that Asterisk has been taught to deal with). In its 200 OK to the T.38 re-INVITE, it has a=T38FaxRateManagement:transferredTCFlocalTCF; this is not valid (the valid values for this are 'transferredTCF' and 'localTCF'). In addition, even though Asterisk sent a=T38FaxUdpEC:t38UDPRedundancy, Gafachi replied with a=T38FaxUdpEC:t38UDPFEC. For T.38 version 0 (which is in use here), the only valid response was either what Asterisk sent, or no T38FaxUdpEC value at all. However, it is unlikely those are causing the call failure here. It's hard to say for sure without seeing the contents of the UDPTL packets, but based on their sizes, they are very likely t38-nosignal packets, and if that's all the FAX stack in Asterisk ever received, it would not trigger a FAX transaction to begin. Another possible problem is the repeated 'seq 0' in all the UDPTL packets, but this could be a problem with the UDPTL stack debugging messages themselves (this was just fixed in the Subversion branches for Asterisk 1.8 and later a couple of days ago). If you would, please retry this with the HEAD of the Asterisk 10 branch instead of 10.0.0-beta1, and also capture the UDPTL packets themselves so we can see what they contained. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
for which user/number sip reinvite is for? ooh! you are running a direct application without any dialplan or user, may be that is the cause! I think you should first write fax dialplan, reload asterisk and test again with originate but this time with extension not application. Nasir Iqbal ICT Innovations http://www.ictinnovations.com/ On Sat, Oct 8, 2011 at 12:20 AM, James Sharp ja...@fivecats.org wrote: On 10/07/2011 12:27 AM, Nasir Iqbal wrote: Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on No NAT involved and I shut off IPTables. Still no luck. Debug shows the SIP invite, RTP frames going in out, the SIP reinvite, and then UDPTL frames coming in until timeout. See the entire transaction at http://pastebin.ca/2087758 -- __**__**_ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/**mailman/listinfo/asterisk-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 03:06 PM, Nasir Iqbal wrote: for which user/number sip reinvite is for? ooh! you are running a direct application without any dialplan or user, may be that is the cause! I think you should first write fax dialplan, reload asterisk and test again with originate but this time with extension not application. No, none of that is relevant. It's perfectly acceptable to call SendFAX() on a CLI/AMI/spool-originated channel. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 04:04 PM, Kevin P. Fleming wrote: First, we can see that Gafachi's T.38 implementation still has some breakage in it (although the problems are ones that Asterisk has been taught to deal with). In its 200 OK to the T.38 re-INVITE, it has a=T38FaxRateManagement:transferredTCFlocalTCF; this is not valid (the valid values for this are 'transferredTCF' and 'localTCF'). In addition, even though Asterisk sent a=T38FaxUdpEC:t38UDPRedundancy, Gafachi replied with a=T38FaxUdpEC:t38UDPFEC. For T.38 version 0 (which is in use here), the only valid response was either what Asterisk sent, or no T38FaxUdpEC value at all. However, it is unlikely those are causing the call failure here. It's hard to say for sure without seeing the contents of the UDPTL packets, but based on their sizes, they are very likely t38-nosignal packets, and if that's all the FAX stack in Asterisk ever received, it would not trigger a FAX transaction to begin. Another possible problem is the repeated 'seq 0' in all the UDPTL packets, but this could be a problem with the UDPTL stack debugging messages themselves (this was just fixed in the Subversion branches for Asterisk 1.8 and later a couple of days ago). Theres a few t30-nosignal packets at the beginning, but then they transition to other t30 packets, including CNG, CED, preambles, training and data. Wireshark says the sequence number is always 0, so it appears that Asterisk is not mis-displaying http://pastebin.ca/2087784 I can provide the raw tcpdump file if needed. If you would, please retry this with the HEAD of the Asterisk 10 branch instead of 10.0.0-beta1, and also capture the UDPTL packets themselves so we can see what they contained. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 03:29 PM, James Sharp wrote: On 10/07/2011 04:04 PM, Kevin P. Fleming wrote: First, we can see that Gafachi's T.38 implementation still has some breakage in it (although the problems are ones that Asterisk has been taught to deal with). In its 200 OK to the T.38 re-INVITE, it has a=T38FaxRateManagement:transferredTCFlocalTCF; this is not valid (the valid values for this are 'transferredTCF' and 'localTCF'). In addition, even though Asterisk sent a=T38FaxUdpEC:t38UDPRedundancy, Gafachi replied with a=T38FaxUdpEC:t38UDPFEC. For T.38 version 0 (which is in use here), the only valid response was either what Asterisk sent, or no T38FaxUdpEC value at all. However, it is unlikely those are causing the call failure here. It's hard to say for sure without seeing the contents of the UDPTL packets, but based on their sizes, they are very likely t38-nosignal packets, and if that's all the FAX stack in Asterisk ever received, it would not trigger a FAX transaction to begin. Another possible problem is the repeated 'seq 0' in all the UDPTL packets, but this could be a problem with the UDPTL stack debugging messages themselves (this was just fixed in the Subversion branches for Asterisk 1.8 and later a couple of days ago). Theres a few t30-nosignal packets at the beginning, but then they transition to other t30 packets, including CNG, CED, preambles, training and data. Wireshark says the sequence number is always 0, so it appears that Asterisk is not mis-displaying You shouldn't be *receiving* CNG, as you are the calling endpoint. If you are seeing UDPTL packets containing T.38 CED, V.21 preamble, DIS, etc. then something is badly wrong. ... and, that thing is probably the sequence number. Once Asterisk sees a packet with sequence number 0, any subsequent packets received with the same sequence number will be dropped (because according to the T.38 recommendation, they must be retransmissions... new packets would have higher sequence numbers). So these UDPTL packets are never making their way up to the FAX stack, and the FAX transaction never gets started. I guess it must be common for UDPTL stacks out there to just not care about repeated sequence numbers, although the one in Asterisk sure does (and it's based on the same code as the one in CallWeaver, FreeSwitch and maybe other packages too). If you'd like to experiment, you can comment out lines 495 and 511 of main/udptl.c, which will make Asterisk's UDPTL stack just not care at all about the incoming sequence number. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
On 10/07/2011 04:42 PM, Kevin P. Fleming wrote: You shouldn't be *receiving* CNG, as you are the calling endpoint. You're right. Hadn't even thought about that. If you are seeing UDPTL packets containing T.38 CED, V.21 preamble, DIS, etc. then something is badly wrong. ... and, that thing is probably the sequence number. Once Asterisk sees a packet with sequence number 0, any subsequent packets received with the same sequence number will be dropped (because according to the T.38 recommendation, they must be retransmissions... new packets would have higher sequence numbers). So these UDPTL packets are never making their way up to the FAX stack, and the FAX transaction never gets started. I guess it must be common for UDPTL stacks out there to just not care about repeated sequence numbers, although the one in Asterisk sure does (and it's based on the same code as the one in CallWeaver, FreeSwitch and maybe other packages too). If you'd like to experiment, you can comment out lines 495 and 511 of main/udptl.c, which will make Asterisk's UDPTL stack just not care at all about the incoming sequence number. HEAD out of SVN + the sequence number change still gets no fax transmit. I do get a few addition fax status messages on the console, though. I'm getting -- FAX handle 0: [ 000.062327 ], STAT_EVT_RX_IMG_STRT st: WT_DIS rt: UNEXPECT 4-9 times (with changing timestamps, of course), then nothing until disconnect. It sounds like that Gafachi's T38 implementation is horribly, horribly broken. I'm not tied to them at all, so if their stuff is broken, I'll go somewhere else. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Digium FFA + Gafachi T38 outgoing issues
Check firewall and NAT settings! Monitoring sip and media flow from asterisk cli can help, use sip set debug on, rtp set debug on and udptl set debug on Nasir Iqbal ICT Innovations http://www.ictinnovations.com/ On Fri, Oct 7, 2011 at 1:37 AM, James Sharp ja...@fivecats.org wrote: Hi, folks. I'm having a heck of a time trying to get outgoing T38 faxing (I don't need inbound right now) working with FFA and Gafachi. G711 faxing works (as well as can be expected over the internet), but I want the higher reliability of T38. I'm running Asterisk 10-beta1. When I drop my callfile in to make the call, I get this: -- Attempting call on SIP/18884732963@gafachi1a for application SendFAX(/srv/httpd/htdocs/**upload/scantest2.tiff,dz) (Retry 1) == Using UDPTL CoS mark 5 == Using SIP RTP CoS mark 5 Channel SIP/gafachi1a-000a was answered. Launching SendFAX(/srv/httpd/htdocs/**upload/scantest2.tiff,dz) on SIP/gafachi1a-000a -- Channel 'SIP/gafachi1a-000a' sending FAX: --/srv/httpd/htdocs/upload/**scantest2.tiff -- Channel 'SIP/gafachi1a-000a' FAX session '6' started -- FAX handle 0: [ 000.000594 ], STAT_EVT_STRT_TX st: IDLE rt: IDLENSTX -- FAX handle 0: [ 000.001139 ], STAT_EVT_TX_HW_RDY st: WT_TX_HW_RDY rt: TRDYNHTY -- FAX handle 0: [ 000.001724 ], P30EVN_SEND_STARTED [Oct 6 04:21:36] ERROR[11616]: res_fax.c:1421 generic_fax_exec: channel 'SIP/gafachi1a-000a' FAX session '6' failure, reason: 'fax session timed-out' (TIMEOUT) [Oct 6 04:21:36] NOTICE[11616]: pbx_spool.c:373 attempt_thread: Call completed to SIP/18884732963@gafachi1a THIS PART HAPPENS ABOUT 15 SECONDS LATER -- FAX handle 0: [ 040.000211 ], STAT_EVT_T1_EXPst: WT_DIS rt: WDISNT1X -- FAX handle 0: [ 042.499953 ], STAT_EVT_HW_CLOSE st: WT_HW_CLS rt: WCLSNCLS -- FAX handle 0: [ 042.500083 ], STAT_SES_COMPLETE -- FAX handle 0: [ 042.500110 ], P30EVN_COMPLETE -- Channel 'SIP/gafachi1a-000a' FAX session '6' is complete, result: 'FAILED' (FAX_NO_FAX), error: 'T1_TIMEOUT', pages: 0, resolution: 'unknown', transfer rate: '2400', remoteSID: '' A tcpdump trace shows the initial invite, ringing, answering, some G711 frames back and forth, the send-T38-invite-after-10-**seconds reinvite (as specified by the Z option), then the far end sends a bunch of T38 traffic until Asterisk times out and drops the call. What also confuses me is this (and this may just be semantics or a true bug): asterisk*CLI fax show stats FAX Statistics: --- Current Sessions : 0 Reserved Sessions: 0 Transmit Attempts: 8 Receive Attempts : 0 Completed FAXes : 7 Failed FAXes : 7 How can I have 8 attempted transmits, 7 completed faxes, and 7 failed faxes? I know 1 transmit didn't go through because I tried to place one call while another was in progess and I only have one licensed channel. Thanks, James Sharp ja...@fivecats.org -- __**__**_ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/**mailman/listinfo/asterisk-**usershttp://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
