[asterisk-commits] alecdavis: trunk r387885 - in /trunk: ./ channels/chan_sip.c

[SVN commits to the Asterisk project]

Author: alecdavis
Date: Wed May  8 02:21:09 2013
New Revision: 387885

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=387885
Log:
chan_sip: NOTIFYs for BLF start queuing up and fail to be sent out after retries fail

RFC6665 4.2.2: ... after a failed NOTIFY transaction remove the subscription

The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.

The solution, follow RFC 6665 4.2.2.2's 'SHOULD' and remove the subscription after failure.
  
(closes issue ASTERISK-21677)

Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)

Review https://reviewboard.asterisk.org/r/2475/
........

Merged revisions 387875 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387880 from http://svn.asterisk.org/svn/asterisk/branches/11

Modified:
    trunk/   (props changed)
    trunk/channels/chan_sip.c

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-11-merged' - no diff available.

Modified: trunk/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/trunk/channels/chan_sip.c?view=diff&rev=387885&r1=387884&r2=387885
==============================================================================
--- trunk/channels/chan_sip.c (original)
+++ trunk/channels/chan_sip.c Wed May  8 02:21:09 2013
@@ -14805,7 +14805,20 @@
 
 	p->pendinginvite = p->ocseq;	/* Remember that we have a pending NOTIFY in order not to confuse the NOTIFY subsystem */
 
-	return send_request(p, &req, XMIT_RELIABLE, p->ocseq);
+	/* Send as XMIT_CRITICAL as we may never receive a 200 OK Response which clears p->pendinginvite.
+	 *
+	 * extensionstate_update() uses p->pendinginvite for queuing control.
+	 * Updates stall if pendinginvite <> 0.
+	 *
+	 * The most appropriate solution is to remove the subscription when the NOTIFY transaction fails.
+	 * The client will re-subscribe after restarting or maxexpiry timeout.
+	 */
+
+	/* 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.
+	 */
+	return send_request(p, &req, XMIT_CRITICAL, p->ocseq);
 }
 
 /*! \brief Notify user of messages waiting in voicemail (RFC3842)