Transfer recalls via REFER NOTIFY events

Asterisk Asterisk SIP
1

Edit: This seems to be a Yealink bug which handles 503 incorrectly. I am just dropping those packets in the mean time.
iptables -I OUTPUT -m string --string “SIP/2.0 503 Service Unavailable” --algo bm --to 65535 -j DROP

Recently we have moved to PJSIP and have experienced some unwanted behavior. I realise this is likely a Yealink problem, but I can not seem to disable it on the device. Hopefully there is a solution in Asterisk, as this bug/feature was not a problem when we used chan_sip.

Is there a way to disable specific subscription states to prevent this behavior?

  1. I call a Yealink
  2. I transfer the call from the Yealink
  3. Yealink sends Asterisk a REFER, and receives a 202 Accepted
  4. I hang up on the caller’s extension
  5. Asterisk NOTIFYs the Yealink with Sipfrag 503 Service Unavailable
  6. Yealink starts ringing saying “recall”
  7. I answer it, terminates instantly because that call leg doesn’t even exist.

Executing [143@from-internal:1] Answer(“PJSIP/242-00000029”, “”) in new stack
> 0x7f81d0788fb0 – Probation passed - setting RTP source address to officeIP:34956
– Executing [143@from-internal:2] GotoIf(“PJSIP/242-00000029”, “1?noblock”) in new stack
– Goto (from-internal,143,5)
– Executing [143@from-internal:5] NoOp(“PJSIP/242-00000029”, “”) in new stack
– Executing [143@from-internal:6] Gosub(“PJSIP/242-00000029”, “recordcheck,s,1(242,143)”) in new stack
– Executing [s@recordcheck:1] NoOp(“PJSIP/242-00000029”, “from 242 to 143, inboundrec=”) in new stack
– Executing [s@recordcheck:2] GotoIf(“PJSIP/242-00000029”, “1?normal”) in new stack
– Goto (recordcheck,s,5)
– Executing [s@recordcheck:5] GotoIf(“PJSIP/242-00000029”, “1?stop”) in new stack
– Goto (recordcheck,s,10)
– Executing [s@recordcheck:10] StopMixMonitor(“PJSIP/242-00000029”, “”) in new stack
– Executing [s@recordcheck:11] Return(“PJSIP/242-00000029”, “”) in new stack
– Executing [143@from-internal:7] Set(“PJSIP/242-00000029”, “CHANNEL(musicclass)=0”) in new stack
– Executing [143@from-internal:8] NoOp(“PJSIP/242-00000029”, “”) in new stack
– Executing [143@from-internal:9] GotoIf(“PJSIP/242-00000029”, “0?keepDir”) in new stack
– Executing [143@from-internal:10] Set(“PJSIP/242-00000029”, “CDR(cdr_direction)=3”) in new stack
– Executing [143@from-internal:11] Set(“PJSIP/242-00000029”, “CDR(cdr_internal_from_extension)=242”) in new stack
– Executing [143@from-internal:12] Set(“PJSIP/242-00000029”, “CDR(cdr_internal_to_extension)=143”) in new stack
– Executing [143@from-internal:13] Set(“PJSIP/242-00000029”, “CDR(cdr_application)=Dial”) in new stack
– Executing [143@from-internal:14] GotoIf(“PJSIP/242-00000029”, “0?dialed”) in new stack
– Executing [143@from-internal:15] Dial(“PJSIP/242-00000029”, “PJSIP/143/sip:143@officeIP:1031,20,W”) in new stack
– Called PJSIP/143/sip:143@officeIP:1031
> 0x7f81d0788fb0 – Probation passed - setting RTP source address to officeIP:34956
> 0x7f81d0788fb0 – Probation passed - setting RTP source address to officeIP:34956
> 0x7f81d0788fb0 – Probation passed - setting RTP source address to officeIP:34956
– PJSIP/143-0000002a is ringing
– PJSIP/143-0000002a answered PJSIP/242-00000029
– Channel PJSIP/143-0000002a joined ‘simple_bridge’ basic-bridge <9ff82abe-d812-4641-b1fe-35d164d52ddc>
– Channel PJSIP/242-00000029 joined ‘simple_bridge’ basic-bridge <9ff82abe-d812-4641-b1fe-35d164d52ddc>
> Bridge 9ff82abe-d812-4641-b1fe-35d164d52ddc: switching from simple_bridge technology to native_rtp
> Locally RTP bridged ‘PJSIP/242-00000029’ and ‘PJSIP/143-0000002a’ in stack
> Locally RTP bridged ‘PJSIP/242-00000029’ and ‘PJSIP/143-0000002a’ in stack
> 0x7f81d07356c0 – Probation passed - setting RTP source address to officeIP:11976
> 0x7f81d07356c0 – Probation passed - setting RTP source address to officeIP:11976
[Feb 15 16:17:49] WARNING[127731][C-00000012]: res_musiconhold.c:884 _get_mohbyname: Music on Hold class ‘0’ not found in memory. Verify your configuration.
– Started music on hold, class ‘default’, on channel ‘PJSIP/242-00000029’
> 0x7f81d07356c0 – Probation passed - setting RTP source address to officeIP:11976
> 0x7f81d07356c0 – Probation passed - setting RTP source address to officeIP:11976
– Channel PJSIP/143-0000002a left ‘native_rtp’ basic-bridge <9ff82abe-d812-4641-b1fe-35d164d52ddc>
> Bridge 9ff82abe-d812-4641-b1fe-35d164d52ddc: switching from native_rtp technology to simple_bridge
– Stopped music on hold on PJSIP/242-00000029
– Channel PJSIP/242-00000029 left ‘simple_bridge’ basic-bridge <9ff82abe-d812-4641-b1fe-35d164d52ddc>
– Executing [142@from-internal:1] Answer(“PJSIP/242-00000029”, “”) in new stack
– Executing [142@from-internal:2] GotoIf(“PJSIP/242-00000029”, “1?noblock”) in new stack
– Goto (from-internal,142,5)
– Executing [142@from-internal:5] NoOp(“PJSIP/242-00000029”, “”) in new stack
– Executing [142@from-internal:6] Gosub(“PJSIP/242-00000029”, “recordcheck,s,1(242,142)”) in new stack
– Executing [s@recordcheck:1] NoOp(“PJSIP/242-00000029”, “from 242 to 142, inboundrec=”) in new stack
– Executing [s@recordcheck:2] GotoIf(“PJSIP/242-00000029”, “1?normal”) in new stack
– Goto (recordcheck,s,5)
– Executing [s@recordcheck:5] GotoIf(“PJSIP/242-00000029”, “1?stop”) in new stack
– Goto (recordcheck,s,10)
– Executing [s@recordcheck:10] StopMixMonitor(“PJSIP/242-00000029”, “”) in new stack
– Executing [s@recordcheck:11] Return(“PJSIP/242-00000029”, “”) in new stack
– Executing [142@from-internal:7] Set(“PJSIP/242-00000029”, “CHANNEL(musicclass)=0”) in new stack
– Executing [142@from-internal:8] NoOp(“PJSIP/242-00000029”, “”) in new stack
– Executing [142@from-internal:9] GotoIf(“PJSIP/242-00000029”, “1?keepDir”) in new stack
– Goto (from-internal,142,11)
– Executing [142@from-internal:11] Set(“PJSIP/242-00000029”, “CDR(cdr_internal_from_extension)=242”) in new stack
– Executing [142@from-internal:12] Set(“PJSIP/242-00000029”, “CDR(cdr_internal_to_extension)=142”) in new stack
– Executing [142@from-internal:13] Set(“PJSIP/242-00000029”, “CDR(cdr_application)=Dial”) in new stack
– Executing [142@from-internal:14] GotoIf(“PJSIP/242-00000029”, “0?dialed”) in new stack
– Executing [142@from-internal:15] Dial(“PJSIP/242-00000029”, “PJSIP/142/sip:142@officeIP:5064,20,W”) in new stack
– Called PJSIP/142/sip:142@officeIP:5064
– PJSIP/142-0000002b is ringing
> 0x7f81d0788fb0 – Probation passed - setting RTP source address to officeIP:34956
== Spawn extension (from-internal, 142, 15) exited non-zero on ‘PJSIP/242-00000029’

2

I know this is an old thread, but I recent ran across this same problem.

I worked with Yealink support on this and they told me to set this value in the config file. It is unfortunately not a setting available in the phone GUI.

transfer.hang_up_after_success_trans = 3

I have tested and confirmed this stopping the recall ringback on the T4X series of phones.

3

I am also having this problem all over. Using this works but it feels a bit hacky:

transfer.hang_up_after_success_trans = 3

I talked to Yealink about this and they had this to say about it:

Dear Customer,
For this case, this parameter ‘transfer.hang_up_after_success_trans = 3’ can fix it, but it only work for V80 firmware or later.
But as I understanding, if the phone goes to VM, server should reply with 200OK. Of cause, if the server reply with 503 error, it will recall back.

Is asterisk sending it a wrong reply? For us it happens when someone is blind transferred to voicemail, they hang up, and it causes the recording to be less than the required length.

yealink-recall
yealink-recall1919×934 533 KB

Using the Sangoma Freepbx 14 distro and asterisk 13.22. This has been happening to us for a while now.