Transferred Calls connect to another on hold Call

[eberly]

Hi,
I'm just beginning to diagnose this, but I'm wondering if anyone else has any experience with Transferred calls being connected to another incoming caller on hold? Users are performing Attended Transfers on Yealink T26 and T22's. 3CX V.9 with all latest updates (as of 9/1/10), Patton Smartnode 4114 FXO Gateways.

Problem happens 3-4 times a day.

I'll post logs later on when I narrow down the exact section - just looking for "first thoughts".

 

[RichardCrabb1]

Re: Tranfserred Calls connect to another Incoming Call

It looks to me like a timing issue when using incoming analogue lines in a "bothway" scenario. If you only have a few calls you won't see the problem. However, if there are lot of calls this will happen.

Here is what happens: Attempt to transfer call externally, the patton does not know that an incoming call is about to take place on a particular port. An incoming call happens just after the line is about to be used for an outgoing call. The incoming call permits this confusion. You could get around this by making the last line of the inbound group the first choice for outbound calls.

Would this help?

Kind regards
Richard Crabb

 

[eberly]

Re: Tranfserred Calls connect to another Incoming Call

Richard,
That would make sense, but I don't believe that is what's happening.

I may not have been very clear, but is occurs when an incoming, external caller is transfered between internal extensions. The person being transferred is connected to a caller who have been placed "on hold" by another station.

I haven't been able to pinpoint whether they are connected to callers on hold by the Target Extension, or just random extensions.

We do not utilize "Call Parking", just Hold and Transfer (unless the Yealink treats Hold/Transfer as Parking automatically).

Also, probably irrelevant, but I said T22 and T26's - it's acually T22 and T28's.

 

[dwaine]

I have this same problem. We have a Patton 4114 as well and it happens when calls are transferred to parking lots. Did you ever figure it out?

 

[eberly]

No, I never resolved this. I'm leaning towards the possibility of user error... though that's really just a shot in the dark. Note: We were not utilizing parking of any sort (at least not explicitly) - just attended and blind transfers.

The ONLY change that I made (for testing) was to update firmware on 1 of my 3 Patton 4114's. The other 2 are on stock factory firmware, but the one (that handles mostly outgoing calls) I updated to the latest available on Patton's site.

Good luck - let me know if you figure this out.