[asterisk-dev] [Code Review] chan_sip: more accurate retransmissions
Mark Michelson
mmichelson at digium.com
Fri Jun 25 12:46:02 CDT 2010
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/747/#review2283
-----------------------------------------------------------
Ship it!
Looks like it should work to me, even if you poke the thread while it's not currently asleep.
- Mark
On 2010-06-25 12:19:38, David Vossel wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/747/
> -----------------------------------------------------------
>
> (Updated 2010-06-25 12:19:38)
>
>
> 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
>
>
More information about the asterisk-dev
mailing list