[asterisk-dev] [Code Review] 2475: Fix SIP Notify / BLF Stop Working, after packet loss and 10 retries
Alec Davis
reviewboard at asterisk.org
Sat Apr 27 03:51:44 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2475/
-----------------------------------------------------------
(Updated April 27, 2013, 8:51 a.m.)
Review request for Asterisk Developers.
Changes
-------
Added further comments in code.
Checked event packages "message-summary" MWI and "call-completion" CC for interlocks, they don't appear obvious.
Bugs: ASTERISK-21677
https://issues.asterisk.org/jira/browse/ASTERISK-21677
Repository: Asterisk
Description (updated)
-------
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 (updated)
-----
branches/1.8/channels/chan_sip.c 380212
Diff: https://reviewboard.asterisk.org/r/2475/diff/
Testing (updated)
-------
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.
Thanks,
Alec Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130427/17fb69c0/attachment.htm>
More information about the asterisk-dev
mailing list