[asterisk-bugs] [JIRA] (ASTERISK-17217) [patch] race condition in setting local capabilities for Setup when fastStart is enabled

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-17217:
----------------------------------------

Unfortunately, {{chan_h323}} has been unsupported for a long time and was marked deprecated. Due to there being a supported replacement channel driver, {{chan_ooh323}}, {{chan_h323}} was removed from the Asterisk source tree in Asterisk 13:

http://lists.digium.com/pipermail/asterisk-dev/2014-June/068363.html

As such, this issue will be closed out as "Won't Fix". I recognize that this issue has been open for a long time, and as a project, we're sorry that the patch attached this issue didn't receive more attention. We've made some changes in the way the patch process works to try and alleviate the issue of patches not receiving attention; for more information, see [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process] on the Asterisk wiki. If you still need H323 support and are using Asterisk, I'd recommend switching to {{chan_ooh323}}, as it has a dedicated module maintainer who can help with patches to that channel driver.

> [patch] race condition in setting local capabilities for Setup when fastStart is enabled
> ----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-17217
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17217
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_h323
>            Reporter: under
>            Severity: Minor
>         Attachments: 12251.diff, fail.log, ok.log
>
>
> When fastStart is enabled, terminal capabilities (supported codecs/dtmf modes) should be sent in Setup to remote peer. But sometimes they are not set and Setup is sent empty. This leads to voice path is not created (remote peer doesn't know what are our capabilities). Some equipment drop this call immediately.
> This happens due to race condition.
> Sometimes "oh323_pvt.cd.call_token" is set AFTER openh323 "asks" chan_h323 for local capabilities (because it "asks" in separate thread from the one where MyMakeCall() is invoked).
> And therefore, when openh323 "asks" for local capabilities, chan_h323 is unable to find "oh323_pvt" structure in set_local_capabilities() by call reference and call_token, because call_token was not set yet (it happens in different thread, as I already wrote).
> However "oh323_pvt.cd.call_reference" is set ok, because it's set under H323Connection::Lock().
> Same logic should be used for "call_token" to prevent race condition.
> ****** ADDITIONAL INFORMATION ******
> This issue didn't reproduce when I used Asterisk on freeBSD. Started to reproduce when I started using Gentoo Linux. This issue is likely to be timing and hardware dependent.



--
This message was sent by Atlassian JIRA
(v6.2#6252)