<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 &quot;accept&quot; mode, then it should not be putting any sort of session-timers headers in the initial INVITE. If it&#39;s not sending any session-timer headers in the INVITE, then it doesn&#39;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&#39;t proposed session timers, then I&#39;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 &quot;accept&quot; means. I think that if we receive a 422 when we&#39;re in &quot;accept&quot; mode, then we&#39;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 &quot;accept&quot; 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 &quot;accept&quot; mode, Asterisk offers &quot;timer&quot; 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 &quot;accept&quot; mode.  The test for including that needs a little tweaking.</pre>
 </blockquote>





 <p>On December 5th, 2012, 9:25 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;">Actually, including a Min-SE in the initial invite when in &quot;accept&quot; 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&#39;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>
 </blockquote>





 <p>On December 12th, 2012, 10:27 a.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;">Okay, this makes sense. Having a Min-SE present with no proposed Session-Expires gives a &quot;hint&quot; to proxies and UAs in the path what they should propose as the Session-Expires as well.

The one thing I&#39;m not sure of is if Asterisk, as a UAS, will handle this correctly. Do we inspect Min-SE if there is no Session-Expires present? It doesn&#39;t appear that we do. We should open an issue to make sure we change Asterisk&#39;s UAS behavior to search for a Min-SE header even if Session-Expires is not present.</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;">Issue created: https://issues.asterisk.org/jira/browse/ASTERISK-20787</pre>
<br />








<p>- Mark</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 &quot;accept&quot; 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>