Summary:	ASTERISK-17475: CNG or T.38 invite detected while call is bridged causes dialplan execution to stop after ReceiveFax
Reporter:	Jay Reeder (escape2mtns)	Labels:
Date Opened:	2011-02-24 14:45:26.000-0600	Date Closed:
Priority:	Major	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/T.38
Versions:	1.6.2.15 13.18.4	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.patch
Description:	We have calls that come in via SIP and are immediately routed out Dahdi PRI to a voice platform.  The call is answered by the Dial() function before bridging.  In cases where CNG or T.38 invite is detected after the call is bridged, the bridge is broken, the hangup extension is executed, and then the fax extension is executed.  When executing the fax extension, after the fax is received, ReceiveFax recognizes that the call has hung up and upon exiting should go to the hangup extension for post-fax processing.  Instead, the dialplan execution stops and we have no ability to perform fax reception processing (email fax or process with a script) because the dialplan never gets executed after the ReceiveFax. ****** ADDITIONAL INFORMATION ****** I was able to resolve this issue by inserting the following just before the redirect to fax in chan_sip.c where CNG is detected:        ast_channel_lock(ast);        ast_set_flag(ast, AST_FLAG_BRIDGE_HANGUP_DONT);        ast_channel_unlock(ast); and by inserting the following just before the redirect to fax in chan_sip.c where T.38 invite is detected:              ast_channel_lock(p->owner);              ast_set_flag(p->owner, AST_FLAG_BRIDGE_HANGUP_DONT);              ast_channel_unlock(p->owner); Those flags prevent the hangup extension from being called when the bridge is broken, which allows proper processing of the fax extension so that we can process the fax after it is received successfully. Actual version is 1.6.2.17-rc3 but we had the same issues on 1.6.2.6.
Comments:	By: Matt Jordan (mjordan) 2012-09-05 08:51:28.822-0500 I inspected the 1.8+ code for chan_sip and it doesn't look like your fix ever got inserted into chan_sip. Would you mind providing a patch for 1.8 and attaching it to this issue?  If possible, I'd like to get this fixed for later versions of Asterisk. By: Jay Reeder (escape2mtns) 2012-09-09 17:46:57.738-0500 patch file for asterisk version 1.8.14.1 By: Jay Reeder (escape2mtns) 2012-09-09 17:51:53.862-0500 I've attached the patch file per request.  This is only a couple of lines of code, but the patch likely isn't in-line with coding requirements (it includes comments we made so that we could find the code changes).