[Home]

Summary:ASTERISK-05807: Transferred phone calls from AgentCallbacklogin drop 50% of the time.
Reporter:Geoff Oakham (goakham)Labels:
Date Opened:2005-12-09 10:59:12.000-0600Date Closed:2006-05-09 09:40:32
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_agent
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dropped_transfer_annotated.txt
( 1) dropped_transfer_clean.txt
Description:We've found phone calls taken by agents in a queue drop 50% of the time when they attempt to transfer them to someone else.  The console looks exactly the same during a successful transfer.  During a successful transfer the caller hears hold music the first time the 'transfer' button is pushed on our hardware sip phones.  On a "doomed transfer", the first sign of trouble is the lack of hold music: the caller hears nothing and his/her call remains active but "lost" until they hang up.

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

I'm using chan_agent.c from the 1.2 branch, but the rest of * is a stock 1.0.8 build.  This problem has been reported on the mailing list several times.  The most detailed was on May 10, 2005 by Eric Wieling.  I caught up with him on #asterisk Dec 9th, 2005 and he mentioned: "That's been a problem for at least 6 months.  Report it as a bug. / We stopped using AgentCallbackLogin because of this issue."

We are using Polycom phones, but they currently don't appear to be the source of the problem.  I'd be happy to help isolate and correct the problem in any way I can.. please feel free to ask.
Comments:By: Serge Vecher (serge-v) 2005-12-09 12:22:01.000-0600

Do Polycom's have SIP firwmare? If so, you need to do a SIP trace capture of a doomed-call happening. To do this, at CLI type:

set debug 4
set verbose 4
sip debug

when enough is captured:
sip no debug

Post the results here as an attachment
By: Geoff Oakham (goakham) 2005-12-12 14:30:57.000-0600

Here you go.. sip debug logs of a failed transfer.  I've done a very quick cleanup (removing some of the information that isn't relevent) but this is more or less untouched.

The original caller is (905)843-1234, which is answered by Agent/329 at extension 329, who attempts to transfer it to extension 328.
By: Serge Vecher (serge-v) 2005-12-12 15:17:18.000-0600

goakham: please identify "who is who" in the logs. Also, looks like this needs an attention of a sip-expert.
By: Geoff Oakham (goakham) 2005-12-12 16:48:46.000-0600

I've paired down the logs.. and put in a few notes.  (Any line starting with ';' is a comment I've added.)
By: Geoff Oakham (goakham) 2005-12-15 10:24:18.000-0600

Is there any other information I could provide to help find this bug?
By: Peng Yong (ppyy) 2005-12-26 06:44:57.000-0600

i test this issue with SVN-branch-1.2-r7608M. i dial to the agent and transfer to a extension. i have no problem after about 20 transfer.

here is extension i transfer to.

exten => 2233,1,Playback(testfile)
exten => 2233,n,Goto(1)
By: Geoff Oakham (goakham) 2005-12-28 08:56:52.000-0600

Just to make sure we're on the same page:

* is the agent logged in as 'AgentCallbacklogin'?
* is the agent using a SIP phone?
* is the SIP client hardware or software?
By: Peng Yong (ppyy) 2005-12-28 09:14:44.000-0600

* is the agent logged in as 'AgentCallbacklogin'?
yes

* is the agent using a SIP phone?
x-lite soft phone

* is the SIP client hardware or software?
x-lite soft phone
By: Geoff Oakham (goakham) 2006-01-03 08:49:27.000-0600

I'll be honest, I've found it extremely difficult to reproduce this bug.. yet it happens [apparently] several times a day.  Is there any other debugging information you would like me to collect the next time this happens?

I remember reading this doesn't happen if Agents are permanent members of the queue.
By: Mark Spencer (markster) 2006-02-11 10:53:26.000-0600

Polycom seems to kill the call...  Have you tried using "#" transfer instead of the transfer button?
By: Juan Pablo Abuyeres (jpabuyer) 2006-02-13 06:45:30.000-0600

This is a little OffTopic, but if that works, is there a way to disable -or make unusable- the transfer button of polycom telephones on the asterisk server?
By: Geoff Oakham (goakham) 2006-02-15 12:40:46.000-0600

I've asked around and we're willing to give the #-to-transfer method a try.

It could easily be the Polycom's fault.  However, supposing the # transfer works, how come the other one doesn't?  I mean, we use the transfer button internally and it works in every other situation except for queue calls.

Have you been able to figure anything out from the SIP dump?

I've notied that the Polycom phone doesn't "kill" the call, so much as "loose it" leaving the caller on hold indefinately.  Does that help?
By: Serge Vecher (serge-v) 2006-02-15 13:17:00.000-0600

goakham: did you try using another UA to see if it's Polycom's fault or not? Try Cisco IP phone with SIP firmware, a Snom or a softphone like X-lite
By: vortex_0_o (vortex_0_o) 2006-02-16 02:45:29.000-0600

prob doesn't help but in my case it seems to be ok.

agent numbers and sip phones on different 'extensions'
phones are 1000-1999 and agents 2000-2999

I am using svn 1.2 branch
1.6.3 of poly firmware (is generally available) (1.6.4 current)
By: Serge Vecher (serge-v) 2006-05-01 14:48:25

goakham: did you to replicate this problem with other SIP phones? Is this still an issue with 1.2.7.1?

for the record: note deleted was duplicate of 0041347 by vortex_0_o
By: Serge Vecher (serge-v) 2006-05-09 09:40:32

no response from reporter -- closing this issue. If you are able to reproduce the problem, please reopen with updated debug information from a recent 1.2 branch. Thanks.