Summary:	ASTERISK-27754: res_fax_spandsp: Asterisk getting "stuck" on T.38 NSF from specific vendor gateway
Reporter:	Nabeel Jafferali (nabeelj)	Labels:	fax
Date Opened:	2018-03-20 14:46:24	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Resources/res_fax Resources/res_fax_spandsp
Versions:	15.2.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) capture.pcap ( 1) debug_27754.txt
Description:	I am using Asterisk 15.2.0 as a T.38 gateway, with a local non-T.38 capable IAX client (iaxmodem) making calls through Asterisk to T.38 capable SIP gateways. It works quite well, except for one specific scenario that I have spent some time isolating. Basically, if Asterisk makes a call through a specific vendor's SIP-PSTN gateway (Metaswitch UMG), it appears Asterisk gets "stuck" after receiving a NSF packet in the T.38 stream. What I mean by stuck is that, listening to the audible fax tones generated by Asterisk, I hear the normal training, followed by a *constant* high-pitched fax tone that does not stop. This is despite the fact that, looking at the T.38 stream, I see "no-signal", followed by a second v21-preamble, NSF, CSI, etc. In our upstream network, I tried re-routing the same PSTN phone number to other SIP-PSTN gateways (Audiocodes), and the problem does not persists, even though the T.38 traffic seems similar (i.e. v21-preamble, NSF, CSI, etc.). In fact, when I just listen to the audio being generated in this case, I can hear the difference (normal traning, followed by non-constant fax tone, followed by silence). Also note that other fax calls out the same Metaswitch UMG gateway, where the remote fax machine does not send NSF message, are successful. So, it would seem the issue only occurs when the remote fax machine sends a NSF message, which the Metaswitch UMG gateway packetizes into T.38, and is received by Asterisk for demodulation. I have opened a ticket with the gateway vendor, but since it appears that Asterisk (or whatever library it uses) is demodulating the T.38 stream incorrectly, I am trying to see if we can pursue it here. I trying setting "core set verbose 100", "udptl set debug on" and "core set debug 100", but I see no difference in the Asterisk CLI logs between the good and bad cases.
Comments:	By: Asterisk Team (asteriskteam) 2018-03-20 14:46:25.668-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2018-03-20 15:34:36.958-0500 We need the logs as well as a wireshark capture so we can see the traffic itself. By: Asterisk Team (asteriskteam) 2018-04-04 12:00:01.467-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Nabeel Jafferali (nabeelj) 2018-05-15 11:36:29.038-0500 I ran the following commands on the Asterisk CLI: logger add channel debug_27754 notice,warning,error,debug,verbose,dtmf,fax core set verbose 5 core set debug 5 sip set debug on rtp set debug on udptl set debug on ...and then reproduced the issue. Attached is the debug_27754.txt file, as well as a network capture of the same call. By: Asterisk Team (asteriskteam) 2018-05-15 11:36:29.482-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Joshua C. Colp (jcolp) 2018-06-05 05:19:34.050-0500 Asterisk uses the spandsp library for this. We give it the T.38 (or audio), and it gives us T.38 (or audio) in return essentially. All the fax part is handled by it. The spandsp library is not something we really support ourselves or have expertise in, so this issue may not be fixable by us. By: Joshua C. Colp (jcolp) 2018-06-05 05:22:28.747-0500 I've accepted this issue as there does appear to be a problem, but per my last comment I do not believe it is in Asterisk and don't know if anyone will pursue looking at the spandsp side. I've kept it open for reference and in case someone does want to.