Summary:	ASTERISK-27657: res_pjsip_t38: ATA fails with hangupcause 58(Bearer capability not available)
Reporter:	Jared Hull (fortytwo)	Labels:	fax pjsip
Date Opened:	2018-02-05 12:48:34.000-0600	Date Closed:	2018-07-10 06:56:12
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_fax Resources/res_pjsip_t38
Versions:	15.0.0-beta1 15.2.0 15.3.0	Frequency of Occurrence	Constant
Related Issues:	is caused by ASTERISK-27080 res_pjsip_t38: Slow T.38 re-invite rejection if remote leg has T.38 disabled
Environment:		Attachments:	( 0) 14.6_log_withPJSIPlogging.txt ( 1) log14-6_mar26.txt ( 2) pjsip.conf.txt ( 3) res_fax.conf.txt ( 4) t38_14-6_mar26.pcap ( 5) t38_asterisk14-6.pcap ( 6) t38_log.txt ( 7) t38.pcap
Description:	Sending a T.38 fax from an ATA is failing with hangup cause 58(Bearer capability not available) on Asterisk 15.2, but the same device and dialplan on Asterisk 14.6 works. There are several strange things in the log: # {{pjsip set logger on}} reports some duplicate T.38 re-INVITEs being recieved from the ATA, but a packet capture on the Asterisk server and a pcap on the SBC server relaying to the Asterisk server show that only one INVITE is there. It also looks like Asterisk is processing both # Sometimes Asterisk sends {{491 Another INVITE transaction in progress}} in response to the T.38 re-INVITE from the ATA. # 109 is the ATA requesting T.38, I don't know what this means. {noformat}[Feb  5 17:39:01] DEBUG[7126][C-0000001d]: res_fax.c:3275 fax_gateway_detect_t38: T.38 disabled on channel PJSIP/109-00000060{noformat} # Asterisk 15.2 sends an INVITE back to the ATA after receiving the ACK, but Asterisk 14.6 does not (because it has begun the fax transmission by this point). {noformat}[Feb  5 17:39:01] DEBUG[10811]: res_pjsip_session.c:1664 ast_sip_session_refresh: Sending session refresh SDP via re-INVITE to 109{noformat}
Comments:	By: Asterisk Team (asteriskteam) 2018-02-05 12:48:34.843-0600 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: George Joseph (gjoseph) 2018-02-07 08:50:54.065-0600 Can you attach the pcap? By: Jared Hull (fortytwo) 2018-02-07 09:38:27.004-0600 If you notice Asterisk sending a no-signal indicator before the 200 OK, that is a simple patch I made to punch a hole in NAT on the t38 port. I have compiled asterisk without that patch and there was no effect. I've also attached the pcap from my Asterisk 14.6 setup. By: Richard Mudgett (rmudgett) 2018-02-07 17:43:34.434-0600 Reattached t38.log as [^t38_log.txt] so we are not forced to download the file.  This is per issue guidelines \[1]. \[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Richard Mudgett (rmudgett) 2018-02-12 14:44:46.285-0600 We'll need the configurations you used to setup this call scenario to try and duplicate the issue.  Such as res_fax.conf, pjsip.conf for endpoint 109 and the outgoing leg with secrets removed of course. By: Jared Hull (fortytwo) 2018-02-12 16:45:35.965-0600 Attached res_fax and pjsip.conf for the endpoint I have tested both 14.6 and 15.2 with the same dialplan, asterisk configuration files, spandsp-0.0.6 source code, and fresh CentOS7 environment. By: Jared Hull (fortytwo) 2018-03-23 17:24:33.030-0500 I've traced this all the way back to the 15.0.0-beta1, so the problem lies somewhere in the jump from 14.6 and 15 as far as I can tell. I applied this patch to releases < 15.2 to avoid crashing during testing ASTERISK-27364 By: Joshua C. Colp (jcolp) 2018-03-26 10:15:53.191-0500 I believe this is due to the work for streams under 15, which may have the regression in your specific scenario. Can you also upload the Asterisk logs of it working under 14.6? By: Jared Hull (fortytwo) 2018-03-26 11:12:14.143-0500 Attached a full asterisk log and pcap of a working fax call with the same setup using 14.6 By: Joshua C. Colp (jcolp) 2018-03-26 11:29:37.381-0500 The 14.6 log doesn't have the SIP trace inline, which is helpful in seeing precisely where/when stuff is happening easily. By: Jared Hull (fortytwo) 2018-03-26 11:56:49.005-0500 Attached Asterisk log with inline SIP logging. By: Joshua C. Colp (jcolp) 2018-03-26 12:05:22.901-0500 With the new information I don't think it was streams, I think it was actually: https://gerrit.asterisk.org/#/c/6012/ The retransmission of the T.38 re-invite is causing that logic to get executed, triggering a rejection of T.38 which cascades into a failure. By: Joshua C. Colp (jcolp) 2018-03-26 13:26:19.264-0500 Are you able to remove the added logic from the review I mentioned and confirm that is the problem? If not I can prepare a patch to do so, so we can confirm it is indeed that. By: Jared Hull (fortytwo) 2018-03-26 14:03:17.638-0500 Recompiled 15.3 with that commit reverted, and it worked! I will do some more fax testing to ensure nothing else is effected. By: Jared Hull (fortytwo) 2018-03-26 15:50:45.107-0500 Everything is working as expected. By: Luke Escude (lukeescude) 2018-06-12 17:37:50.173-0500 Any updates on this issue? We can't upgrade to 15 until t.38 is working. Thanks! By: Joshua C. Colp (jcolp) 2018-06-12 19:12:49.712-0500 Any updates will be posted on this issue. There is no need to ask for one. By: Richard Mudgett (rmudgett) 2018-07-05 15:26:10.012-0500 Asterisk and testsuite patches up on gerrit. By: Friendly Automation (friendly-automation) 2018-07-10 06:56:14.809-0500 Change 9333 merged by Joshua Colp: res_pjsip_t38.c: Be smarter about how we respond when T.38 is disabled. [https://gerrit.asterisk.org/9333|https://gerrit.asterisk.org/9333] By: Friendly Automation (friendly-automation) 2018-07-10 07:23:03.442-0500 Change 9335 merged by Joshua Colp: res_pjsip_t38.c: Be smarter about how we respond when T.38 is disabled. [https://gerrit.asterisk.org/9335|https://gerrit.asterisk.org/9335] By: Friendly Automation (friendly-automation) 2018-07-10 07:23:32.558-0500 Change 9334 merged by Joshua Colp: res_pjsip_t38.c: Be smarter about how we respond when T.38 is disabled. [https://gerrit.asterisk.org/9334|https://gerrit.asterisk.org/9334]