<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 />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">{quote}
From: asterisk-dev lists mail by Walter Doekes
I recently patched one of my (opensips) presence servers to *not* expire the subscription after a few unanswered notify's.
Temporary network issues (probably unpunctured NAT) made subsequent NOTIFYs not go out because the presence server had dropped the subscription. And then the subscribers were (rightly) wondering why they were not getting new notifies while nearby devices were getting theirs.
{quote}
With the above in mind, I can see a way forward;
new int required 'failed_transactions_count'
in the notify response 200OK:
reset failed_transactions_count
after the 10 packet retransmissions fail:
increment failed_transactions_count
if count < some value (3)
clear pendinginvite (this unlocks the network interlock we're experiencing)
else
remove subscription
Not strictly the RFC compliant, but wasn't in the first place, but makes us tolerant.
The outcome after network connectivity is fixed:
For 1.8 to trunk, if the subscription expiry had *NOT* elapsed, the BLF would come right on the next State Notify event trigger.
For 11 and above;
When [re-]subscribing, the BLF will update correctly, as State Notify as sent every [re-]subscribe.
But for 1.8;
After a re-subscribe, the BLF may still be wrong, as 1.8 doesn't send a State Notify after a re-subscribe (the subscription still exists as we not have had enough errors).
After a subscribe the BLF will update correctly. Subscription doesn't exist, due to previous failed_transactions > some value, expired, device rebooted, etc.
</pre>
<br />
<p>- Alec</p>
<br />
<p>On May 6th, 2013, 8:40 p.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 May 6, 2013, 8:40 p.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 subsystem relies on a NOTIFY 200OK response to clear the SIP_PAGE2_STATECHANGEQUEUE flag and p->pendinginvite.
If the response never arrives, then any further NOTIFYs cannot EVER be sent, they just 'queue' up by replacing the previous queued notify.
The fix: Follow RFC6665 4.2.2 more closely, after failed NOTIFY transaction remove the subscription.
Then after a period of time the client will (re-)subscribe, which will create a new subscription.
For minimum BLF 'not working' time maxexpiry in sip.conf needs to be around 300, not the default of 3600 seconds.
</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 https://issues.asterisk.org/jira/browse/ASTERISK-21677
Asterisk 1.8, subscribers will NOT update their status when they re-subscribe, but will on the next event.
Asterisk 11, subscribers WILL update their status when they re-subscribes.
Reporter of ASTERISK-21677 has also tested on a number of production servers.</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">(380212)</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>