[asterisk-bugs] [JIRA] Updated: (ASTERISK-17475) CNG or T.38 invite detected while call is bridged causes dialplan execution to stop after ReceiveFax

[Jay Reeder (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Reeder updated ASTERISK-17475:
----------------------------------

    Attachment: chan_sip.patch

patch file for asterisk version 1.8.14.1

> CNG or T.38 invite detected while call is bridged causes dialplan execution to stop after ReceiveFax
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-17475
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17475
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 1.6.2.15
>            Reporter: Jay Reeder
>            Assignee: Jay Reeder
>         Attachments: chan_sip.patch
>
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira