<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1672/">https://reviewboard.asterisk.org/r/1672/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, Joshua Colp, Mark Michelson, and Olle E Johansson.</div>
<div>By Terry Wilson.</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">When handle 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 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 currently relies on the hangup calling sip_scheddestroy. I couldn't think of a reason why we wouldn't have a channel and be able to hang up in these cases. I'm leaning toward adding a sip_scheddestroy_final() to each of the applicable cases just to be sure, but I'm not 100% sure it is necessary...
For more information, see section 17.1.1.1 of RFC 3261.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested various 4xx responses with sipp and verified that channels went away, but the sip transaction stayed up and we re-send ACK on retransmitted non-2xx INVITE responses.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-17717">ASTERISK-17717</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/channels/chan_sip.c <span style="color: grey">(350414)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1672/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>