[asterisk-commits] dvossel: trunk r272557 - /trunk/channels/chan_sip.c

[SVN commits to the Asterisk project]

Author: dvossel
Date: Fri Jun 25 14:39:53 2010
New Revision: 272557

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=272557
Log:
chan_sip: more accurate retransmissions

RFC3261 states that Timer A should start at 500ms (T1) by default.
In chan_sip this value initially started at 1000ms and I changed
it to 500ms recently. After doing that I noticed in my packet
captures that it still occasionally retransmitted starting at
1000ms instead of 500ms like I told it to.  This occurs because
the scheduler runs in the do_monitor thread.  If a new retransmission
is added while the do_monitor thread is sleeping then it may not
detect that retransmission for nearly 1000ms.  To fix this I just
poke the do_monitor thread to wake up when a new packet is sent
reliably requiring retransmits.  The thread then detects the new
scheduler entry and adjusts its sleep time to account for it.

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


Modified:
    trunk/channels/chan_sip.c

Modified: trunk/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/trunk/channels/chan_sip.c?view=diff&rev=272557&r1=272556&r2=272557
==============================================================================
--- trunk/channels/chan_sip.c (original)
+++ trunk/channels/chan_sip.c Fri Jun 25 14:39:53 2010
@@ -3493,6 +3493,11 @@
 		ast_free(pkt);
 		return AST_FAILURE;
 	} else {
+		/* This is odd, but since the retrans timer starts at 500ms and the do_monitor thread
+		 * only wakes up every 1000ms by default, we have to poke the thread here to make
+		 * sure it successfully detects this must be retransmitted in less time than
+		 * it usually sleeps for. Otherwise it might not retransmit this packet for 1000ms. */
+		pthread_kill(monitor_thread, SIGURG);
 		return AST_SUCCESS;
 	}
 }