vicidial.org

Hey Guys,

I'm having this issue that when an agent transfers the call to external phone number via Transfer-Conf then Dial With Customer. After the agent leaves the 3-way, disposition the call and customer hangs up but the transfer line stays active or did not hang up the call yet, the call still stays active. Sometimes it goes up to 50 minutes active

Isn't it that after the customer hangs up the call everything should be disconnected or terminated even in the transfer line?

Here's my configuration:

crontab:
/usr/share/astguiclient/ADMIN_keepalive_ALL.pl --cu3way
/usr/share/astguiclient/AST_conf_update.pl --no-vc-3way-check

dialplan:
exten => _9COC1NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9COC1NXXNXXXXXX,n,Dial(SIP/CONNEX/1317#${EXTEN:4},,tToR)
exten => _9COC1NXXNXXXXXX,n,Hangup

Server > Recording Limit: 90

Campaign > Hangup Xfer Recording Start: Y

I also tried to use the 88 prefix which I slightly modify to match my dialplan above:

; This is a loopback dialaround to allow for hearing of ringing for 3way calls
exten => _881NXXNXXXXXX,1,Answer()
exten => _881NXXNXXXXXX,n,Dial(${TRUNKloop}/9COC${EXTEN:2},,To)
exten => _881NXXNXXXXXX,n,Hangup()

but still have no lack.

Any solutions for this?

If there is more than 1 channel in the session, the system won't clear it out. Check your logs and see what the conditions are for the examples you have.

We have a client that does tens of thousands of 3way calls(with leave 3way) each day like this and they have not had any issues like the one you have reported.

Hi Matt,

Thanks for the reply. I run some test again today and I captured the log for test:

this is during the transfer of the call to external phone number, agent leaves 3 way and when customer already hangs up:

Code: Select all

[Sep  6 17:29:48] VERBOSE[19915][C-0001e69f] pbx.c: Executing [8817542318639@default:1] Answer("Local/8817542318639@default-00011a96;2", "") in new stack
[Sep  6 17:29:48] VERBOSE[19914] dial.c: Called 8817542318639@default
[Sep  6 17:29:48] VERBOSE[19914] dial.c: Local/8817542318639@default-00011a96;1 answered
[Sep  6 17:29:48] VERBOSE[19914][C-0001e6a0] pbx.c: Executing [8600100@default:1] MeetMe("Local/8817542318639@default-00011a96;1", "8600100,Fq") in new stack
[Sep  6 17:29:48] VERBOSE[19915][C-0001e69f] pbx.c: Executing [8817542318639@default:2] Dial("Local/8817542318639@default-00011a96;2", "IAX2/ASTloop:pTfa58HwqFYCD2VF@127.0.0.1:40569/9COM17542318639,,To") in new stack
[Sep  6 17:29:48] VERBOSE[19915][C-0001e69f] app_dial.c: Called IAX2/ASTloop:pTfa58HwqFYCD2VF@127.0.0.1:40569/9COM17542318639
[Sep  6 17:29:48] VERBOSE[19916][C-0001e6a1] pbx.c: Executing [9COM17542318639@default:1] AGI("IAX2/ASTloop-7960", "agi://127.0.0.1:4577/call_log") in new stack
[Sep  6 17:29:49] VERBOSE[19916][C-0001e6a1] pbx.c: Executing [9COM17542318639@default:2] Dial("IAX2/ASTloop-7960", "SIP/CONNEX/1318#17542318639,60,tToR") in new stack
[Sep  6 17:29:49] VERBOSE[19916][C-0001e6a1] app_dial.c: Called SIP/CONNEX/1318#17542318639
[Sep  6 17:29:50] VERBOSE[19915][C-0001e69f] app_dial.c: IAX2/127.0.0.1:40569-5447 is making progress passing it to Local/8817542318639@default-00011a96;2
[Sep  6 17:29:55] VERBOSE[19915][C-0001e69f] app_dial.c: IAX2/127.0.0.1:40569-5447 answered Local/8817542318639@default-00011a96;2
[Sep  6 17:29:55] VERBOSE[19915][C-0001e69f] bridge_channel.c: Channel Local/8817542318639@default-00011a96;2 joined 'simple_bridge' basic-bridge <6c1c2f49-e9db-4410-8e7c-eeed1bf912a3>

and this is the normal log when the transfer line hangs up:

Code: Select all

[Sep  6 17:33:09] VERBOSE[19916][C-0001e6a1] pbx.c: Spawn extension (default, 9COM17542318639, 2) exited non-zero on 'IAX2/ASTloop-7960'
[Sep  6 17:33:09] VERBOSE[19915][C-0001e69f] bridge_channel.c: Channel Local/8817542318639@default-00011a96;2 left 'simple_bridge' basic-bridge <6c1c2f49-e9db-4410-8e7c-eeed1bf912a3>
[Sep  6 17:33:09] VERBOSE[19915][C-0001e69f] pbx.c: Spawn extension (default, 8817542318639, 2) exited non-zero on 'Local/8817542318639@default-00011a96;2'
[Sep  6 17:33:09] VERBOSE[19915][C-0001e69f] pbx.c: Executing [h@default:1] AGI("Local/8817542318639@default-00011a96;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----200-----200-----IAX2 HANGUP (16))") in new stack
[Sep  6 17:33:09] VERBOSE[19915][C-0001e69f] res_agi.c: <Local/8817542318639@default-00011a96;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----200-----200-----IAX2 HANGUP (16)) completed, returning 0
[Sep  6 17:33:09] VERBOSE[19914][C-0001e6a0] pbx.c: Spawn extension (default, 8600100, 1) exited non-zero on 'Local/8817542318639@default-00011a96;1'
[Sep  6 17:33:09] VERBOSE[19914][C-0001e6a0] pbx.c: Executing [h@default:1] AGI("Local/8817542318639@default-00011a96;1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16--------------------)") in new stack
[Sep  6 17:33:09] VERBOSE[19914][C-0001e6a0] res_agi.c: <Local/8817542318639@default-00011a96;1>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16--------------------) completed, returning 0

