[asterisk-dev] [Code Review] 2475: NOTIFYs for BLF start queuing up and fail to be sent out after retries fail

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2475/#review8455
-----------------------------------------------------------

Ship it!


I'll quote Alec from #asterisk-dev here, as he provided a good explanation as to why this change is needed:

{quote}
(03:58:13 PM) alecdavis: @mjordan, yes the discussion you refer to, is grandstream specific, where the grandstream accepts a uncolicited NOTIFY after a rebbot from a stale subscription. But most of the times the phone has been rebooted would have been because 'a' BLF had stopped working. Which then lead in to the specific 'stale version no' issue on the grandstream.
(04:02:01 PM) alecdavis: @mjordan, review2475 after a failed NOTIFY transaction (due to a network event), removes the subscription, as the RFC says it 'SHOULD'. The phone resubscribes in it's own time, and the BLF magically starts working again. then
(04:05:11 PM) alecdavis: and the reporter has just reported that his devices are not on a LAN but are internet connected, so network outage probability is high.
(04:07:18 PM) alecdavis: the BLF fix, is a simple 1 word change, XMIT_RELIABLE changed to XMIT_CRITICAL, thus the subsription gets removed after it fails.
{quote}

- Matt Jordan


On May 6, 2013, 8:40 p.m., Alec Davis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2475/
> -----------------------------------------------------------
> 
> (Updated May 6, 2013, 8:40 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21677
>     https://issues.asterisk.org/jira/browse/ASTERISK-21677
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   branches/1.8/channels/chan_sip.c 380212 
> 
> Diff: https://reviewboard.asterisk.org/r/2475/diff/
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> Thanks,
> 
> Alec Davis
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130506/b5c16e83/attachment.htm>