Yealink Forums

Hi.

I have read many posts about this issue and have tried the proposed solutions to no avail.

I'm using a T19P (E2) phone and a T41P phone for the tests. So, the scenario is similar as described on other posts:
1. Incoming call to T19P
2. T19P answers
3. T19P makes a new call to T41P
4. T41P answers
5. T19P performs an attended transfer
6. Caller id shown on T41P's display still shows T19P data and does not update with the original incoming call caller id (name/number)

My first tests were on some of the 80s firmware versions, then I upgraded both phones to the latest 82, because the only documentation that confirmed the existence of the "refresh_remote_id" parameter was on the autoprovisioning template files of the version 82.

After provisioning both phones with this new parameter enabled (through autoprovision), I downloaded the configuration in order to check if the parameter was or wasn't configured, and it turned out that it didn't appear on the downloaded configuration. I tested in spite of this evidence, and of course it didn't work.

Since there is no documentation about what RFC this new parameter supports, it's even more difficult to make modifications on my system to satisfy Yealink phones limitations (for example RFC 5876 doesn't seem to be supported, and it would be of great help to use PAI on UPDATE requests instead of FROM).

I still haven't tested it on other phone models, but I need this to work on these.

Best regards.

Dear Customer,

For your description, if the phone receive the invite message or update message with refresh header via PAI, then you can configure the parameter below to let the phone read the caller id from the PAI firstly, and from FROM Secondly:
account.X.cid_source = 2
X means the account you want to use.

If still have probelm, please send the level 6 syslog, pcap and config.bin to me do further analysis.
Refer to the FAQ to collect the three files:
http://support.yealink.com/faq/faqInfo?id=707

Best Regards,
Lucia

First, thanks for the answer.

The documentation clearly states that it is ONLY for the INVITE request, and since it doesn't even mention reINVITEs, it can be assumed that it is just for the initial INVITE. In other words, the purpose of this parameter doesn't seem to be for the use in attended transfers scenarios, it is just another way to specify the caller details to the callee. The documentation says:

Quote:Caller ID source = PAI-FROM
1) The IP phone checks Privacy: id header preferentially, if there is a Privacy: id in the INVITE
request, the caller identification information will be hidden and the IP phone LCD screen
presents anonymous.
2) If there is not any Privacy: id header in the INVITE request, the IP phone checks and
presents the caller identification from the P-Preferred-Identity header.
3) If there is not P-Preferred-Identity header in the INVITE request, the IP phone checks and
presents the caller identification from the P-Asserted-Identity header.
4) If there is not P-Asserted-Identity header in the INVITE request, the IP phone presents the
caller identification derived from the FROM header.

According to Yealink answers on other forum threads, the parameter refresh_remote_pid is the one that should handle transfers, but it doesn't seem to be on the available firmwares and it's not documented.

The invite include the reinvite.
Please test the parameter first, if still have problem, we need you provide the level 6 syslog, config.bin and pcap trace for further analysis.

(02-02-2018 09:47 AM)Lucia_Yealink Wrote: [ -> ]The invite include the reinvite.
Please test the parameter first, if still have problem, we need you provide the level 6 syslog, config.bin and pcap trace for further analysis.

I only mentioned the reINVITE as an example of how unclear it is. Our PBX doesn't support PAI on reINVITEs, it sends UPDATEs and they don't seem to be supported on Yealink phones.

Anyway, I'm attaching the requested logs (for both phones). The scenario is the same I explained before:
1. Incoming call to T19P
2. T19P answers
3. T19P makes a new call to T41P
4. T41P answers
5. T19P performs an attended transfer
6. Caller id shown on T41P's display still shows T19P data and does not update with the original incoming call caller id (name/number)

Dear Customer,

For this parameter, it works for both invite and update message which pbx send to the phone to refresh the caller id.
account.X.cid_source=
0：FROM
1：PAI
2：PAI-FROM
3：PRID-PAI-FROM
4：PAI-RPID-FROM
5：RPID-FROM
I just check the pcap you provide and locate the problem, in your situation, the pbx send two update message to the T41P, both of the two update contact the PAI.
The fisrt one is: P-Asserted-Identity: "Daniel Diaz" <sip:142@10.176.255.0>\r\n
The second is: P-Asserted-Identity: "227605147" <sip:227605147@10.176.255.0>\r\n

The phone read the caller id from the PAI of the first update message.
Suggestion: Please let the pbx send only one update message with the correct PAI.