I’ve recently encountered an issue on FreePBX 17 with transferring intercom calls (blind transfer). I originally thought it was an issue with the phone itself, but then found it to be caused by the PBX instead.
Here’s what happens:
Extension 1202 dials *801203 which calls Ext. 1203 in intercom mode.
Extension 1203 auto-answers the intercom call and the call is connected.
Extension 1202 executes a blind transfer by pressing the Trans softkey, then dialing 1204 to transfer to Ext. 1204 without the *80 intercom prefix and then presses the B Trans softkey.
Extension 1202 completes the blind transfer and the call disappears from the screen. The call is no longer associated with 1202. Extension 1203 hears a ringout sound.
Extension 1204 does not ring but instead auto-answers the call as if it were an intercom call, however, the transfer did not include Ext. 1202 dialing *80 prefix before 1204.
It appears that when FreePBX sees Extension 1202 dial 1203 in an intended intercom call, it retains that intercom call characteristic when 1202 transfers the call to 1204 causing 1204 to auto-answer. This does not happen with an attended/semi-attended transfer.
This also occurs with Call Queues, if the intercom call is transferred to a call queue, an extension in the queue automatically answers instead of ringing normally.
Is this normal FreePBX functionality? Is there a way to disable this? When I realized this it was quite confusing, especially with it happening with transfers to call queues. Thanks.
What does the trans key do? There are at least three ways of doing a blind transfer on an answered call:
Asterisk feature code.
SIP: REFER.
SIP: INVITE, followed by an automatic SIP REFER/Replaces.
Also, which channel driver are you using. chan_sip and chan_pjsip handle the setting of additional headers differently, and the autoanswer is triggered by an additional header. chan_sip is probably more likely to carry over the answer-after=0, although FreePBX complicates this, as I think it uses channel variables to control the code that actually sets the header, and those might carry over.
Hello, as far as I know, the transfer key does not do an Asterisk feature code and simply allows the user to dial an extension and either select B Trans or Send (attended transfer), which could use either SIP: REFER or SIP: INVITE with SIP REFER/Replaces as you mentioned, however, I am not entirely sure. Furthermore, I am using chan_pjsip on all the phones in my system.
I suspect you are doing a REFER, a that will set up the new call on the same channel, so is more likely to inherit the channel variables that indicates auto-answer.
As a general point, I think, in the absence of specific documentation on the behaviour, I would say that the behaviour when doing a blind transfer of an answer-after= call was undefined.
Thanks for the follow up. In that case, would SIP: Invite followed by an automatic SIP REFER/Replaces solve this issue? If so, how would I implement it, on the PBX or the (Yealink) phones themself? Thanks.
It has to be implemented on the phones. Some phones do it naturally. In practice it might be easier to train people to use an attended transfer and complete it without waiting for an answer.
I see, thank you for your help. I’ve taken a look at Yealink’s documentation and unfortunately it appears they only support the REFER method for transferring. I guess it should be fine then, the call does transfer in the end after all, just going to be a small quirk.
However, with intercom calls I have also ran into another separate, worse issue that could be related here, would you be able to help with that? Thanks.
I’ll merge that thread back here as we have some information to work with, and if someone has run into the same caveat or may know a solution, please feel free to answer:
I’ve been experiencing some issues with the intercom function of FreePBX 17 lately, one of which is attached in the link above. I have noticed that when an extension intercom calls another phone, and that phone picks up and does a blind transfer, the call instead of transferring gets disconnected entirely and the phone that did the transfer gets a “ghost call” (it says Recall) from the extension being transferred, but when the recall is picked up, that call immediately drops as well as the other extension being transferred had already been disconnected entirely.
This is a rather bizzare issue I have run across, is there an explanation or fix for this? This only happens on intercom calls, normal calls do not face this problem.
P.S. I have also tried this with a softphone that does the transfer to see if it was a phone issue, however, it yields the same result.
I suspect that this might be a clue to intercom part. You can’t answer a phone that was called in intercom mode as the effect of that mode is to force it to answer without human intervention. That may well mean that it is not being hung up.
During a SIP REFER transfer, the original session isn’t terminated but receives call progress information. Because the person on the phone that is requesting the transfer didn’t answer it, they may not explicitly hang it up. In that case the phone might well respond to feedback that the transfer failed by producing the “Recall” message that you observed.
I don’t have enough information to understand why the transfer failed, although a codec mismatch is possible. For that, and to get a better idea of why the middle phone thinks there has been a failure, I’d need the protocol logs.
Actually, it is even possible that the middle phone is treating a normal end of the call whilst it’s session is still up, as a recall.