Blind transfer bug introduced or working as intended?

[efounco]

When you blind transfer a call from one extension to another, the BLF indicator light doesn't turn back to green on the phone it was transferred from until the call is either picked up or dropped. The call transfers just fine, but it appears that the extension is busy on other BLFs in the office. This is causing a bit of confusion when transferring to an extension that may ring for a long time (i.e. external numbers). Is this a feature to help slow down the chaos or simply a glitch in SP4? We've reverted back to SP3 in the meantime and it doesn't exhibit this behavior.

 

[efounco]

Re: Bug or feature in 3CX V10 SP4?

By the overwhelming responses to my question, I'm assuming this is a known bug in SP4. Basically, any time you blind transfer a call, whether it be to an external number, shared park, another extension or voice mail, the extension from which it was transferred from will stay busy until the call is picked up. While it doesn't seem like a huge issue, imagine a scenario in which the user has set their mailbox up to ring for 120 seconds because they are on a mobile phone. When a call is transferred to that extension and goes unanswered, the extension from which it was transferred from will remain "busy" for 2 minutes and will unable to receive incoming calls from the queue.

 

[MichaelB_3CX]

Re: Blind transfer bug introduced in 3CX V10 SP4

Hi,
You have answered your own post. This is not a bug neither a glitch.
This is the correct behavior.

Thanks and Regards

 

[efounco]

Re: Blind transfer bug introduced in 3CX V10 SP4

Thanks for the confirmation on this; I just discovered it myself.

After further testing, it appears that even though the light turns green with 3CX SP3, the extension doesn't actually become available for an incoming call until the transfer has completed. So, SP3 gives you the illusion that that the call was transferred and is ready for an incoming call, but in actuality SP4 is just reporting the status of the line properly.

 

[MichaelB_3CX]

Re: Blind transfer bug introduced in 3CX V10 SP4

Exactly, it was a known issue coming from previous versions and now it is fixed in SP4.
Thanks again.

 

[SY]

Re: Blind transfer bug introduced in 3CX V10 SP4

You (user) can forget about a call which is transferred "blindly". All the phones allow it. (The hint - put handset on hook or press button which terminates the call)
"Huge/known bug", "glitch" is not a suitable definition for this behavior...
If you have any suggestions how to improve this procedure then please pay a visit to ideas.3cx.com and post it

Thanks

 

[efounco]

Re: Blind transfer bug introduced in 3CX V10 SP4

Well, here's the dilemma; what am I doing wrong? How can I speed things up?

A call comes in from the T1 trunk and goes into the queue. The queue is setup to ring all extensions that are logged into it. An operator answers the call and transfers it using a BLF key on the Cisco SPA500S. The call is transferred successfully, but the operator's line stays busy and cannot answer another call from the queue until the previous call has been answered or dropped.

We are using Cisco SPA504G w/500S sidecars. I've tried firmware revisions 7.4.6, 7.4.7, 7.4.8a, 7.4.9a and 7.4.9c. Both SP3 and SP4 exhibit this symptom with transferring calls.

While having to wait an extra 20 seconds to take a call doesn't seem like a big deal, you have to realize that we have only a single operator logged into the queue at times and multiple people in the queue. Also, some of our extensions are setup to dial outside number. In those instances, the operator might have to sit there and wait for 2+ minutes (twiddling their thumbs) before the call is completed or dropped and another call comes in from the queue. Is that normal?

 

[rayfield]

Re: Blind transfer bug introduced in 3CX V10 SP4?

During this time that the operator's 'line' is busy, can he/she not make any outgoing calls either?

When I duplicate this scenario on a Grandstream GXP2010, a softkey becomes available, after I've transferred the call to another extension, or transferred it to a Shared Parking 'space', to "End Call". Pressing that key disconnects my Grandstream phone from the 'connection' and it can then be used to place or receive another all, immediately. I think the Yealink phones work the say way (or very similar).

John Rayfield, Jr. CETma

 

[efounco]

Re: Blind transfer bug introduced in 3CX V10 SP4?

Ignore what I said about parking lots and voice mail. The problem primarily exists when you blind transfer a call from one extension to another. With some VOIP systems, when you blind transfer a call, the line status immediately returns to "available", and the VOIP software/system handles the transfer. With 3CX, when you blind transfer a call, the line status stays "busy" until the transfer has completed (more like an assisted transfer). Because the 3CX queue system doesn't allow for multiple incoming calls per extension, it becomes highly inefficient for distributing calls in the scenario I have provided.

 

[nbailey]

For my suggestion I am going to ignore everything else said in this thread and offer a suggestion to your problem, again ignoring everything else said.

504G with sidecar. Setup a second extension on the phone and allow said operator to log into the queue with two extensions and/or one extension in the queue second extension for transfers, meaning park the call that comes into the queue, means the queue extension is now free, second extension on the same handset unparks and then transfers the call, now only the second extension is "tied up for 20 seconds or so" meanwhile the main queue extension is still being polled all from the same handset.

Just food for thought.

Thanks,
Nate

 

[fthomas_mcallen]

Hi. I know this is an old thread, but I was shocked to see that this is "correct behavior." This basically makes call queues unusable. No one can afford to have queue agents being idle for 20 seconds after each incoming call is transferred to a target extension. It is like setting money on fire. Very surprised to see V12 SP6 still exhibits this behavior. This one bug, and yes it is a bug, whether 3CX admits to it or not, negates all of the cost savings that make 3CX attractive because of lost agent productivity. I hope this is changed, because otherwise 3CX is a very attractive option for us.

 

[jj1]

Hi,

We have exactly the same issue with Yealink Phones and 3CX Call Queues. As an example the Yealink T46GN is not releasing call on blind transfer until answered/timed out at the other extension and this seriously delays new queue calls from reaching the Agent (20-30 seconds sitting idle)

The behaviour only seems to occur with Yealink phones, I have tested using a Snom 870 and the 3CX SoftPhone which release the call straight away and the next call queue can come straight to the Agent.

I have posted on the Yealink forum under an existing thread so please can you add to that and this thread if you are having the same issue.

[T21P] Problem with Blind Transfer - http://forum.yealink.com/forum/showthread.php?tid=4170&pid=16614#pid16614

 

[jj1]

Yealink have been really helpful in regard to this strange behaviour and after sending some traces from Snom and Yealink phone they have now released a new T46G Firmware (28.80.0.72.rom) that changes the blind transfer behaviour to match what we see with the Snom phones.

We've tested with only one agent logged into the call queue and as soon as we blind transfer the first call the second call comes straight in now.

Great job Yealink