[asterisk-dev] [Code Review] chan_sip: retransmit response to BYE requests until timer J expires

[Mark Michelson]

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

Ship it!


Looks good now!

- Mark


On 2010-06-17 10:19:00, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/694/
> -----------------------------------------------------------
> 
> (Updated 2010-06-17 10:19:00)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> According to RFC 3261 section 17.2.2, which describes non-INVITE server transaction, when a dialog enters the Completed state it must destroy the dialog after Timer J (T1*64) fires.  For a BYE transaction Asterisk terminates the dialog immediately during sip_hangup() when it should be waiting T1*64 ms.  This results in some odd behavior.  For instance if Asterisk receives a BYE and transmits a 200ok in response, if the endpoint never receives the 200ok it will retransmit the BYE to which Asterisk responds with a "481 Call leg/transaction does not exist" because the dialog is already gone.
> 
> To resolve this I made a function called sip_scheddestroy_final().  This differs slightly from sip_schedestroy() in that it enables a flag that will prevent the destruction from ever being rescheduled or canceled afterwards.  It also prevents the pvt's needdestroy flag from being set which triggers the destruction of the dialog within the do_monitor thread().  By using this function we are guaranteed destruction will not occur until the scheduled time.  This allows Asterisk to respond to any possible retransmits for a dialog after we process the initial BYE request for T1*64 ms.
> 
> 
> Other changes: I removed two instances where sip_cancel_destroy is used right before calling sip_scheddestroy.  sip_scheddestroy always calls sip_cancel_destroy before scheduling the new destruction so it is completely unnecessary.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 271122 
>   /trunk/channels/sip/include/dialog.h 271122 
>   /trunk/channels/sip/include/sip.h 271122 
> 
> Diff: https://reviewboard.asterisk.org/r/694/diff
> 
> 
> Testing
> -------
> 
> I tested this two ways.
> 
> 1. I made a sipp scenario that created a dialog, and sent a retransmit of the final BYE request over and over for 36 seconds.  Timer J (T1*64) by default is 32 seconds so my expected results were that the retransmitted BYE requests should receive a 200ok until after 32 seconds, in which dialog destruction takes place and the remaining BYE retransmissions should get "481 Call leg/transaction does not exist" responses.  These results occurred as expected.
> 
> 2. I called Asterisk from one of my Polycom phones, hung up, and verified that the dialog existed when issuing the "sip show channels" cli command in the correct state for 32 seconds until being removed.
> 
> I also ran some sip sanity tests verifying things like transfers still worked as expected.
> 
> 
> Thanks,
> 
> David
> 
>