Summary:	ASTERISK-17217: [patch] race condition in setting local capabilities for Setup when fastStart is enabled
Reporter:	under (under)	Labels:
Date Opened:	2011-01-09 13:57:01.000-0600	Date Closed:	2014-08-12 11:20:28
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_h323
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 12251.diff ( 1) fail.log ( 2) ok.log
Description:	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.
Comments:	By: under (under) 2011-01-09 14:15:47.000-0600 in the attached patch error logging of this case is enabled and actual fix is implemented. By: under (under) 2011-01-10 05:52:31.000-0600 forgot to mention, this issue is relevant to all asterisk versions. By: Matt Jordan (mjordan) 2014-08-12 11:20:22.747-0500 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.