Disconnect local channels taken Vicidial

[chuentecural]

Hi, I´m new in this forum, at present work with a Vicidial System, and I need help with a problem I am presenting

please I needs help!

The characteristics of my system are as follows

Vicibox v.8.1.2
Version 2.14-695a (information since web Vicidial)
Asterisk 13.21.1-vici

the problem is that I am observing, that from my asterisk there are stuck or dead calls that carry much time. I tried to hang up these calls with the "hangup request" and selecting the channel but I have the following result: "is not know channel"

for example:

vicibox81:~ # asterisk -rx "hangup request Local/9156412013473@default-00006216;2"
Local/9156412013473@default-00006216;2 is not a known channel
vicibox81:~ #


these are the calls that are taken:

vicibox81:~ # asterisk -rx "core show channels verbose"
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID
Local/9156412013473@ default h 1 Ring AGI agi://127.0.0.1:4577/call 0000000000 15:09:10
Local/9156987239341@ default h 1 Up AGI agi://127.0.0.1:4577/call 0000000000 15:09:10
Local/9156652354074@ default h 1 Ring AGI agi://127.0.0.1:4577/call 0000000000 15:09:10
0 active channels
0 active calls
63797 calls processed
vicibox81:~ #

I've had this problem before and the solution was to restart my server, but I don't find that to be an optimal solution.

[williamconley]

1) Welcome Aboard!

2) Good job posting your system specs. However: Please remember to include the full Vicidial Version WITH BUILD (you missed the build).

3) This is not a "General Discussion". It's a Support request. I will move the thread to the Support Board accordingly.

4) Your stated problem:

stuck or dead calls that carry much time

DEAD calls is what happens when a Lead hangs up but the agent does not push "hangup customer" and instead stays in the session not talking to anyone. It's a good reason to fire someone, but does not in any way indicate that there is a flaw in Vicidial UNLESS you have reason to believe that the Lead is in fact still on the phone with the agent (for instance by Monitoring the call and hearing them still talking).

There is a campaign setting to auto-pause agents who sit in DEAD for too long. You may want to look into that.

"stuck" doesn't mean anything. Please clarify if you meant something other than DEAD being displayed in the real time screen.

5) Your example:

vicibox81:~ # asterisk -rx "hangup request Local/9156412013473@default-00006216;2"

As stated in 4), since the Lead has already hung up, trying to terminate the Lead's channel is pointless. It's already been terminated. So I won't bother asking you why you would run this command, or where you got the data ... it doesn't matter. The real time screen's DEAD determination made this attempt rather pointless.

[chuentecural]

William thanks for the reply.

I attached required information.
"BUILD: 181116-1133"

The calls indicated sometimes have a time of more than 24 hours active without having executives connected and even executing the "hangup request" command the call does not disconnect it, as I mentioned sometimes I have more than 10 calls that spend more than 24 hours active and the only solution is to restart the server.

[williamconley]

The calls indicated sometimes have a time of more than 24 hours active

I'd like to see the evidence of this. Is it a log entry or a realtime screen entry?

I suspect you have a configuration/installation issue based on your description.

Have you manually edited any of your .conf files in any way?

Do you make calls outside the Vicidial interface?

What pathways do these "24 hour" calls take? Inbound ... outbound ... transfers ... survey ...?

[chuentecural]

William.

The calls I send to you are still shown by the asterisk but not vicidial, it will also show two additional calls with less time.
attached call capture from asterisk.

vicibox81:~ # asterisk -rx "core show channels verbose"
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID
Local/9156983339869@ default h 1 Up AGI agi://127.0.0.1:4577/call 0000000000 21:30:51
Local/9156412013473@ default h 1 Ring AGI agi://127.0.0.1:4577/call 0000000000 39:11:32
Local/9156987239341@ default h 1 Up AGI agi://127.0.0.1:4577/call 0000000000 39:11:32
Local/9156652354074@ default h 1 Ring AGI agi://127.0.0.1:4577/call 0000000000 39:11:32
Local/9156322255395@ default h 1 Ring AGI agi://127.0.0.1:4577/call 0000000000 20:03:31
0 active channels
0 active calls
162172 calls processed
vicibox81:~ #


