Summary:	ASTERISK-14703: [patch] faxing with T.38 fails
Reporter:	had (had)	Labels:
Date Opened:	2009-08-24 12:10:28	Date Closed:	2011-06-07 14:07:49
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) issue-15770.patch ( 1) issue-15770-1.4.26.1.patch ( 2) patch3.txt ( 3) trace_patch3.zip
Description:	I have asterisk 1.4.26.1 setup with T.38 passthrough. I have linksys 2102 ATA and my provider use Cisco gateway with T.38 support enabled. Everytime I send fax this fail with no apparent reason. In sip debug logs it looks that T.38 negotiation was successfull, later I receive SIP BYE packet from provider and the call si hangup but no fax is sent.
Comments:	By: Kevin P. Fleming (kpfleming) 2009-08-24 12:50:51 There is no indication that Asterisk caused any problem here; the T.38 reINVITE from the provider was properly passed through to your ATA device, which responded appropriately and the response was passed back to the provider. Everything looks normal, and then the provider hangs up the call. I'd suggest talking to your provider about why their end hung up the call before assuming Asterisk was involved in causing that to happen. By: had (had) 2009-08-24 14:40:58 I've done another couple of traces and it looks that everytime other side send the SIP BYE packet and hang up the call. I tried 6 times and 3 times provider hang up and 3 times my side. Please see second debug log where sip bye came from my side. By: had (had) 2009-08-24 15:20:30 I've also done wireshark trace. After T.38 negiotiation and switch over you can see UDPTL packets. But there are only UDPTL packets from ATA to asterisk. I can't see any packets from asterisk to provider... By: Kevin P. Fleming (kpfleming) 2009-08-24 15:28:53 That log shows a gap of about 49 seconds between the T.38 reINVITE process being completed and the BYE arriving; that would match up with the FAX protocol's 'no response' timer, and would indicate that the FAX endpoints could not communicate with each other. If you look at your packet capture, at packet 1980 the SPA starts to send T.38 UDPTL packets with a 'no-signal' indication, meaning the calling FAX machine is not sending any content. The receiving machine is not sending any content at all, but I can see some malformed T.38 packets being generated by Asterisk, so I'm still investigating. By: Kevin P. Fleming (kpfleming) 2009-08-24 16:04:23 Can you try the attached patch please? Thanks. By: had (had) 2009-08-24 16:52:44 please find attached new trace after applying the patch. Faxing is still unsuccessfull but it looks there are more information about those malformed packets. By: had (had) 2009-08-24 17:11:31 I'm not sure if I needed to make and make install after applying that patch. The next trace patch2.pcap is after make && make install. It looks very similar to he first patch trace. By: had (had) 2009-08-25 16:01:52 Is there any update in this issue? Thanks By: Kevin P. Fleming (kpfleming) 2009-08-25 16:28:37 I'm working on it, but it's complicated because your carrier's system is switching from audio to T.38 mode without changing UDP port numbers, which Asterisk is not yet prepared to handle properly. I'll try to post an updated patch today. By: had (had) 2009-08-25 16:35:30 thanks By: Kevin P. Fleming (kpfleming) 2009-08-25 18:15:38 OK, here's another patch to try; you'll have to revert the previous patch for this one to apply, as it touches the same code (and more). When you run this test, I'll need both the packet capture *and* the full Asterisk log (including 'set verbose 10', 'set debug 10', 'sip debug on' and 'rtp debug on') so that I can see how the packets going in and out relate to the processes in the Asterisk code. Thanks. By: had (had) 2009-08-25 19:51:02 OK, I've done couple of tests. Before I applied the patch I reverse to the last WM snapshot (which I've done after I installed and setup asterisk 1.4.26.1). For no particular reason I tried to send fax before applying of the second patch and I was very surprised when the fax was sent OK. I've send another 8-10 faxes and about 50% were successfull. Than I applied the patch and all faxes failed. But what I found out was: After the called fax answers and I can hear the modem noise: - fax is sent OK when the noise is longer and it sounds that it finished without being broken(before patch) - fax failed with Comms Error when the noise is cut in the middle and after short while of quiet period the noise continue and finish (before patch) - fax failed without any error message when the noise is cut in the middle and doesn't continue (after patch) I also have done traces: File "before_patch2_good.pcap" is trace from sucessfull fax Files "before_patch2_bad.pcap and txt" are trace and logs from unsucessfull fax File "patch2.txt" and "patch2trace.pcap" are traces and logs after applying patch I hope this make sense. Thanks By: had (had) 2009-08-25 20:00:37 I had to zip those traces because they are slightly bigger than 2M. By: Kevin P. Fleming (kpfleming) 2009-08-26 11:17:34 Somehow the proper patch did not get uploaded here... I'll try to get it uploaded now. By: Kevin P. Fleming (kpfleming) 2009-08-26 11:18:51 It's there now; thanks for your testing efforts. By: had (had) 2009-08-26 12:55:37 tried to apply that patch but it wasn't applied completely. Here is the error message: patching file channels/chan_sip.c Hunk #1 succeeded at 847 (offset -1 lines). Hunk #2 succeeded at 872 (offset -1 lines). Hunk #3 succeeded at 899 (offset -1 lines). Hunk #4 succeeded at 1496 (offset -20 lines). Hunk ASTERISK-1 succeeded at 1656 (offset -20 lines). Hunk ASTERISK-2 succeeded at 2878 (offset -20 lines). Hunk ASTERISK-3 succeeded at 3125 (offset -20 lines). Hunk ASTERISK-4 succeeded at 3844 (offset -22 lines). Hunk ASTERISK-5 succeeded at 3884 (offset -22 lines). Hunk ASTERISK-6 succeeded at 4452 (offset -22 lines). Hunk ASTERISK-7 succeeded at 4504 (offset -22 lines). Hunk ASTERISK-8 succeeded at 4512 (offset -22 lines). Hunk ASTERISK-9 FAILED at 5377. Hunk ASTERISK-10 succeeded at 5436 (offset -33 lines). Hunk ASTERISK-11 succeeded at 5604 (offset -33 lines). Hunk ASTERISK-12 succeeded at 5711 (offset -33 lines). Hunk ASTERISK-13 succeeded at 6264 (offset -37 lines). Hunk ASTERISK-14 succeeded at 7025 (offset -46 lines). Hunk ASTERISK-15 succeeded at 7039 (offset -46 lines). Hunk ASTERISK-16 succeeded at 7417 (offset -50 lines). Hunk ASTERISK-17 succeeded at 7452 (offset -51 lines). Hunk ASTERISK-18 succeeded at 8684 (offset -51 lines). Hunk ASTERISK-19 succeeded at 9579 (offset -51 lines). Hunk ASTERISK-20 succeeded at 9688 (offset -51 lines). Hunk ASTERISK-21 succeeded at 9823 (offset -51 lines). Hunk ASTERISK-22 succeeded at 10227 (offset -51 lines). Hunk ASTERISK-23 succeeded at 10246 (offset -51 lines). Hunk ASTERISK-24 succeeded at 10391 (offset -51 lines). Hunk ASTERISK-25 succeeded at 10439 (offset -51 lines). Hunk ASTERISK-26 succeeded at 10844 (offset -51 lines). Hunk ASTERISK-27 succeeded at 10889 (offset -51 lines). Hunk ASTERISK-28 succeeded at 10901 (offset -51 lines). Hunk ASTERISK-29 succeeded at 10994 (offset -51 lines). Hunk ASTERISK-30 succeeded at 11072 (offset -51 lines). Hunk ASTERISK-31 succeeded at 11095 (offset -51 lines). Hunk ASTERISK-32 succeeded at 11124 (offset -51 lines). Hunk ASTERISK-33 succeeded at 11317 (offset -51 lines). Hunk ASTERISK-34 succeeded at 11518 (offset -51 lines). Hunk ASTERISK-35 succeeded at 11590 (offset -51 lines). Hunk ASTERISK-36 succeeded at 12096 (offset -51 lines). Hunk ASTERISK-37 succeeded at 12107 (offset -51 lines). Hunk ASTERISK-38 succeeded at 12117 (offset -51 lines). Hunk ASTERISK-39 succeeded at 12455 (offset -51 lines). Hunk ASTERISK-40 succeeded at 12721 (offset -58 lines). Hunk ASTERISK-41 succeeded at 12840 (offset -58 lines). Hunk ASTERISK-42 succeeded at 13667 (offset -58 lines). Hunk ASTERISK-43 succeeded at 13675 (offset -58 lines). Hunk ASTERISK-44 succeeded at 14538 with fuzz 1 (offset -58 lines). Hunk ASTERISK-45 succeeded at 14682 (offset -59 lines). Hunk ASTERISK-46 succeeded at 15025 (offset -59 lines). Hunk ASTERISK-47 succeeded at 15047 (offset -59 lines). Hunk ASTERISK-48 succeeded at 15058 (offset -59 lines). Hunk ASTERISK-49 succeeded at 15070 (offset -59 lines). Hunk ASTERISK-50 succeeded at 15409 (offset -59 lines). Hunk ASTERISK-51 succeeded at 15922 (offset -59 lines). Hunk ASTERISK-52 succeeded at 15932 (offset -59 lines). Hunk ASTERISK-53 succeeded at 16675 (offset -59 lines). Hunk ASTERISK-54 succeeded at 17383 (offset -59 lines). Hunk ASTERISK-55 succeeded at 18188 (offset -59 lines). Hunk ASTERISK-56 succeeded at 18602 (offset -59 lines). Hunk ASTERISK-57 succeeded at 18653 (offset -59 lines). Hunk ASTERISK-58 succeeded at 18836 (offset -59 lines). Hunk ASTERISK-59 succeeded at 18894 (offset -59 lines). 1 out of 63 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej By: Kevin P. Fleming (kpfleming) 2009-08-26 13:18:39 Sorry about that; chan_sip.c has changed a little since 1.4.26.1 was released. I've uploaded a patch specific for 1.4.26.1, or you can use a checkout from the 1.4 branch in Subversion with the previously uploaded patch. By: had (had) 2009-08-26 13:52:25 Ok, after I applied the patch faxing is still failing with Comms.Error on fax display. I've attached trace and logs. By: Kevin P. Fleming (kpfleming) 2009-08-27 11:03:20 Alright, the first thing that I notice in the log and packet capture (and this was present in your last two or three as well) is that the SIP packets being received by Asterisk are duplicated... it receives the same SIP packet from the ATA or your provider two, three or four times. This is indicative of some sort of very strange network problem, and if it is happening to the media packets as well, there's no way that T.38 is going to work properly (and audio calls are going to sound strange as well). I do see one problem happening here because of the repeated SIP messages, which I'll try to address, but you really need to figure out what is causing that problem, because fixing it will probably solve your T.38 issues as well. By: had (had) 2009-08-27 11:30:21 I have that asterisk server installed on virtual server which is running on windows server. The eth0 interface of VM server is bridged with hardware ethernet card. This could cause duplicate packets in those traces. But the audio calls sounds OK. Today I will install the server on my other server with public IP and I'll test it again. By: Leif Madsen (lmadsen) 2009-09-22 08:42:39 Setting this issue back to Assigned while kpfleming solves the issue he discovered that he wanted to solve. By: Kevin P. Fleming (kpfleming) 2009-10-01 10:25:28 The repeated SIP message issue is minor, and no reason to leave this issue open. Given that we haven't had any feedback from the reporter in a month, I'm closing this issue. It can be reopened if the problem still exists.