Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Transfer loses calls.

Discussion in '3CX Phone System - General' started by ccomley, Apr 3, 2014.

Thread Status:
Not open for further replies.
  1. ccomley

    Apr 6, 2011
    Likes Received:
    Ok, free mars bar to anyone who can crack this one, it seems to be baffling the egg-heads at 3CX Towers.

    Incoming call from Sip Trunk is fielded by receptionist.

    She speaks to the caller and then makes an attended transfer to Extension 2345

    User at 2345 isn't there, the call starts to go to VM, so the receptionist aborts the transfer attempt.

    Receptionist speaks to caller again and establishes his secondary preference, and starts an attended transfer to 3456

    As SOON as she presses the TRFR key, the call is gone.

    It does appear to be a factor that the first attempted transfer went to VM, BUT if the receptionist has then retrieved the call, not completed the transfer, surely that should not be a factor. If she abandons the transfer and goes back to the caller BEFORE the first extension goes to VM, it never happens. As it is, it only "sometimes" happens. But often enough the customer is getting Quite Cross.

    UNLESS - and I don't see how but - unless somehow the receptionist returning to talk to the caller *hasn't* ceased the first attempted transfer and so when she presses TRFR again, that's seen by the system as the *completion* of the original attended transfer.

    (If it matters
    - 3CX V12 - latest SP *not* yet applied
    - Receptionist uses a Yealink T.46G
    - Sip Trunk is from Gamma. 3CX have reminded me this is an "unsupported" supplier but frankly, the customer is more likely to chuck 3CX and go Asterisk than they are to change Sip Trunk, the deal is too good.

    There's also an ISDN trunk (Patton gateway) and I'm wondering if I should try forwarding the sip trunk to that and see if the problem persists when the incoming call is via ISDN.
  2. ian.watts

    ian.watts Active Member

    Apr 8, 2011
    Likes Received:
    Pull up the call log, verbose, for that call number.
    Interested to see where the BYE is being initiated.. and from which leg (trunk to PBX, PBX to <somewhere?>...).

    That may shed a bit of light on where the transfer is "dropping" the call.
    Agreed, I am doubtful the trunk is dropping their leg first.. unless it's Broadvox, but that's a different story. ;)
Thread Status:
Not open for further replies.