[asterisk-dev] [Code Review] 2475: Fix SIP Notify / BLF Stop Working, after packet loss and 10 retries

[Alec Davis]

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

(Updated April 26, 2013, 9:58 a.m.)


Review request for Asterisk Developers.


Changes
-------

Instead of duplicating code in retrans_pkt, and potentially breaking other notifiers.

Only in transmit_state_notify() change the send_request() to XMIT_CRITICAL instead of XMIT_RELIABLE.
This meets RFC6665 requirement to remove subscription on failed transaction after retires.


Bugs: ASTERISK-21677
    https://issues.asterisk.org/jira/browse/ASTERISK-21677


Repository: Asterisk


Description
-------

The notify subsystem relies on a NOTIFY 200OK response to come back to clear the SIP_PAGE2_STATECHANGEQUEUE flag and p->pendinginvite.
If the response never arrives, then any future 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
-------

as per bug report  ASTERISK-21677

Asterisk 1.8 will NOT update it's status when the client re-subscribes, but will on the next event.
Asterisk 11, WILL update it's status when the client re-subscribes.


Thanks,

Alec Davis

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