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):
- Ext 2093 calls Ext 2094
- Ext 2094 hits Transfer and dials “2095”
- Ext 2095 rings and shows “Ext 2094” is calling
- While it is ringing, Ext 2094 hangs up, to complete the transfer
- Ext 2095 still shows Ext 2094 calling (it should show Ext 2093)
- 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