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





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On April 25th, 2013, 7:43 a.m. UTC, <b>Olle E Johansson</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;">RFC 6665 is very clear that if we fail (after a couple of retries) then the subscription should be removed. The client should resubscribe. SIP has retransmissions to handle packet loss and retries.

The subscription does not become invalid because of ONE dropped response.

Now, if we have MWI NOTIFY without subscriptions we may need a way to restart. But not with subscriptions.</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;">Agreed 2 seconds would fail before any retries, 30 seconds would have been more appropriate.

I should have read the RFC first, it&#39;s a SHOULD though, not a MUST.

RFC6665 4.2.2.  Sending State Information to Subscribers
&quot;If the NOTIFY request fails due to expiration of SIP Timer F (transaction timeout), the notifier SHOULD remove the subscription.&quot;
      
&quot;     Upon client restart or reestablishment of a network connection, it is
      expected that clients will send SUBSCRIBE requests to refresh
      potentially stale state information; such requests will reinstall
      subscriptions in all relevant nodes.&quot;

The above seems flawed, how will a client know the network in the middle was down, that they missed any requests, and thus need to SUBSCRIBE again?
If the subscription expires time is short enough, 5 minutes, then OK the BLF may be incorrect for upto 5 minutes. 

As we currently don&#39;t remove the subscription after 10 retries we&#39;re working with SHOULD, it&#39;s ok for it to stay.

So perhaps I need to clear the SIP_PAGE2_STATECHANGEQUEUE and pendinginvite after all of the retries, or set a flag back in the subscription indicating a failed transaction.

Or change my proposed timeout to 30 seconds.


</pre>
<br />










<p>- Alec</p>


<br />
<p>On April 25th, 2013, 7:35 a.m. UTC, Alec Davis wrote:</p>








<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.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Alec Davis.</div>


<p style="color: grey;"><i>Updated April 25, 2013, 7:35 a.m.</i></p>







<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-21677">ASTERISK-21677</a>


</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;">The notify sub system relies on a NOTIFY 200OK response to come back to clear the SIP_PAGE2_STATECHANGEQUEUE flag and p-&gt;pendinginvite
If the response never arrives, then any future NOTIFYs cannot EVER be sent, they just &#39;queue&#39; up by replacing the previous queued notify.

The fix: assume after a period of time (2 seconds), if we haven&#39;t had a response, that the request/response got lost.


  </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;">as per bug report  ASTERISK-21677</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/11/channels/chan_sip.c <span style="color: grey">(386529)</span></li>

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

</ul>

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







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








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