Any update on solution on this ? My other guy from Mexico also having this issue on one of the Poundteam Server. Hope that Bill can see this post .

again the process is:

agent call customer (manual or predictive) > customer transferred to external number > agent leave 3 way after dial with customer > 3rd line answered customer and talk > customer hangs up but 3rd line stays on the line. And the call won't terminate not until 3rd line hangs up the call.

The behaviour that I expect is once the customer hangs up it'll also show hangup on the 3rd line.

With that flow the line is still active and when I pull the transfer recording, all I can hear is dead call. If the the line wasn't hangup on 3rd line (say for an hour), it'll also shows in the voip report in my provider that the total minutes of call will be like 60min. Same duration of the call (just to verify).

I would need to review the external transfer and the hangup process on a working system and compare it against your to see what it is missing, but a posible work around would be adding manually to the meetme app the option k - Close the conference if there's only one active participant left at exit.

ambiorixg12 wrote:I would need to review the external transfer and the hangup process on a working system and compare it against your to see what it is missing, but a posible work around would be adding manually to the meetme app the option k - Close the conference if there's only one active participant left at exit.

Possibly a great workaround ... as long as recording is not still in play.

And the call won't terminate not until 3rd line hangs up the call.

Um ... by design. There is still someone in the call, the call is still live. The remote agent has to hang up the call to kill it. WHY would your remote agent / 3rd party NOT hang up the call? (Help us understand the situation here).

This may require a custom watchdog app to check every minute for "single party calls" that were once "two party calls" and do not presently involve an agent (ie: don't kill an agent session with an agent waiting for calls!) at least until a new function / trigger can be added to backwash the end of the call and kill the entire session when the client terminates the call (actually, I'd think either end terminating should kill the entire session ...?)

In Production when our reps transfer over the customer most of the time they are falling to an IVR (external) and due to long wait and customer will tend to hang up the call leaving the the meetme to still live.

ambiorixg12 wrote:I would need to review the external transfer and the hangup process on a working system and compare it against your to see what it is missing, but a posible work around would be adding manually to the meetme app the option k - Close the conference if there's only one active participant left at exit.

which file should I add the k ?

just want to confirm if this is the line that needs to be edited in extensions.conf? :

Code: Select all

; astGUIclient conferences
exten => _86000[0-4]X,1,Meetme(${EXTEN},q)
exten => _86000[0-4]X,n,Hangup()

; VICIDIAL conferences
exten => _86000[5-9]X,1,Meetme(${EXTEN},Fq)
exten => _86000[5-9]X,n,Hangup()
exten => _8600[1-2]XX,1,Meetme(${EXTEN},Fq)
exten => _8600[1-2]XX,n,Hangup()

[Sep 6 17:29:48] VERBOSE[19914][C-0001e6a0] pbx.c: Executing [8600100@default:1] MeetMe("Local/8817542318639@default-00011a96;1", "8600100,Fq") in new stack

Based on your logs this is the conference room 8600100, so this one looks to be the line exten => _8600[1-2]XX,1,Meetme(${EXTEN},Fq)

but a posible work around would be adding manually to the meetme app the option k - Close the conference if there's only one active participant left at exit.

IT WORKS!

Thank you guys.

excellent postback newbie!

newbie!

Indeed I am . tnx again Bill. as always.