Ensure ACK retransmit & hangup on non-200 response to INVITE
authorTerry Wilson <twilson@digium.com>
Mon, 16 Jan 2012 21:50:10 +0000 (21:50 +0000)
committerTerry Wilson <twilson@digium.com>
Mon, 16 Jan 2012 21:50:10 +0000 (21:50 +0000)
commitaacc158072bbbc609363404cc4689284a1b6ce8f
tree93f45b1c934ba300c37ce009dd4a2a45d27c291c
parentfb5924ebe8104a9a5d95d6d1f2f6df41874ab93b
Ensure ACK retransmit & hangup on non-200 response to INVITE

When handling a non-2xx final response on an INVITE transaction, we have to
keep the transaction around after we send an ACK in case we receive a
retransmission of the response so we can re-transmit the ACK, but also tear
down the ast_channel as soon as we transmit the ACK. Before this patch, we
could fail at both of these things. Calling sip_alreadygone/needdestroy
prevented us from keeping the transaction up and retransmitting the ACK, and
queueing CONGESTION was not sufficient to cause the channel to be torn down
when originating calls via the CLI, for example.

This patch queues a hangup with CONGESTION instead of just queueing CONGESTION
for these responses and removes the sip_alreadygone and sip_needdestroy calls
from handle_response_invite on non-2xx responses. It relies on the hangup
calling sip_scheddestroy.

For more information, see section 17.1.1.1 of RFC 3261.

(closes issue ASTERISK-17717)
Review: https://reviewboard.asterisk.org/r/1672/
........

Merged revisions 351130 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 351131 from http://svn.asterisk.org/svn/asterisk/branches/10

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_sip.c