do you talk about configuring the .conf file would this be extensions.conf?


this problem happens with predictive calls (outgoing) from vicidial, when manual calls are made (outgoing) we do not have this problem

[williamconley]

We'll need the full log from a single call to see where it went wrong.

"Predictive"? Is this campaign set to adapt or ratio? (Adapt is predictive, Ratio is just autodial)

0 active channels suggests that these calls are not really active.

Have you manually edited ANY .conf files related to asterisk?

By Misconfigured I refer to modifying any conf files in asterisk or having an incorrect entry for a Carrier.

If you provided your carrier information (in admin->carriers) that would be helpful. Replace any IPs by changing the last two sets of numbers with Xs and change any user/password/secret information to Xs as well.

[chuentecural]

I commented that the configuration of our Vicidial server was a backup of an old server. When I started to manage this server I encountered these problems.

I answer your questions

"Predictive"? Is this campaign set to adapt or ratio? (Adapt is predictive, Ratio is just autodial)
This problem occurs in predictive campaigns.

0 active channels suggests that these calls are not really active.
As you mentioned, there are no active channels, but the calls shown by the asterisk are taken

Have you manually edited ANY .conf files related to asterisk?
I have only edited files such as extension_psnt.conf and sip.conf

By Misconfigured I refer to modifying any conf files in asterisk or having an incorrect entry for a Carrier.
Attachment configuration



If you provided your carrier information (in admin->carriers) that would be helpful. Replace any IPs by changing the last two sets of numbers with Xs and change any user/password/secret information to Xs as well.

[williamconley]

backup of an old server.

So you took just the db from that old server or the entire system (perl script, php files, etc).

"Predictive"? Is this campaign set to adapt or ratio? (Adapt is predictive, Ratio is just autodial)
This problem occurs in predictive campaigns.

Is the dial method for the campaign Adapt or Ratio?

0 active channels suggests that these calls are not really active.
As you mentioned, there are no active channels, but the calls shown by the asterisk are taken

I'm not sure what you mean by this.

Have you manually edited ANY .conf files related to asterisk?
I have only edited files such as extension_psnt.conf and sip.conf

Remove all edits to any conf files. There should not be a psnt.conf unles Vicidial created it (which it does not, it creates "extension-vicidial.conf"). This is likely where your problem is.

By Misconfigured I refer to modifying any conf files in asterisk or having an incorrect entry for a Carrier.
Attachment configuration

Do NOT post images of configurations (they fail in most cases anyway, such as these ... everyone but you just sees the URL and/or the word Image). Do not post entire configuration files either. Images are not searchable and as such useless for future users (who all arrive here via google ... a search engine, lol).

Additionally, posting just the index of the carriers with NO active carriers provides no information. The manual entries you made to .conf files should instead be in a carrier. Each carrier entry has the ability to put the information for each carrier in the appropriate .conf file without manual editing (and that's why the carrier module exists: to avoid manual edits). If you make a mistake creating a carrier, all you need to do is deactivate the carrier and your mistake is gone. Plus during upgrades the .conf files are modified ... which deletes your modifications. And you have to log in via console to edit as opposed to making all edits in the web interface (keeps all locations where human error may be an issue within easy reach, no console access required except for troubleshooting ... NOT for changes. )

Post the configuration options as test that you believe are relevant. Not all of them. Just ones you have changed from their default values and are being used by these calls.

If you provided your carrier information (in admin->carriers) that would be helpful. Replace any IPs by changing the last two sets of numbers with Xs and change any user/password/secret information to Xs as well.

[/quote]
You missed this entirely.