Summary:	ASTERISK-28473: res_pjsip_t38: Crash on Asterisk 16.4
Reporter:	Joshua Elson (joshelson)	Labels:	fax
Date Opened:	2019-07-08 12:47:11	Date Closed:	2019-09-18 14:38:03
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip_t38
Versions:	16.4.0	Frequency of Occurrence	Frequent
Related Issues:	is related to ASTERISK-28495 res_pjsip_t38: 200 OK with SDP answer with declined stream causes crash
Environment:		Attachments:	( 0) asterisk-core-20190708-092625-brief.txt ( 1) asterisk-core-20190708-092625-full.txt ( 2) asterisk-core-20190708-092625-locks.txt ( 3) asterisk-core-20190708-092625-thread1.txt ( 4) HOMER5-45.32.207.203-4804996066-7_8_2019_9_25_49.pcap
Description:	This is likely related to ASTERISK-27944... but we're seeing our favorite T38 negotiation crash again. Still looking for a scenario to reproduce cleanly, but this appears to happen in an odd T38 negotiation failure.
Comments:	By: Asterisk Team (asteriskteam) 2019-07-08 12:47:12.234-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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua Elson (joshelson) 2019-07-08 12:47:40.990-0500 Backtrace attached. By: Joshua Elson (joshelson) 2019-07-08 13:29:15.940-0500 Got a scenario and a PCAP (attached here). This was originally an inbound call to Asterisk, which is forwarded out from Asterisk to carrier. On the forwarded leg, Asterisk sends a 488 to the T.38 re-invite from carrier, but then sends a T.38 reinvite itself. By: Kevin Harwell (kharwell) 2019-07-08 13:29:20.641-0500 The session_media object is NULL, so when it tries to de-reference it it crashes. Either it was not properly setup to begin with or was "reset". Can you also post the log from around the time of an occurrence? I'm hoping it'll have an error and/or warning message in it regarding the mentioned negotiation failure. By: Joshua Elson (joshelson) 2019-07-08 19:17:19.260-0500 So we are just showing ringing on the forwarded line in the log output before the negotiation attempt causes the crash. Nothing specifically regarding the T.38 negotiation failure in the logs themselves. We're working to see if we can repro it another way. By: Kevin Harwell (kharwell) 2019-07-09 13:15:08.717-0500 I'm a little confused by the pcap. Could you better explain your setup, scenario, and IP sources? And the flow of the general call with actors involved? Thanks! By: Joshua Elson (joshelson) 2019-07-09 13:24:47.436-0500 Yeah.. Apologies here. This is a little disjointed. Here's the explanation as best as we understand it: 1. A fax call comes inbound from an outside SIP carrier to us. 2. We initiate a MixMonitor and immediately send a Dial to a second carrier. 3. We get a T38 reinvite from the second carrier, which we 488. 4. We then initiate a T38 reinvite ourselves to second carrier, at which point (or somewhat soon thereafter) we crash. There technically should be two PCAPs, I believe we just provided a carrier proxy-level capture of the second. I can see if we can provide those a little closer to the Asterisk box if I can make that work. By: Kevin Harwell (kharwell) 2019-07-09 14:56:18.980-0500 Cool thanks that helps. I'm going to go ahead and open up this as an issue since Asterisk shouldn't be crashing in any scenario. Please add anymore details when they come up as it will help us narrow down the cause. By: Kevin Harwell (kharwell) 2019-07-09 14:59:02.243-0500 A couple of suggestions. 1. Sounds like it doesn't happen every time for the same scenario. Maybe compare the pcaps of a good vs bad run to see if anything stands out. 2. Same for the Asterisk logs. Compare a good vs bad run. Unfortunately of course once a crash occurs there is no more logging. Do however check the log file after each crash because depending on the timing (logs are written in a separate thread)more or less log statements might get written out. So maybe one of the times you might see a relevant error/warning in the log.