freeswitch
freeswitch copied to clipboard
signalwire
Kill channel freeswitch not exits
I have calls that come into a queue and then get pulled out by a lua script in background and transfered to a destination. all works fine except that it looks like the sessions a not clearing from FS when all the parties clear the calls.
When I do show channels, I get this for example: uuid direction created created_epoch name state cid_name cid_num ip_addr dest presence_id presence_data callstate callee_name callee_num callee_direction call_uuid hostname sent_callee_name sent_callee_num 5e8215e7-b036-4cce-9b96-e57db92f13ee outbound 03/10/2019 11:40 1.35E+09 sofia/external/02031950164 CS_HANGUP Outbound Call 2031950164 135.196.144.32 agent_to_queue_paymentsense_queue_service ACTIVE SEND 5e8215e7-b036-4cce-9b96-e57db92f13ee freeswitch2 4.4209E+11 2089623100
But when I try to get kill or query it, I get a message that the call is not anywhere in the FS.
/usr/local/freeswitch/bin/fs_cli -H 10.5.2.105 -x "uuid_kill 5e8215e7-b036-4cce-9b96-e57db92f13ee" -ERR No Such Channel!
/usr/local/freeswitch/bin/fs_cli -H 10.5.2.105 -x "uuid_exists 5e8215e7-b036-4cce-9b96-e57db92f13ee" false
Does anyone have an idea how I can kill that call. If I restart the FS, they clear, but the problem is that they are hitting my limit on number of simultaneous calls.
Any help much appreciated.
please confirm you see this behavior with latest freeswitch release.
I'm using freeswitch v1.10.1 latest
Post the lua script. Maybe it has an endless loop.
What lua script file I can show you? I dont use lua script
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.
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
You can only hangup channels once so trying again will not work and just say not found. Look for the logs that match the uuid of the hung channels to see if it fully destroyed. If something is holding on to the session it will get stuck at the end of its lifetime to prevent crashes.
On Tue, Jun 23, 2020 at 11:24 PM HưởngNV [email protected] wrote:
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
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/signalwire/freeswitch/issues/34#issuecomment-648575817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEAFFM3553FDBCH2OCPBGTRYF5ZXANCNFSM4I46MMVQ .
-- Anthony Minessale II Founder, FreeSWITCH. http://freeswitch.com
https://youtu.be/l_hOxzCt6X4 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
How longisthe lifetime? There is definitely somethingholdingontothe session, there isnothingmorementioningthe uuid after the say entry.
On Wed, 24 Jun 2020 00:28:40 -0400, Anthony Minessale wrote:
[1 <text/plain; UTF-8 (quoted-printable)>] You can only hangup channels once so trying again will not work and just say not found. Look for the logs that match the uuid of the hung channels to see if it fully destroyed. If something is holding on to the session it will get stuck at the end of its lifetime to prevent crashes.
On Tue, Jun 23, 2020 at 11:24 PM HưởngNV [email protected] wrote:
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
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/signalwire/freeswitch/issues/34#issuecomment-648575817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEAFFM3553FDBCH2OCPBGTRYF5ZXANCNFSM4I46MMVQ .
-- Anthony Minessale II Founder, FreeSWITCH. http://freeswitch.com
https://youtu.be/l_hOxzCt6X4 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/signalwire/freeswitch/issues/34#issuecomment-648576865 [2 <text/html; UTF-8 (quoted-printable)>]
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici wb2una
[email protected]
would this makeit possible to kill the channel? and could you give steps such as delete statements, etc.
Thanks.
On Wed, 24 Jun 2020 00:24:59 -0400, HưởngNV wrote:
[1 <text/plain; UTF-8 (7bit)>]
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
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/signalwire/freeswitch/issues/34#issuecomment-648575817 [2 <text/html; UTF-8 (7bit)>]
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici wb2una
[email protected]
I fixed the initial problem with cepstral and that solved the hang, but I think there should be a way to kill such a channel in some way or a shorter timeout.
On Wed, 24 Jun 2020 00:28:40 -0400, Anthony Minessale wrote:
[1 <text/plain; UTF-8 (quoted-printable)>] You can only hangup channels once so trying again will not work and just say not found. Look for the logs that match the uuid of the hung channels to see if it fully destroyed. If something is holding on to the session it will get stuck at the end of its lifetime to prevent crashes.
On Tue, Jun 23, 2020 at 11:24 PM HưởngNV [email protected] wrote:
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
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/signalwire/freeswitch/issues/34#issuecomment-648575817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEAFFM3553FDBCH2OCPBGTRYF5ZXANCNFSM4I46MMVQ .
-- Anthony Minessale II Founder, FreeSWITCH. http://freeswitch.com
https://youtu.be/l_hOxzCt6X4 https://www.youtube.com/watch?v=oAxXgyx5jUw https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/signalwire/freeswitch/issues/34#issuecomment-648576865 [2 <text/html; UTF-8 (quoted-printable)>]
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici wb2una
[email protected]
@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
@huongbn did you resolve your issue? I faced the same problem the other day, solved it like:
show callsand if
kill {uuid}returns error, then I trykill {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
I have the same problem on FreeSWITCH Version 1.10.3-release-15-129de34d84~64bit (1.10.3 -release-15-129de34d84 64bit)
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.
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.
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.
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.
Is there a way to determine what resources a "stuck call" is waiting for? Maybe if I increase the debugging level?
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?
Need every UUID of these 'stuck' calls checked in the logs, to find any common code paths the call takes or other interactions.
@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)
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.
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"
