[asterisk-bugs] [JIRA] (ASTERISK-24831) Upon reeiving BYE a dialog is scheduled for destruction in 32000 ms and gets stuck, causing long calls

[Fabian Borot (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225133#comment-225133 ] 

Fabian Borot commented on ASTERISK-24831:
-----------------------------------------

Thank you Matt I have all of that it, but cant posted it here, what can we do?


> Upon reeiving BYE a dialog is scheduled for destruction in 32000 ms and gets stuck, causing long calls
> ------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24831
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24831
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.2.1, 13.1.0
>         Environment: Asterisk 13.1-cert1 built by root @ AW-MIA-CORE-14 on a x86_64 running Linux on 2015-02-22 04:22:00 UTC
> Linux AW-MIA-CORE-14 2.6.18-308.24.1.el5 #1 SMP Tue Dec 4 17:43:34 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Fabian Borot
>            Assignee: Fabian Borot
>         Attachments: debug log filtered by 11820 c-000da360-with private IPs.txt
>
>
> We are having a very serious with calls not being terminated upon receiving of the BYEs sometimes.
> A call is established, then one of the legs(in this case  B leg, outgoing channel) sends a BYE, the log shows the BYE being received and replied to (sip debug, plus debug level), but the call is scheduled to be destroyed in 32000 ms. (really long time!!) and nothing is shown in the logs regarding the termination of the whole dialog right away.
> Then the A leg ( incoming channel) sends a BYE before that time (7 secs after we received the BYE in the B leg!!) because the asterisk did not send the BYE upon receiving the Bye for the B leg.
>  It seems in this case that the BYE from the A leg (2nd BYE) was the one that shutdown the call and we can see the DIAL command returning but sometimes also the process is repeated (also incoming channel scheduled for destruction in 32000 ms)
> Sometimes the difference is more than a minute and this is causing us to have different times for the call record, over billing out customers and creating huge disputes.
> I have a pcap file with both legs of the call, the asterisk log with debug info but I can publish it here because it has public IPs (from us, our customer and our providers)
> I am submitting a summary of the debug session for this call replacing the IPs by private IPs, I can provide the rest to a safe place upon request.
> At first sight it seems to be that the "sip_scheddestroy_final" inside "handle_request_bye" in chan_sip.c is called with the def value = -1, causing it to scheduled the destruction to "timer1 * 64" exactly 32000 ms
> which should not be the case because asterisk received the BYE and replied to it as well right away with 200 OK, so there is nothing to wait for.
> In case that the asterisk is the one sending the BYE then it has to go through the process of retransmitting the BYE request at T1, then 2T1 etc
> let me know what else is needed please, we have a lot or urgency to fix this issue, although it can not be replicated we thing that we can provide enough information to help find the problem



--
This message was sent by Atlassian JIRA
(v6.2#6252)