<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/4273/">https://reviewboard.asterisk.org/r/4273/</a>
     </td>
    </tr>
   </table>
   <br />




<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Mark Michelson.</div>










<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</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;">Consider a situation where Asterisk is configured to register with a remote server, and the configuration specifies bad authentication credentials. If the remote server always responds to Asterisk's registration attempts with 401 responses (each with a new nonce), then Asterisk will continue to immediately send new registrations. Though this loop can be broken by correcting the authentication credentials used for the outbound registrations, it is a nuissance to be continuously throwing registrations out and never stopping.

With this change, the registration state is altered to take into account if we have already attempted authentication. If we have, and we receive another 401/407 response, we will not re-attempt authentication. Instead, we will fall through and treat the response as a registration failure. From there, the usual logic regarding registration failures takes place.</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;">I used a SIPp scenario to emulate a registration server that always responds to REGISTER requests with a 401 response. Without this patch, Asterisk would continuously send new REGISTER requests when met with a 401 response. With this patch, Asterisk sends its initial REGISTER, then retries with authentication once, and then does not re-attempt with authentication any longer. With auth_rejection_permananent enabled, Asterisk completely stops attempting to register. With auth_rejection_permanent disabled, then Asterisk waits the retry_interval before re-attempting to REGISTER, and the cycle repeats.

I have also created a test on /r/4274 that ensures that this fix works as expected.</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/13/res/res_pjsip_outbound_registration.c <span style="color: grey">(429672)</span></li>

</ul>

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







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




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