Review Board 1.7.16

NOTIFYs for BLF start queuing up and fail to be sent out after retries fail

Review Request #2475 - Created April 25, 2013 and submitted

Alec Davis
1.8 to trunk
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.

As per bug report

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.
Review request changed
Updated (May 8, 2013, 3:23 p.m.)
  • changed from pending to submitted
Committed in revision 387885 runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to