<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/2222/">https://reviewboard.asterisk.org/r/2222/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On December 4th, 2012, 5:21 p.m., <b>Mark Michelson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">First off, the changes you have regarding the use of a named constant instead of magic numbers are great, as is the change you made regarding the setting of the cached Min-SE.
The other parts seem off.
The test you have created is not valid. If Asterisk is set to "accept" mode, then it should not be putting any sort of session-timers headers in the initial INVITE. If it's not sending any session-timer headers in the INVITE, then it doesn't make sense that the endpoint would respond with a 422 since there was no proposed session interval. If we do go up against an endpoint that sends us a 422 when we haven't proposed session timers, then I'm really not sure how we should react to that, to be honest. Since they should be proposing a Min-SE in their 422, we could potentially respond with some sort of Session Timer proposal, but that would violate the local policy of what "accept" means. I think that if we receive a 422 when we're in "accept" mode, then we're clearly dealing with a broken implementation and should not attempt to renegotiate.
The change you have put in now can result in placing a Min-SE header but no Session-Expires header in the initial INVITE when in "accept" mode, which is less than ideal.
</pre>
</blockquote>
<p>On December 5th, 2012, 8:45 a.m., <b>opticron</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">When in "accept" mode, Asterisk offers "timer" in the Supported header. This allows intermediate proxies to place a Session-Expires header in the invite or to reduce the value thereof according to RFC 4028. Later proxies or the final recipient of the message can then respond with a 422 specifying a Min-SE header which Asterisk will be required to include in all further attempts.
I agree that Asterisk should not be placing a Min-SE or Session-Expires in the initial invite when in "accept" mode. The test for including that needs a little tweaking.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Actually, including a Min-SE in the initial invite when in "accept" mode could prevent the situation where we receive a 200 OK with an unacceptably low Session-Expires (according to peer configuration) and need to tear down the call after the fact (which doesn't currently happen, see ASTERISK-20653). The end result would be acceptance of a call that does not conform to the configuration of the peer. If/When ASTERISK-20653 gets fixed, this situation becomes less of an issue since the call can be torn down as expected.</pre>
<br />
<p>- opticron</p>
<br />
<p>On November 30th, 2012, 4:26 p.m., opticron wrote:</p>
<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.</div>
<div>By opticron.</div>
<p style="color: grey;"><i>Updated Nov. 30, 2012, 4:26 p.m.</i></p>
<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;">RFC 4028 states that if a 422 response is ever received during a session refresh or during a call attempt (and the UAC wishes to retry), the all subsequent attempts or refreshes must have a Min-SE header. Asterisk does not currently do this if operating in the "accept" mode. This patch corrects this behavior and swaps out a few magic numbers for a pre-existing constant.
This was discovered when writing the test for https://reviewboard.asterisk.org/r/2223/</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;">Before this patch, the test in https://reviewboard.asterisk.org/r/2223/ failed. After the patch, it passes.</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/SWP-5051">SWP-5051</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">(376948)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2222/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>