Summary:	ASTERISK-26432: chan_dahdi: hangup during long TDD sendtext not detected, blocking channel
Reporter:	Nicolas Chapleau (nicchap)	Labels:
Date Opened:	2016-10-03 09:06:31	Date Closed:
Priority:	Major	Regression?	Yes
Status:	Open/New	Components:	Channels/chan_dahdi
Versions:	13.11.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 6.5 libpri 1.5.0 Dahdi 2.11.1 Asterisk 13.11.2 wanpipe 7.0.19 8 DMS100 PRIs on Sangoma A108DE cards	Attachments:	( 0) chan_dahdi.c.sendtext.13.15.1.patch ( 1) chan_dahdi.c.sendtext-13.15.1.patch
Description:	(peusdo) answer() setTDD ( on ) sendText( "Put a long message to play back on the customers TTY device" ) When a hangup occurs during the sendtext, I can see the PRI_EVENT_HANGUP_REQ on my PRI span but it is not processed until the sendtext command completes. I have debugged the sendtext command and I see it complete tdd_generate then loop (chan_dahdi.c line 13435) to write the tones while checking for hangup (line 13436), which is NOT detected. Meanwhile, new calls coming into that span get rejected until the sendtext completes, after which I get PRI MDL (f) errors. On busy systems, it will also cause Exceptionally long frame queuing error messages. I can easily recreate this by hanging up during the sendtext command and calling back right away. This issue has blocked us from upgrading from 1.4.43 where it does not happen. For now I put a temporary fix in our script to send TDD text one letter at a time which helps but not having sendtext block the span on hangup.
Comments:	By: Asterisk Team (asteriskteam) 2016-10-03 09:06:32.232-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: Richard Mudgett (rmudgett) 2016-10-04 12:38:37.810-0500 The {{chan_dahdi.c:dahdi_sendtext()}} has a simplistic polling loop that doesn't process received frames.  Thus the queued AST_CONTROL_HANGUP frame from PRI does not get processed. By: Nicolas Chapleau (nicchap) 2017-05-17 08:02:18.212-0500 Do you think re-writing that polling loop would fix this issue? Just want to know prior to going deeper into code. By: Richard Mudgett (rmudgett) 2017-05-17 09:50:20.594-0500 Yes that should fix the issue.  The polling loop needs to defer frames like a channel in autoservice (autoservice.c) while looking for the AST_CONTROL_HANGUP frame.  If it sees the hangup frame it needs to exit the loop and requeue any deferred frames.  Also the channel is locked on entry to that function so you will need to unlock it while waiting in poll() so other code won't get blocked waiting for the lock unnecessarily. By: Nicolas Chapleau (nicchap) 2017-05-22 18:18:44.456-0500 Patch adding HANGUP detection in dahdi_sendtext. By: Nicolas Chapleau (nicchap) 2017-05-22 18:20:10.918-0500 Thanks Richard, surprisingly enough your short explanation really helped me out. I have added the hangup detection code in dahdi_sendtext and have tested it successfully on our servers. Notice that I only defer the HANGUP frame and no other deferrable frames, since we are sending text, the other end should not really be sending anything anyways. The patch was run against version 13.15.1. Feel free to take credit or change the code any way you want. I have signed all documents to submit code. By: Nicolas Chapleau (nicchap) 2017-05-23 11:34:24.555-0500 Quick update on previously submitted patch. Forgot to free discarded frames.