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

[Alec Davis]

> On April 25, 2013, 7:43 a.m., Olle E Johansson wrote:
> > RFC 6665 is very clear that if we fail (after a couple of retries) then the subscription should be removed. The client should resubscribe. SIP has retransmissions to handle packet loss and retries.
> > 
> > The subscription does not become invalid because of ONE dropped response.
> > 
> > Now, if we have MWI NOTIFY without subscriptions we may need a way to restart. But not with subscriptions.

Agreed 2 seconds would fail before any retries, 30 seconds would have been more appropriate.

I should have read the RFC first, it's a SHOULD though, not a MUST.

RFC6665 4.2.2.  Sending State Information to Subscribers
"If the NOTIFY request fails due to expiration of SIP Timer F (transaction timeout), the notifier SHOULD remove the subscription."
      
"     Upon client restart or reestablishment of a network connection, it is
      expected that clients will send SUBSCRIBE requests to refresh
      potentially stale state information; such requests will reinstall
      subscriptions in all relevant nodes."

The above seems flawed, how will a client know the network in the middle was down, that they missed any requests, and thus need to SUBSCRIBE again?
If the subscription expires time is short enough, 5 minutes, then OK the BLF may be incorrect for upto 5 minutes. 

As we currently don't remove the subscription after 10 retries we're working with SHOULD, it's ok for it to stay.

So perhaps I need to clear the SIP_PAGE2_STATECHANGEQUEUE and pendinginvite after all of the retries, or set a flag back in the subscription indicating a failed transaction.

Or change my proposed timeout to 30 seconds.


- Alec


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


On April 25, 2013, 7:35 a.m., Alec Davis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2475/
> -----------------------------------------------------------
> 
> (Updated April 25, 2013, 7:35 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21677
>     https://issues.asterisk.org/jira/browse/ASTERISK-21677
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The notify sub system 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: assume after a period of time (2 seconds), if we haven't had a response, that the request/response got lost.
> 
> 
>   
> 
> 
> Diffs
> -----
> 
>   branches/11/channels/chan_sip.c 386529 
>   branches/11/channels/sip/include/sip.h 386529 
> 
> Diff: https://reviewboard.asterisk.org/r/2475/diff/
> 
> 
> Testing
> -------
> 
> as per bug report  ASTERISK-21677
> 
> 
> Thanks,
> 
> Alec Davis
> 
>

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