[test-results] [Bamboo] Asterisk - 1.6.2 > Ubuntu Lucid (10.04) > #141 was SUCCESSFUL (with 81 tests). Change made by Russell Bryant.
Bamboo
bamboo at asterisk.org
Mon Jan 24 15:31:54 CST 2011
-----------------------------------------------------------------------
Asterisk - 1.6.2 > Ubuntu Lucid (10.04) > #141 was successful.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
All 2 jobs passed with 81 tests in total.
http://bamboo.asterisk.org/browse/AST162-LUCID-141/
--------------
Code Changes
--------------
Russell Bryant (303548):
>Merged revisions 303546 via svnmerge from
>https://origsvn.digium.com/svn/asterisk/branches/1.4
>
>........
> r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
>
> Fix channel redirect out of MeetMe() and other issues with channel softhangup.
>
> Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
> working properly. This issue includes a patch that resolves the issue by
> removing a call to ast_check_hangup() from app_meetme.c. I left that in my
> patch, as it doesn't need to be there. However, the rest of the patch fixes
> this problem with or without the change to app_meetme.
>
> The key difference between what happens before and after this patch is the
> effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
> ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
> sees this which causes it to exit as intended. Checking ast_check_hangup()
> caused app_meetme to exit earlier in the process, and the target of the
> redirect saw the condition where ast_read() returned NULL.
>
> Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
> solve the issue if another application did the same thing. There are also
> other edge cases where if an application finishes at the same time that a
> redirect happens, the target of the redirect will think that the channel hung
> up. So, I made some changes in pbx.c to resolve it at a deeper level. There
> are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
> abort the hangup process. My patch extends this to remove the END_OF_Q frame
> from the channel's read queue, making the "abort hangup" more complete. This
> same technique was used in every place where a softhangup flag was cleared.
>
> (closes issue #18585)
> Reported by: oej
> Tested by: oej, wedhorn, russell
>
> Review: https://reviewboard.asterisk.org/r/1082/
>........
>
--------------
Tests
--------------
Fixed Tests (1)
- AsteriskTestSuite: S/rfc2833 dtmf detect
--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20110124/8577adaf/attachment.htm>
More information about the Test-results
mailing list