[asterisk-bugs] [JIRA] (ASTERISK-21207) Deadlock on fax extension calling ast_async_goto() with locked channel

Matt Jordan (JIRA) noreply at issues.asterisk.org
Tue Mar 12 09:58:01 CDT 2013


    [ https://issues.asterisk.org/jira/browse/ASTERISK-21207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204131#comment-204131 ] 

Matt Jordan edited comment on ASTERISK-21207 at 3/12/13 9:56 AM:
-----------------------------------------------------------------

The {{ast_async_goto}} in {{process_sdp}} is problematic. Queueing a DTMF frame on the channel won't uniquely fix it, as the fax detection is only performed on DTMF frames pulled out of the RTP layer.

I'm a little hesitant to do that, however, since that would mean we would try to trip off to the fax extension if anyone queued up a DTMF with an 'f' on it on the channel - which seems like it could be abused/confused.

One alternative would be to hijack the AST_CONTROL_T38_PARAMETERS control frame. We could add a new value onto {{ast_control_t38}} - AST_T38_GOTO_FAX - and queue that up on the channel safely. When that is passed back into {{sip_indicate}}, we could then safely bounce off to the fax extension.

What do you think of that solution? It's still an API change in a release branch (ew), but it may allow us to defer the {{ast_async_goto}} into a slightly safer portion of the code.
                
      was (Author: mjordan):
    The {{ast_async_goto}} in {{process_sdp}} is problematic. Queueing a DTMF frame on the channel won't uniquely fix it, as the fax detection is only performed on DTMF frames pulled out of the RTP layer.

I'm a little hesitant to do that, however, since that would mean we would try to trip off to the fax extension if anyone queued up a DTMF with an 'f' on it on the channel - which seems like it could be abused/confused.

One alternative would be to hijack the AST_CONTROL_T38_PARAMETERS control frame. We could add a new value onto {{ast_control_t38}} - AST_T38_GOTO_FAX - and queue that up on the channel safely. When that is passed back into {{sip_indicate}}, we could then safely bounce off to the fax extension.
                  
> Deadlock on fax extension calling ast_async_goto() with locked channel
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-21207
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21207
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi, Channels/chan_sip/General
>    Affects Versions: 10.7.1, 11.2.1
>         Environment: CentOS 6.3 x86_64
>            Reporter: Ashley Winters
>            Severity: Critical
>         Attachments: fax-deadlock.patch, gdb-fax-deadlock.txt
>
>
> On an asterisk system with heavy use of AGI and inbound CNG-detected faxing, occasionally all channel activity will freeze. Running 'core show channels' returns nothing, but the logs continue running with anything except channel activity. Running with 'sip set debug on' shows that chan_sip.c doesn't even claim to be reading packets anymore.
> This deadlock was triggered several times daily across our array of asterisk servers, which process hundreds of faxes and tens of thousands of calls daily.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list