From: David Vossel Date: Fri, 25 Jun 2010 19:39:53 +0000 (+0000) Subject: chan_sip: more accurate retransmissions X-Git-Tag: 11.0.0-beta1~2774 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aa428b896782743b92f8e214f4235d7e07c041e3;p=thirdparty%2Fasterisk.git 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 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272557 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- diff --git a/channels/chan_sip.c b/channels/chan_sip.c index b3bf2cd017..5720f9b643 100644 --- a/channels/chan_sip.c +++ b/channels/chan_sip.c @@ -3493,6 +3493,11 @@ static enum sip_result __sip_reliable_xmit(struct sip_pvt *p, int seqno, int res 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; } }