Kill channel freeswitch not exits about freeswitch HOT 23 OPEN

@huongbn did you resolve your issue? I faced the same problem the other day, solved it like:

show calls

and if kill {uuid} returns error, then I try kill {b_uuid} and it works

from freeswitch.

please confirm you see this behavior with latest freeswitch release.

from freeswitch.

please confirm you see this behavior with latest freeswitch release.

I'm using freeswitch v1.10.1 latest

from freeswitch.

Post the lua script. Maybe it has an endless loop.

from freeswitch.

Post the lua script. Maybe it has an endless loop.

What lua script file I can show you? I dont use lua script

from freeswitch.

Using 1.10.3, I may have something similar. I am using an ivr menu with sepstral, and the last item in the execute stackis the say command for the long greeting. I can't kill the channel and if I do uuid_kill, it said no such channel, but I have to restart fs to get rid of it. Sepstral is not speaking so it may have problems, but the channel should definitely be able to be killed.

from freeswitch.

Using 1.10.3, I may have something similar. I am using an ivr menu with sepstral, and the last item in the execute stackis the say command for the long greeting. I can't kill the channel and if I do uuid_kill, it said no such channel, but I have to restart fs to get rid of it. Sepstral is not speaking so it may have problems, but the channel should definitely be able to be killed.

You can clear state channels in database

from freeswitch.

from freeswitch.

from freeswitch.

from freeswitch.

from freeswitch.

@huongbn did you resolve your issue? I faced the same problem the other day, solved it like:

show calls

and if kill {uuid} returns error, then I try kill {b_uuid} and it works

Same for me here. I'm trying to identify the main problem but I have the same behavior. Killing the other channel free the first locked one

from freeswitch.

I have the same problem on FreeSWITCH Version 1.10.3-release-15-129de34d84~64bit (1.10.3 -release-15-129de34d84 64bit)

from freeswitch.

Same problem with 1.10.5 / 1.10.3 / 1.10.2 .
A call B
B call C
B transfer A on C and sometimes we will have a blocked line.

We have an hangup on the call of B and C but not a unbridge, he will come only when the call between A and C will be hangup.

A and C have a normal call BUT B and C always have a line into show calls and A leg is not killable (no session exist), we have to kill B leg, this kill the blocked line BUT the call of A and C too.

Can we have a fix or do we have to go back into the 1.8 version ?
I saw this script : https://github.com/ccppprogrammer/clean_fs_calls.sh but i think it's not a normal solution.

from freeswitch.

Do you use mod_xml_cdr with an http endpoint to collect cdrs ?

I have noticed the problem seems to occur when the http endpoint not answer properly to FS when it pushs the xml cdr at the end of the call.

I think it's that that lock the normal clearing/closing channel cleanup in FS. Haven't dig this in code yet but maybe someone else could dig it.

from freeswitch.

No we don't use CDR of FreeSwitch, thank you for your help.
For more information we have only one script who use the session and it's the script who bridge the call between A/B and B/C, A/B will be released (the script will continue and close after the bridge) but the script about the call between B/C will be blocked on session:bridge and not be released after transfer.
We only have a other lua script who will work on session variable in live BUT he don't take the session (with freeswitch.session), he only use freeswitch command to set variable (like uuid_setvar) and this script is not blocked.

from freeswitch.

I have this issue occasionally, but haven't determined which part of my call flow is causing them to get stuck. It seems to be random on inbound or outbound calls. I'm using mod_xml_curl for directory and dialplan, and the calls as usually recorded.

Currently have 4 "stuck calls" on:
FreeSWITCH Version 1.10.6-release-18-1ff9d0a60e~64bit (-release-18-1ff9d0a60e 64bit)

uuid_kill {uuid} and uuid_kill {b_uuid} both return:

-ERR No such channel!

Yesterday something caused the SQLite to be busy (the full 300 retries down to "SQL is BUSY!"). I did a reload mod_sofia and it seemed to clear up, but maybe the two issues are related. But I couldn't find anything in the logs that indicated what caused the SQL to lock up, which is concerning.

from freeswitch.

Is there a way to determine what resources a "stuck call" is waiting for? Maybe if I increase the debugging level?

from freeswitch.

We need someone to tell us the steps they've done to replicate these 'stuck' calls, We've been searching for this, I suspect its related to the att_xfer app or the eavesdrop app, maybe both. fetristan How are you doing this transfer?

from freeswitch.

Need every UUID of these 'stuck' calls checked in the logs, to find any common code paths the call takes or other interactions.

from freeswitch.

@briankwest i don't kow how to replicate, i just know this scenario :

Same problem with 1.10.5 / 1.10.3 / 1.10.2 . A call B B call C B transfer A on C and sometimes we will have a blocked line.

We have an hangup on the call of B and C but not a unbridge, he will come only when the call between A and C will be hangup.

A and C have a normal call BUT B and C always have a line into show calls and A leg is not killable (no session exist), we have to kill B leg, this kill the blocked line BUT the call of A and C too.

Can we have a fix or do we have to go back into the 1.8 version ? I saw this script : https://github.com/ccppprogrammer/clean_fs_calls.sh but i think it's not a normal solution.

If this can help, we really often eavesdrop and it's really possible someone eavesdrop one of the leg at the transfer moment.
I will speak with my production to stop eavesdrop on these calls to see if we have a change.
If i can have a example ill copy there.

I don't know if this can help but the last time i found this on the blocked line :
9430ebd7-8a15-4027-beec-5b624162e4eb 2021-03-26 11:01:50.468564 [NOTICE] sofia.c:1089 Hangup sofia/internal/[email protected]:5060 [CS_PARK] [NORMAL_CLEARING]
9430ebd7-8a15-4027-beec-5b624162e4eb 2021-03-26 11:06:13.108556 [DEBUG] switch_ivr_bridge.c:1895 sofia/internal/[email protected]:5060 skip receive message [UNBRIDGE] (channel is hungup already)

from freeswitch.

I can also confirm that we use eavesdrop very often and run into the same problem. Using the latest version of fs does not help resolve this issue.
My script that @fetristan mentioned and somehow found it, partially solves the problem, but it's a dirty hack and shouldn't be used unless there are problems.

from freeswitch.

Hi, this is called zombie calls. I could only get rid of it by this script. After 20-30 mins I run this script and it deletes zombie calls from freeswitch's database. Here, you can use the script.

#!/bin/bash
t=$(date +%s)
let "tt=$t-500"
echo $tt
sql_channels="DELETE FROM channels WHERE created_epoch < $tt"
sql_calls="DELETE FROM calls WHERE call_created_epoch < $tt"
/usr/bin/sqlite3 /var/lib/freeswitch/db/core.db "$sql_channels"
/usr/bin/sqlite3 /var/lib/freeswitch/db/core.db "$sql_calls"

from freeswitch.