<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/1562/">https://reviewboard.asterisk.org/r/1562/</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 and wdoekes.</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;">Way back in the day, Asterisk sent a 100 Trying when receiving a register request, despite RFC 3261 stating:
8.2.6.1 Sending a Provisional Response

One largely non-method-specific guideline for the generation of
responses is that UASs SHOULD NOT issue a provisional response for a
non-INVITE request. Rather, UASs SHOULD generate a final response to
a non-INVITE request as soon as possible.

Someone initially tried to remove the 100 Trying in https://issues.asterisk.org/jira/browse/ASTERISK-9157, but cries of &quot;there might be phones that require this behavior!&quot; were made and YAUO (yet another useless option) was added to chan_sip. There is no conceivable way that someone would write code that requires a provisional 100 response to a REGISTER. It would be an absurd amount of going out of one&#39;s way to write broken code. Add to that the fact (as wdoekes points out on the mailing list) that the flag is set on the peer, not copied to the pvt, but checked on the pvt anyway--it hasn&#39;t even worked all these years.

Even better, fixing the code would lead to the same kind of username disclosure as the nat= debacle we are trying to clean up. This leads me to the happy conclusion that we should finally just rip this code out. This patch does that.</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;">It compiles.</pre>
  </td>
 </tr>
</table>




<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">(343161)</span></li>

 <li>/branches/1.8/channels/sip/include/sip.h <span style="color: grey">(343161)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/1562/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>




  </div>
 </body>
</html>