Hello I have a strange problem that is driving me crazy and I cannot find the solution.
The call scenario is :
I make a call that is coming to my extension ex. 201 → I transfer the call to extension 202.
At this point the 202 screen has the information of the initial caller. When I put on hold the call and peek the call again (unhold) the screen of the 202 shows as caller num the 201.
I have tried with the attended and blind transfers and both have the same result. The extensions are both pjsip and the inbound call comes from an iax trunk.
Are these SIP native, or FreePBX feature code. These handle caller ID differently. In particular, for native SIP attended transfer (including blind transfers implemented as attended transfers which are automatically completed), the new channel is set up without knowledge of the original call.
The transfer is made through the 201 extension with the button or the softkey and the 201 extension is configured from the EPM with the blind transfer option (but I have tested the attended also).
And the problem is that when the call is fully transfered at the 202 extension is that I can see the initial caller successfully. When I hold the call I can still see the initial caller. When I unhold the line then the 201 caller id is displayed.
“peek” is the wrong word here. I originally thought you were parking the call, but I’m not so sure now.
In any case, I think you need to provide a full, verbose log (from the file not the screen, please), with “pjsip set logger on” in effect. Please also give the make and model of phone. Also the versions of Asterisk and FreePBX.
As I’ve already hinted, transfers can be done in more than one way, and are dependent on the phone. Also EPM may handle different phones in different ways.
My guess is that this is a problem in the use of connected line updates, to override the initial caller ID, and may be an Asterisk issue, but one really needs to see what is being sent over the wire and whether connected line update operations are being attempted, in order to be clear what is happening.
The phone appears to be doing a native SIP attended transfer in the early media stage of the new call leg. The initial caller ID is that of the transferor, as Asterisk has no idea, at first, that this is a transfer.
The REFER is done during early media, which means either that it is the phone simulating blind transfer, or the transferring person initiated completion the moment they heard ring back.
Asterisk has use UPDATE, as the phone allows this, to change the connected line to the IAX line, still in early media. It does this with a P-Asserted-Identity header.
After answer, the destination does an a=sendonly hold followed by an a=sendrecv unhold. Asterisk doesn’t add P-Asserted-Identity to either of these.
I’m not sure of the correct protocol for handling connected line updates, so I’m not sure if PAI has to be repeated on all subsequent INVITEs, putting Asterisk at fault, or whether the UAS (phone) is expected to hold onto the last PAI value it received, putting it at fault. I’d say one of them is at fault. It is also possible that the RFCs are not adequately tightly specified.
Note that, if Asterisk is at fault, a bug report will not be accepted against version 16.x, as it no longer receives non-security related fixes. You will need to reproduce against the latest 18 or 20 version.
Good morning to all.
I made a test today using the feature code of blind transfer (##+extension) instead of the buttons of my phone (s705).
Now, the callerid doesn’t change on the final recipient.
I could use this to solve my problem, but the deployment is for a call center and it is crucial for me that the supervisor that transfers the call should first speak to the agent before the transfer is competed.(attended transfer).
I made a test with the feature code of the attended transfer (*2) and the result is that the callerid is altered.
I upgraded to 18.16.0 asterisk and I updated all the modules of the Freepbx to the latest.
The callerid doesn’t change upon holding and unholding.
I will make more tests today and I will come back if I find anything else.
For now, the upgrade of the asterisk version is the solution to my problem.