Yealink T42G attended transfer fix

I recently started using a Yealink T42G - An older (but still very functional) SIP Desk Phone. Weeks passed without any issues, until I attempted an attended transfer. I'd receive a call, chat to them, hit transfer, dial the next number, hit send, and my desk phone would start ringing again displaying "ReCall" on the screen. If you answer the call, the leg to the phone you wish to transfer to will drop.

Fortunately I was eventually able to find a fix. I presume the same fix will work on the other T4X series phones, including the T40, T41 T46 and T48 

The first step was looking at a SIP trace (Packet Capture) for clues. It revealed the SIP server was rejecting the call with a 403 Forbidden, so I looked at the (Redacted) REFER for clues:

REFER sip:93.184.216.34:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.130.218:5060;branch=z9hG4bK2982342611
Route: <sip:93.184.216.35;lr;ftag=1c673289805;did=183.3252;nat=yes>
From: <sip:441111111111@register.uk.example.org>;tag=2811361735
To: +447777777777 <sip:447777777777@sip.uk.example.org>;tag=1c673289805
Call-ID: 8aa398d5-3f45-49e9-911a-c28f04236812-2-1@example
CSeq: 3 REFER
Contact: <sip:441111111111@10.0.130.218:5060>
Max-Forwards: 70
User-Agent: Yealink SIP-T42G 29.83.0.120
Refer-To: <sip:93.184.216.34:5060?Replaces=2_1031327012%4010.0.130.218%3Bto-tag%3Dds-1b83c8f2-3e6fb99d%3Bfrom-tag%3D2899283723>
Event: refer
Referred-By: <sip:441111111111@register.uk.example.org>
Content-Length: 0

Nothing stands out immediately, so I compared it with an example  from another phone that worked:

REFER sip:93.184.216.34:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.14:5060;branch=z9hG4bK1368237426
Route: <sip:93.184.216.35;lr;ftag=1c151890343;did=0da.35f;nat=yes>
From: <sip:441111111111@register.staging.example.org>;tag=2011551301
To: 443333333333 <sip:1004@sip.staging.example.org>;tag=1c151890343
Call-ID: 38b8501e-72a3-452f-924b-aac4cd154be2-2-1@example
Contact: <sip:441111111111@192.168.0.14:5060>
Max-Forwards: 70
User-Agent: Yealink SIP-T58 58.84.0.25
Refer-To: <sip:07777777777@register.staging.example.org:5060?Replaces=1_3551048162%40192.168.0.14%3Bto-tag%3Dszar4dhqtcbkadzn.i%3Bfrom-tag%3D2763499357>
Event: refer
Referred-By: <sip:441111111111@register.staging.example.org>
Content-Length: 0

Which reveals the difference in the "Refer-To" header:

Refer-To: <sip:93.184.216.34:5060?Replaces=2_1031327012%4010.0.130.218%3Bto-tag%3Dds-1b83c8f2-3e6fb99d%3Bfrom-tag%3D2899283723>

VS

 

Refer-To: <sip:07777777777@register.staging.example.org:5060?Replaces=1_3551048162%40192.168.0.14%3Bto-tag%3Dszar4dhqtcbkadzn.i%3Bfrom-tag%3D2763499357>

The header from the failed transfer doesn't contain the number in the URI. 

Let's consult my favourite bed time reading, RFC5589 to see if there's any clues there.

   The Contact URI of the Transfer Target SHOULD be used by the
   Transferor as the Refer-To URI, unless the URI is suspected or known
   to not be routable outside the dialog.  Otherwise, the Address of
   Record (AOR) of the Transfer Target SHOULD be used.  That is, the
   same URI that the Transferor used to establish the session with the
   Transfer Target should be used.

Ahah, so it looks like the phone should potentially be using the AOR of the transfer target rather than the contact. So it's possible the issue is being caused by a bug or config problem with the phone.

I checked every visible setting within the phones web configuration page and couldn't find any obvious missed setting, so I wondered if anyone else was having the issue. I checked the logs on the SIP server and found several examples of Yealinks making attended transfers with the AOR in the Refer-To header working fine... so it does work. I then went on a wild goose chase of downgrading to various versions of firmware wondering if it was a bug, but I had no luck there.

I remembered I could download the phones config in a text format, which can occasionally revel settings that aren't exposed in the web interface by navigating to Settings > Configuration > Export CFG Configuration File (All).

I opened it up in a text editor and had a look around, and one of the parameters stood out:

account.11.transfer_refer_to_contact_header.enable = 1

That sounds suspiciously like the issue I'm having.... so I did a find and replace, swapping the 1 with a 0 on all 12 lines, and then imported the edited config file, and voila, I can now successfully perform an attended transfer without the call being rejected, with a proper Refer-To Header:

Refer-To: <sip:07777777777@register.staging.example.org:5060?Replaces=2_1031327012%4010.0.130.218%3Bto-tag%3Dds-1b83c8f2-3e6fb99d%3Bfrom-tag%3D2899283723>

I honestly have no idea how this issue came about, whether it is a default setting, something I enabled accidentally in the web UI and overlooked, or something introduced in a certain firmware version. I'm just glad it's fixed!