[asterisk-dev] [Code Review] chan_sip: RFC compliant retransmission timeout

[Terry Wilson]

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

Ship it!


This looks fundamentally correct to me, with the caveats below. Sometime I think we really need to go through chan_sip and remove all of the magic numbers for timers (like 4000ms for T2, etc.). Also, pkt->timer_a is poorly named since it doesn't start at t1 and  increment--it just keeps track of the current multiplier. But, those are things for another time, I suppose.


/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/749/#comment5267>

    Since pkt->retrans_stop is only used from inside this function, do we need to have it stored in sip_pkt? If we do need it, I notice that we have (char)is_resp, (char)is_fatal, and now (int)retrans_stop in sip_pkt. We might think about making those bitfields.



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/749/#comment5268>

    I suppose this could overflow for absurdly large values of timer_t1 since they are both ints. So above, instead of retransmitting for 4.3 years (with timer_t1 ~ 2^31), we would instead not retransmit at all. ;-)


- Terry


On 2010-06-29 09:30:45, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/749/
> -----------------------------------------------------------
> 
> (Updated 2010-06-29 09:30:45)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Retransmission of packets should not be based on how many packets were sent, but instead on a timeout period.  Depending on whether or not the packet is for a INVITE or NON-INVITE transaction, the number of packets sent during the retransmission timeout period will be different, so timing out based on the number of packets sent is not accurate.
> 
> This patch fixes this by removing the retransmit limit and only stopping retransmission after a timeout period is reached.  By default this timeout period is 64*(Timer T1) for both INVITE and non-INVITE transactions.  For more information on sip timer values refer to RFC3261 Appendix A.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 272920 
>   /trunk/channels/sip/include/sip.h 272920 
> 
> Diff: https://reviewboard.asterisk.org/r/749/diff
> 
> 
> Testing
> -------
> 
> I tested this with a sipp scenario that sends an INVITE but does not respond to Asterisk's 200 OK response.  I verified Asterisk continues to send retransmits until the packet times out at the correct timeout time.  I also did a sanity check to verify packets continue to be acknowledged correctly by placing some test calls.
> 
> 
> Thanks,
> 
> David
> 
>