[Home]

Summary:ASTERISK-07146: Attended transfer does not free up the agent in queue
Reporter:astonmartin (astonmartin)Labels:
Date Opened:2006-06-12 04:52:38Date Closed:2006-09-27 13:48:13
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) configs_correct.txt
( 1) console_log.log
( 2) debug_petergg.txt
( 3) debug.log
Description:Agent stays in 'busy' state even after the attended transfer is successfully executed.

****** ADDITIONAL INFORMATION ******

If an agent presses *2 (or whatever the DTMF combination for attended transfer is), he/she will stay in 'busy' state until the conversation between the caller and the person, to which agent transfered the call to, is completed.
Comments:By: Serge Vecher (serge-v) 2006-06-12 09:40:37

ok ... do you have some console logs of this happening? What channels are in use?
By: astonmartin (astonmartin) 2006-06-12 10:40:01

I have uploaded console log - have executed SHOW QUEUE command, where you can see agent Agent/03020 being 'busy' after transfer.

SIP channels are in use.

Please let me know, if you need more info - configs and such.
By: astonmartin (astonmartin) 2006-06-15 02:47:47

I have just noticed that the agent would still receive new calls, eventhough she/he is in 'busy' state, so I wonder if this isn't just some silly typo in the app_queue.c, where a "status" constant or something like that doesn't get updated after transfer?
By: Serge Vecher (serge-v) 2006-06-15 08:27:41

ok, need to see a debug log here also.

Can you please make sure your logger.conf has the following line:
  console => notice,warning,error,debug

Then restart Asterisk, execute set debug 4 and try this again? Thanks
By: astonmartin (astonmartin) 2006-06-15 08:54:24

vechers: I have attached a debug.log file. Execution of the attended transfer is logged in line 366.

Let me know, if you need more info/logs...
By: Serge Vecher (serge-v) 2006-06-15 09:22:35

alright, moving this to app_queue project, as I think, the problem is within the app, not the core.
By: astonmartin (astonmartin) 2006-06-15 09:53:36

Yes, I guess you're right.
By: BJ Weschke (bweschke) 2006-06-16 08:02:42

can you please provide extensions.conf and agents.conf information as to how these agents are configured so this can be reproduced here locally? Thanks.
By: Serge Vecher (serge-v) 2006-06-16 11:43:46

re: config.txt
By: astonmartin (astonmartin) 2006-06-16 11:57:29

Please ignore configs.txt, as configs_correct.txt is the correct one. This is a sample txt file that includes extensions and agents configurations with which I have managed to reproduce the problematic behavior.

1. "from-sip" is a context to which SIP calls arrive
2. agents use SIP softphones and login by entering _51XXX extension, which executes AgentCallbackLogin action (XXX is number of the agent, let's say 001)
3. calls from queues get transfered to extension _4. in the "agents" context, which then forwards call to the desired SIP client (SIP/Agent001 for example)
4. Extension _7XXX in the "from-sip" context is the extension to which agents do the transfers by entering DTMF *27405 for example....where 4405 is an extension on another SIP server
5. Extension "123" is just a sample extension to a queue

Please let me know, if you will be unable to reproduce the problem.
By: astonmartin (astonmartin) 2006-06-17 09:07:23

Is it possible that the wrong two channels get bridged together or something like that?
By: Serge Vecher (serge-v) 2006-06-19 21:11:05

astonmartin: the debug trace is missing a [verbose] log.
Can you please do:
set debug 4
set verbose 4
sip debug

at CLI and recapture the console output and post here?
By: petergg (petergg) 2006-07-06 08:24:04

I have the same Problem.

here is the debug:

Jul  6 14:19:56 VERBOSE[10485] logger.c:     -- SIP/4461-3bdc answered Local/4461@user-e3b5,2
Jul  6 14:19:56 VERBOSE[10482] logger.c:     -- Agent/4461 answered SIP/telenumber-7280
Jul  6 14:19:56 VERBOSE[10485] logger.c:   == Spawn extension (user, 4461, 1) exited non-zero on 'Local/4461@user-e3b5,2'
Jul  6 14:19:59 VERBOSE[10482] logger.c:     -- Stopped music on hold on SIP/telenumber-7280
Jul  6 14:20:03 VERBOSE[3876] logger.c:     -- Started music on hold, class 'default', on channel 'SIP/telenumber-7280'
Jul  6 14:20:08 VERBOSE[10519] logger.c:     -- Executing Dial("SIP/4461-4f4a", "SIP/4460|55|tTr") in new stack
Jul  6 14:20:08 VERBOSE[10519] logger.c:     -- Called 4460
Jul  6 14:20:08 VERBOSE[10519] logger.c:     -- SIP/4460-75c8 is ringing
Jul  6 14:20:13 VERBOSE[10519] logger.c:     -- SIP/4460-75c8 answered SIP/4461-4f4a
Jul  6 14:20:13 VERBOSE[10519] logger.c:     -- Attempting native bridge of SIP/4461-4f4a and SIP/4460-75c8
Jul  6 14:20:15 VERBOSE[3876] logger.c:     -- Started music on hold, class 'default', on channel 'SIP/4460-75c8'
Jul  6 14:20:16 VERBOSE[3876] logger.c:     -- Stopped music on hold on SIP/telenumber-7280
Jul  6 14:20:16 VERBOSE[3876] logger.c:     -- Stopped music on hold on SIP/4460-75c8
Jul  6 14:20:16 VERBOSE[10482] logger.c:   == Spawn extension (qscin, telenumber, 11) exited non-zero on 'SIP/telenumber-7280'
Jul  6 14:20:16 VERBOSE[10519] logger.c:   == Spawn extension (user, 4460, 1) exited non-zero on 'Agent/4461'


By: Serge Vecher (serge-v) 2006-07-06 09:17:26

petergg: your debug log is also missing

Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
By: petergg (petergg) 2006-07-06 10:30:39

ok, i've added now the new debug-file.
By: Serge Vecher (serge-v) 2006-07-06 10:43:38

that looks better: the following lines are of interest:
Jul  6 17:11:36 DEBUG[11844] app_queue.c: Device 'Local/4462@user' changed to state '2' (In use) but we don't care because they're not a member of any queue.
Jul  6 17:11:36 DEBUG[11748] channel.c: Avoiding initial deadlock for 'Local/4461@user-2fcf,2'
By: Serge Vecher (serge-v) 2006-09-06 09:29:14

astonmartin, petergg: can you please try the latest 1.2 branch (r>42000) and see if this issue still persists?
By: petergg (petergg) 2006-09-06 09:38:29

thx, i'll test it monday.
By: Serge Vecher (serge-v) 2006-09-27 13:47:58

Monday has come and gone ... If the problem still persists in 1.2.12.1, please reopen the issue...