Blind transfer from analog phones fails

Discussion in '3CX Phone System - General' started by aabramov, Jun 10, 2013.

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

    Joined:
    Jun 10, 2013
    Messages:
    4
    Likes Received:
    0
    Hello all,

    We just recently rolled out our 3CX v11 based system.
    We are using Yealink T20p phones, but some are analog cordless, connected by means of an AudioCodes MP-124 FXS ATA.

    The cordless phones don't have a transfer button, so we use the flash button.
    The problem is that the transfer never happens. The operator waits until she hears the dial tone and then hangs up. This drops both calls.
    Using the IP phones flash button results in the same behavior.
    For some reason, transferring to a Yealink T22p works fine. I checked settings and didn't find any differences between the T22 and T20's that seemed probable.

    Our Setup:
    3CX v11, up to date on all service packs
    Windows 7 machine
    Yealink T20p phones
    1 Yealink T22p phone
    AudioCodes MP-124 FXS ATA. (for analog cordless phones)
     
  2. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    Sorry, but your description is a little confusing to follow. I understand that you are using some Yealinks in addition to the analog cordless phones which are also using an MP ATA. What is lacking is the sequence of events and how performed. Lacking further detail, I am uncertain if what you want to happen is possible.

    Where the confusion comes into play is that you indicate:
    "The operator waits until she hears the dial tone and then hangs up. This drops both calls." The operator is using a cordless analog phone? How did either call get to the operator using the analog cordless? How did she manage to answer both calls? Why would she hang up upon hearing dial tone? I assume that a call would come in and be answered. Then, upon learning that a transfer is needed, would hook flash, get a dial tone and then dial the number to where the call is to be transferred. Then, upon hearing the ring or the far end phone being answered, would then hang up so as to try and keep the connection between the originator and destination parties alive.

    You then state:
    "Using the IP phones flash button results in the same behavior". Why would you not use the "transfer" button if that is the function you wish to perform?

    If you can provide the details, perhaps we can help. Also, why an Audiocodes ATA? I don't think this is a supported device; not that it won't or can't work, but is likely not as well used by most using 3CX so if a solution resides with the ATA, the prospect of getting to same is less likely,.
     
  3. aabramov

    Joined:
    Jun 10, 2013
    Messages:
    4
    Likes Received:
    0
    My apologies,

    The operators do a lot of roaming around the office and therefore need cordless phones. We tried to stick with what we had before switching to 3CX (from FreePBX) which is analog cordless phones connected to the system by means of an AudioCodes ATA. I understand that AC is not supported, but it works fine (at least for all other features)

    Here is what we are trying to do
    When the call comes in to the Operator (O), either from an outside line or inside the PBX, and the O needs to transfer the call, they follow these steps:
    1. Press the Flash button to get dial-tone (The Caller (C) is put on hold).
    2. Dial the Destination extension (D)
    3. As soon as they hear a ringing tone, they hang up.

    When using other analog phones, this causes D and C stay in conversation while O is out of it. However, with these cordless phones, this cancels the call and all 3 (O, C and D) get disconnected.

    The only way to make the transfer work, is to wait until D picks up the phone (or it rolls to VM), then O can leave the conversation and it will continue without her
     
  4. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    OK, now I understand. I do not profess to have an answer for the moment. I think the issue lies within how the system interprets the hang-up (from the analog) given the current configurations. My guess is that the system is interpreting the hang-up before the answer as a cancel; no different than if you dialed an extension using an IP phone and hung-up before someone on the other end physically got the phone off-hook.

    What I suggest is that you place a call and look at the logs using both an IP phone and one of the analog phones and compare the results of how the system handled using the logs. Place both calls the same and to the same remote extension so as to eliminate as much variability as possible. Many adapters use a code after the hookflash so as to define the action desired (call forward, transfer, etc.). This is what I was able to glean from the MP manual regarding a transfer -

    " Consultation Transfer (REFER and REPLACES):
    The common way to perform a consultation transfer is as follows:
    In the transfer scenario there are three parties: Party A = transferring, Party B =
    transferred, Party C = transferred to.
    • A Calls B.
    • B answers.
    • A presses the hook-flash and puts B on-hold (party B hears a hold tone).
    • A dials C.
    • After A completes dialing C, A can perform the transfer by on-hooking the A
    phone.
    • After the transfer is complete, B and C parties are engaged in a call.
    The transfer can be initiated at any of the following stages of the call between A and
    C:
    • Just after completing dialing C phone number - transfer from setup.
    • While hearing Ringback – transfer from alert.
    • While speaking to C - transfer from active.


    This is what the log will hopefully show and then perhaps some change can be made.
     
  5. aabramov

    Joined:
    Jun 10, 2013
    Messages:
    4
    Likes Received:
    0
    lneblett,

    Thank you for your reply.
    Here is what I did
    A (ext 575) calls B (ext 506)
    B transfers to C(ext 540)
    The system sees this as to separate calls. The logs are below. I can also get verbose logs if it'll be more helpful
    The log for successful transfer is in next post

    12-Jun-2013 09:17:20.668 Leg L:1397.1[Extn] is terminated: Cause: BYE from PBX
    12-Jun-2013 09:17:20.667 [CM503008]: Call(C:1397): Call is terminated
    12-Jun-2013 09:17:20.666 Leg L:1397.2[Extn] is terminated: Cause: BYE from 192.168.1.61:5060
    12-Jun-2013 09:17:20.633 Leg L:1397.3[Extn] is terminated: Cause: 487 Request Terminated/INVITE from 10.10.20.109:5062
    12-Jun-2013 09:17:20.632 [CM503003]: Call(C:1397): Call to <sip:540@10.10.20.2:5060> has failed; Cause: 487 Request Terminated/INVITE from 10.10.20.109:5062
    12-Jun-2013 09:17:20.624 NAT/ALG check:L:1397.1[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:17:08.634 NAT/ALG check:L:1397.1[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:17:08.491 NAT/ALG check:L:1397.2[Extn] REQUEST 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:17:05.552 [CM503007]: Call(C:1397): Extn:506 has joined, contact <sip:506@192.168.1.61:5060>
    12-Jun-2013 09:17:05.551 [CM503007]: Call(C:1397): Extn:575 has joined, contact <sip:575@10.10.20.4:5060>
    12-Jun-2013 09:17:05.549 L:1397.2[Extn] has joined to L:1397.1[Extn]
    12-Jun-2013 09:17:05.548 NAT/ALG check:L:1397.2[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:17:02.983 [CM503025]: Call(C:1397): Calling T:Extn:506@[Dev:sip:506@192.168.1.61:5060] for L:1397.1[Extn]
    12-Jun-2013 09:17:02.934 [CM503027]: Call(C:1397): From: Extn:575 (<sip:575@10.10.20.2:5060>) to T:Extn:506@[Dev:sip:506@192.168.1.61:5060]
    12-Jun-2013 09:17:02.934 [CM503004]: Call(C:1397): Route 1: from L:1397.1[Extn] to T:Extn:506@[Dev:sip:506@192.168.1.61:5060]
    12-Jun-2013 09:17:02.932 [CM503001]: Call(C:1397): Incoming call from Extn:575 to <sip:506@10.10.20.2:5060>
    12-Jun-2013 09:17:02.931 NAT/ALG check:L:1397.1[Extn] REQUEST 'INVITE' - basic check passed. No information for extended checks


    12-Jun-2013 09:17:20.541 Leg L:1398.1[Extn] is terminated: Cause: BYE from PBX
    12-Jun-2013 09:17:20.495 [CM503008]: Call(C:1398): Call is terminated
    12-Jun-2013 09:17:13.785 [CM503025]: Call(C:1398): Calling T:Extn:540@[Dev:sip:540@10.10.20.109:5062] for L:1398.1[Extn]
    12-Jun-2013 09:17:13.735 [CM503027]: Call(C:1398): From: Extn:506 (<sip:506@192.168.1.212:5060>) to T:Extn:540@[Dev:sip:540@10.10.20.109:5062]
    12-Jun-2013 09:17:13.735 [CM503004]: Call(C:1398): Route 1: from L:1398.1[Extn] to T:Extn:540@[Dev:sip:540@10.10.20.109:5062]
    12-Jun-2013 09:17:13.734 [CM503001]: Call(C:1398): Incoming call from Extn:506 to <sip:540@192.168.1.212:5060>
    12-Jun-2013 09:17:13.733 NAT/ALG check:L:1398.1[Extn] REQUEST 'INVITE' - basic check passed. No information for extended checks
     
  6. aabramov

    Joined:
    Jun 10, 2013
    Messages:
    4
    Likes Received:
    0
    In this case, I called an IP phone, and used its transfer button. (TRAN ext TRAN)

    A (ext 575) calls B (ext 549)
    B transfers to C(ext 540)
    As you can see here this is all one call.

    12-Jun-2013 09:22:46.166 Leg L:1400.4[VMail] is terminated: Cause: BYE from PBX
    12-Jun-2013 09:22:46.166 [CM503008]: Call(C:1400): Call is terminated
    12-Jun-2013 09:22:46.165 Leg L:1400.1[Extn] is terminated: Cause: BYE from 10.10.20.4:5060
    12-Jun-2013 09:22:44.715 Leg L:1400.3[Extn] is terminated: Cause: 487 Request Terminated/INVITE from 10.10.20.109:5062
    12-Jun-2013 09:22:44.714 [CM503003]: Call(C:1400): Call to <sip:540@10.10.20.2:5060> has failed; Cause: 487 Request Terminated/INVITE from 10.10.20.109:5062
    12-Jun-2013 09:22:44.689 Leg L:1400.2[Extn] is terminated: Cause: BYE from 192.168.1.30:5062
    12-Jun-2013 09:22:44.673 NAT/ALG check:L:1400.1[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:22:44.535 [CM503007]: Call(C:1400): VMail:999 has joined, contact <sip:999@127.0.0.1:40600>
    12-Jun-2013 09:22:44.532 L:1400.4[VMail] has joined to L:1400.1[Extn]
    12-Jun-2013 09:22:44.532 NAT/ALG check:L:1400.4[VMail] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:22:44.418 [CM503025]: Call(C:1400): Calling T:VMail:999@[Dev:sip:999@127.0.0.1:40600;rinstance=6c6cd3e7fe6b8f19] for L:1400.1[Extn]
    12-Jun-2013 09:22:44.362 [CM503005]: Call(C:1400): Forwarding: T:VMail:999@[Dev:sip:999@127.0.0.1:40600;rinstance=6c6cd3e7fe6b8f19]
    12-Jun-2013 09:22:44.362 L:1400.1[Extn] forwards call from Extn:540 to VMail:999 based on rule Fwd[Available/NoAnsw]
    12-Jun-2013 09:22:44.362 L:1400.1[Extn] failed to reach Extn:540, reason No Answer
    12-Jun-2013 09:22:29.328 [CM503025]: Call(C:1400): Calling T:Extn:540@[Dev:sip:540@10.10.20.109:5062] for L:1400.1[Extn]
    12-Jun-2013 09:22:29.273 [CM503027]: Call(C:1400): From: Extn:575 (<sip:575@10.10.20.2:5060>) to T:Extn:540@[Dev:sip:540@10.10.20.109:5062]
    12-Jun-2013 09:22:29.273 [CM503004]: Call(C:1400): Route 1: from L:1400.1[Extn] to T:Extn:540@[Dev:sip:540@10.10.20.109:5062]
    12-Jun-2013 09:22:26.052 NAT/ALG check:L:1400.1[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:22:25.925 NAT/ALG check:L:1400.2[Extn] REQUEST 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:22:23.008 [CM503007]: Call(C:1400): Extn:549 has joined, contact <sip:549@192.168.1.30:5062>
    12-Jun-2013 09:22:23.007 [CM503007]: Call(C:1400): Extn:575 has joined, contact <sip:575@10.10.20.4:5060>
    12-Jun-2013 09:22:23.005 L:1400.2[Extn] has joined to L:1400.1[Extn]
    12-Jun-2013 09:22:23.005 NAT/ALG check:L:1400.2[Extn] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks
    12-Jun-2013 09:22:21.940 [CM503025]: Call(C:1400): Calling T:Extn:549@[Dev:sip:549@192.168.1.30:5062] for L:1400.1[Extn]
    12-Jun-2013 09:22:21.934 [CM503027]: Call(C:1400): From: Extn:575 (<sip:575@10.10.20.2:5060>) to T:Extn:549@[Dev:sip:549@192.168.1.30:5062]
    12-Jun-2013 09:22:21.934 [CM503004]: Call(C:1400): Route 1: from L:1400.1[Extn] to T:Extn:549@[Dev:sip:549@192.168.1.30:5062]
    12-Jun-2013 09:22:21.932 [CM503001]: Call(C:1400): Incoming call from Extn:575 to <sip:549@10.10.20.2:5060>
    12-Jun-2013 09:22:21.931 NAT/ALG check:L:1400.1[Extn] REQUEST 'INVITE' - basic check passed. No information for extended checks
     
Thread Status:
Not open for further replies.