[Home]

Summary:ASTERISK-03703: [patch] Don't destroy call until all responses on BYE have been processed
Reporter:khb (khb)Labels:
Date Opened:2005-03-18 15:32:49.000-0600Date Closed:2011-06-07 14:11:56
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch_sip_hangup.txt
( 1) siphangup.txt
Description:Calls are destroyed too early on some BYEs when responses might still be expected, causing obvious effects.
Comments:By: khb (khb) 2005-03-18 15:36:33.000-0600

Patch is for dev. CVS
By: Mark Spencer (markster) 2005-03-18 15:44:15.000-0600

What do you mean "all responses on bye"?  We do not cancel the bye until we get an acknowledgement on it already.
By: khb (khb) 2005-03-18 18:43:08.000-0600

Should have said "any responses"
Seems like the pvt is destroyed immediately after sending BYE,
and that's what appeared to be the situation, since the
response apparently couldn't be matched to an existing call.
Keeping the dialog pvt around a little longer seemed to
fix it. Could be a combination of issues perhaps, not only by
Asterisk.
Not sure what you mean by "cancel the bye", you mean cancel
retransmissions?  That didn't seem to be a problem.
By: Olle Johansson (oej) 2005-03-19 03:04:23.000-0600

khb: Patch disclaimed?
By: Olle Johansson (oej) 2005-03-19 03:38:24.000-0600

Why not fix both CANCEL and HANGUP?

According to the RFC, we should hang around 64 T1 timers (500 ms or RTT) until we destroy the dialog for a CANCEL.

There's no timer for BYE in 15.1.1, so I guess it's the default from 17.1.2 which also is 64 T1 timers.

KHB: Do you agree with this patch?

Disclaimer on file.
By: khb (khb) 2005-03-19 10:38:05.000-0600

Hmm, I am not sure that is ok.  I haven't investigated the actual behavior on Cancel with this driver.
Cancels technically can only be issued during a short period while a dialog has not transitioned to the completed state yet, and there should have been a timer active already.
This was a dialog ending BYE and there definitely didn't seem to be a timer active at that time and instance.  I didn't spend any time researching this, what seemed to be a bug in that installation or scenario, in any great depth. This was more a or less a "3 1/2 Minute fix" again initially which then seemed should be permanent.
Retrofitting chan_sip with proper timers is tricky as it has only circumstancial notion of state.
If you want to move the patch up for more generality, you need to research existing behavior in all cases of hangups and cancels.
By: Kevin P. Fleming (kpfleming) 2005-03-31 15:15:38.000-0600

Is one of these patches ready for CVS? There doesn't seem to be consensus here, except that destroying the private structure as soon as we send BYE is the wrong thing to do.
By: Mark Spencer (markster) 2005-04-11 01:05:13

sip channels are not actually destroyed until there are no packets for retransmission which means that a final response to the bye has to be received, see the line:

if (ast_test_flag(sip, SIP_NEEDDESTROY) && !sip->packets && !sip->owner) {
ast_mutex_unlock(&sip->lock);
__sip_destroy(sip, 1);
goto restartsearch;
}
By: Michael Jerris (mikej) 2005-05-02 15:57:32

Is this still an issue?  *poke*
By: Olle Johansson (oej) 2005-06-05 17:37:26

I will have to update patch to latest cvs. Will try soon.
By: Michael Jerris (mikej) 2005-07-12 16:49:34

oej-  This one seems to have stalled.  Where do we stand here?
By: Olle Johansson (oej) 2005-07-20 13:48:47

---Have to believe Mark that it's not an issue.