From: Steve Murphy Date: Thu, 25 Sep 2008 16:12:14 +0000 (+0000) Subject: (closes issue #12101) X-Git-Tag: 1.4.23-rc1~70 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8524d212f68204eeb7ca092137a9befe55cee1b2;p=thirdparty%2Fasterisk.git (closes issue #12101) Reported by: MVF Tested by: neutrino88, urzedo, murf, thiagofernandes Many thanks to neutrino88 for this patch, which solves a problem whereby channels get a CANCEL request, respond to it properly, but end up in a hung state, infinitely being rescheduled. This fix is a bit crude, in that catches the problem at a rather late phase, but it may prevent infinite rescheduling problems that might still arise. It might have been better to find out why, in the course of protocol handling, the channel was not destroyed, but we leave that to future generations. Many thanks to urzedo and thiagofernandes for their work in verifying that the patch code indeed is being executing, and averting the problem. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144420 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- diff --git a/channels/chan_sip.c b/channels/chan_sip.c index 5ffa8a166b..1449434429 100644 --- a/channels/chan_sip.c +++ b/channels/chan_sip.c @@ -2092,10 +2092,17 @@ static int __sip_autodestruct(const void *data) } /* If there are packets still waiting for delivery, delay the destruction */ - if (p->packets) { + /* via bug 12101, the two usages of SIP_NEEDDESTROY in the following block + * of code make a sort of "safety relief valve", that allows sip channels + * that were created via INVITE, then thru some sequence were CANCELED, + * to die, rather than infinitely be rescheduled */ + if (p->packets && !ast_test_flag(&p->flags[0], SIP_NEEDDESTROY)) { if (option_debug > 2) ast_log(LOG_DEBUG, "Re-scheduled destruction of SIP call %s\n", p->callid ? p->callid : ""); append_history(p, "ReliableXmit", "timeout"); + if (p->method == SIP_CANCEL || p->method == SIP_BYE) { + ast_set_flag(&p->flags[0], SIP_NEEDDESTROY); + } return 10000; }