[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    [asterisk-dev] [Code Review] chan_sip: more accurate retransmissions
From:       "David Vossel" <dvossel () digium ! com>
Date:       2010-06-25 17:19:38
Message-ID: 20100625171938.3668.68276 () hotblack ! digium ! com
[Download RAW message or body]


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

Review request for Asterisk Developers and Russell Bryant.


Summary
-------

Yes, there is some red in this diff, ignore it I'll fix it.

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.


Diffs
-----

  /trunk/channels/chan_sip.c 272526 

Diff: https://reviewboard.asterisk.org/r/747/diff


Testing
-------

I tested it with sipp.  sipp sends and invite and nothing more.  I watch the 200oks \
get retransmitted and verify the retransmission times are correct.


Thanks,

David


-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


[prev in list] [next in list] [prev in thread] [next in thread]