Does not update the Caller ID on Attended transfer if destination no answer


(avl) #1

With freepbx 14.0.13.4 and asterisk 16.4.1 when we try to make an semi attended trasfer (A call B and B make attended transfer call to C and without answer from C the Β party make transfer A to C) the C party see B and not the A. On the attended transfer with answer from C and pickup feature the refresh caller id working properly.
The phone are yealink with pai-from for the refresh caller id and for the extension in the Freepbx is PAI in the Send RPID field and the trust RPID is yes. We have trying also with cisco phones with rpid settings without any difference.
is it something we have missed?
Many thanks.


(avl) #2

Hello,
to be more clear with Freepbx 12.0.76.4 - asterisk 11.18.0 the semi attended transfer works properly.
We made an upgrade with fresh install Freepbx 14.0.13.4 - asterisk 16.4.1 and the feature doesn’t work. The C party cannot see the A party after transfer which is the real device in conversation.
After that we made a fresh install Freepbx 12 and the feature works.

Just for note with different distro with asterisk version 13.22.0 with only set the send rpid = PAI for each extension the semi attended transfer works properly (Caller Id has been updated).

We have tested with chan_sip and 5060 port on sip.

Many thanks.


(Dave Burgess) #3

Unless someone else has found and figured out what options changed, I’d suggest that this is an Issues Ticket.

From my perspective, I’m not sure that the new performance isn’t wrong - it could be a feature request/new interpretation of some requirement that’s causing the issue. If that’s the case, there should probably be an option to turn on the “old” effect. Either way, if it is actually a bug, it seems like an Issues Ticket would be appropriate.


(christrati) #4

I believe you’re describing the same issue I’m experiencing with our PBXact setup. I actually opened a ticket back in Oct 2018 (Sangoma Ticket #840804) about the issue. This February (Feb 22, 2019) I opened another ticket better describing the issue (Sangoma Ticket #876462). It took some time, but the Sangoma tech was able to reproduce the issue. He then opened an internal ticket with Asterisk about the issue, below is the last comment I received about the ticket on Aug 2019:

“I have submitted JIRA # FREEI-683 for this. I will keep you updated as I hear back from engineering. Since JIRAs created by us are now classified as internal, links to them are not accessibly to outside our network.”

Previously, when I found an asterisk bug @lgaetz worked with me and get captured the appropriate asterisk log info and escalated it and it was fixed in a month or two.

Just to clarify the issue, this is with semi-attended transfers and specifically the caller-ID not updating. In our situation, we came from a Toshiba PBX and the only way to transfer any call was semi-attended. In this case, once you upgrade past Asterisk 13.22.0, the caller-ID will not update. In fact, if you use PJSIP on Asterisk 13.22.0, it will break.

We’re using primarily Yealink phones (T41S and T46S), along with about 70 Sangoma phones (S400, S705). This happens with any of the phones. I had to change all of the phones to chan_sip in order for the warm or semi-attended transfers to work correctly. I would like to change to PJSIP in the future; however, this is a show stopper for our organization.

Here’s the callflow that reproduces the issue, for clarification (it only matters if the last endpoint is using chan_sip. The final person to receive the call has to be on Asterisk 13.22.0 and use chan_sip. The prior numbers can use PJSIP, but the last person to receive the call has to be chan_sip):
Here is a workflow example of what I’m doing to perform a warm transfer or a “semi-attended” transfer, using a newer version of Asterisk (at the time, Asterisk 13.25 or Asterisk 16.2):

  1. Ext 2093 calls Ext 2094
  2. Ext 2094 hits Transfer and dials “2095”
  3. Ext 2095 rings and shows “Ext 2094” is calling
  4. While it is ringing, Ext 2094 hangs up, to complete the transfer
  5. Ext 2095 still shows Ext 2094 calling (it should show Ext 2093)
  6. Ext 2095 answers the call and it still shows Ext 2094, rather than Ext 2093

When I revert to asterisk 13.22, and perform the same steps, after step 4, on Step 5, the caller ID will update and show “Ext 2093”.

I haven’t heard any further updates to the internal ticket. If I receive any updates, I’ll sure post to this thread.

Chris