vicidial.org

Goautodial 3.3 standard installation, latest git pull.

Problem happens when Remote Agent hangs up - the caller in the Ingroup is not kicked from the meetme. Caller stays in the conference for about 10 minutes and eventually gets disconnected.

Same problem happens when the caller hangs up. Remote Agent stays in the conference but gets disconnected in shorter time frame (1-2 min).

Anything wrong or that's by design?
Thank you

odessaxeon wrote:Goautodial 3.3 standard installation, latest git pull.

NEVER use the phrase "latest" unless it is actually your intent to make future users look up the repository at this date and time to find out your Vicidial Version number. Which is available in the admin screens you were just looking at a minute ago (unless gardo hid them?). Please just post the Vicidial Version with Build (as a requirement for this site, which provides Free Support for the Free Software called Vicidial which is theoretically making you lots of money! LOL )

odessaxeon wrote:Problem happens when Remote Agent hangs up - the caller in the Ingroup is not kicked from the meetme. Caller stays in the conference for about 10 minutes and eventually gets disconnected.

Who set up your "Carrier"? It's possible your carrier dialplan entry is missing the 'hangup" line (3rd line) which runs a cleanup script. Without that line ... there is no follow up process to clean up after the call terminates. If you're not sure, have a look at the Example carriers that were in the system originally. The Dialplan Entry field has three required lines. The first and last lines are absolutely required and should remain unchanged except that the extension should match your carrier.

Please post an example asterisk CLI output for a test of this issue. Not real, not 3000 lines of code from a fully running dialer ... just One Call with nothing else going on.

Here is the Vici version:
VERSION: 2.9-441a
BUILD: 140612-1628

The carrier is setup properly, with hangup @ the 3rd line.
This happens only with remote agents, logged in agents have no issues.
I will submit log on the weekend.

As per your comment:

williamconley wrote:which is theoretically making you lots of money! LOL )

I will post an off topic joke - hope nobody minds

Man comes home from work and asks his wife and daughter:
Man to wife: Would you sleep with another man for $1000?
Wife: no.
Man: what about seeping with another man for $100000?
Wife: yea, I would
Man to daughter: Would you sleep with another man for $1000?
Daughter: no.
Man: what about seeping with another man for $100000?
Daughter: yea, I would
Then Man says - theoretically, we are reach, but practically - I have two sluts in my home

All remote agents? Cell Phones? Land Lines? Vicidial SIP phones?

Note that remote agents come in many flavors ... they can use a phone under Admin->Phones or an extension that passes through a Vicidial dialplan entry for a carrier. Whichever you are using ... try it with another. If it passes through a carrier dialplan with hangup ... move it to a dialplan that does NOT have that (if it doesn't, change it to one that does ...).

If you can reproduce the issue reliably, it should be fairly easy to resolve. We like those! (It's those Intermittent issues that are perplexing. And actually even more fun! LOL )

Posting an asterisk CLI example would be useful ...

ViciBox v.7.0.4-170113
VERSION: 2.14-647a
BUILD: 171229-2309

Sorry to dig up an old thread, but I didn't see that there was a clear solution for local SIP phone devices.

I have a similar issue using Remote Agents to local SIP phone extensions. If the caller hangs up first, the SIP phone gets disconnected immediately, no problem there. But if the agent hangs up first, the system does not immediately hang up on the caller (My one test call so far was about 3 minutes). The system is live at the moment, so the logs will have to wait until this evening.

Actually just typing this now, I have an idea.

I going to try setting the Remote Agent Extension to 9999XXXX, where XXXX is the actual extension, then add this to the top of the carrier dialplan:

exten => _9999XXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9999XXXX,n,Dial(SIP/${EXTEN:4},,tTo)
exten => _9999XXXX,n,Hangup

Setup & test complete. Result: the same. The caller is left in the conference by themselves, and the realtime report shows the agent in the call still.

Recommendations?


**** EDIT ****
I didn't actually test the caller hanging up first, the guys just didn't say that was a problem. I just tested it myself and it doesn't hang up the agent immediately, it was about 2 minutes.

I think maybe my test agent extension (was '5555') was effecting the results. I changed the test extension to '2000' and using the 99992000 remote agent as described above, both sides of the call hang up as soon as the other side hangs up.

necival wrote:I think maybe my test agent extension (was '5555') was effecting the results. I changed the test extension to '2000' and using the 99992000 remote agent as described above, both sides of the call hang up as soon as the other side hangs up.

good postback!

Actually, my comment about 5555 vs 2000 was not correct, the new user 2000 was set to ON-HOOK=N (the default for a new remote agent). That was the real difference. Changing that user to ON-HOOK=Y had the same results previously stated. As a bandaid for the call center, I've switched all the agents to ON-HOOK=N but this doesn't feel like a solution to me.

I also had to modify the 9999 prefix to override the caller id name sent to the SIP device:

exten => _9999XXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9999XXXX,n,Set(CALLERID(name)=${CALLERID(num)})
exten => _9999XXXX,n,Dial(SIP/${EXTEN:4},15,tTo)
exten => _9999XXXX,n,Hangup

One major problem with this setup is that the admin cannot use the monitor/listen feature of the real-time main report. I'm guessing that might be related to the CID name override, but haven't dug into that yet.

Maybe I'm missing something basic regarding the on-hook=y setup...

Is there a way for the on-hook remote agent to hang up on the caller, maybe with dtmf?
If not, how can we get the conference to hang up immediately if either party hangs up?

I'm also going to try installing the latest vicibox on a separate machine and test if it behaves the same, maybe this was a bug that is already fixed in newer versions that what this call center is using.

I'm also going to try installing the latest vicibox on a separate machine and test if it behaves the same, maybe this was a bug that is already fixed in newer versions that what this call center is using.

We have no clients experiencing this problem, so I'd suggest that there is something ... special about your install/configuration that's causing this breakage.

HI
I have the same issue , all configuration is corercte just like our freind