SIP REFER transfer failing with 481 Call/Transaction Does Not Exist

Voice & Telephony
1

We are getting SIP REFER failures again, and I honestly don’t understand the difference between REFER and INVITE-based transfers.

When my agents click ‘Transfer’ in the UI, does the system use REFER or a new INVITE? And how do I know which one is failing?

2

From an audit perspective, every failed transfer must be documented.

If the SIP REFER fails with a 481, the call drops and the customer has to call back. That dropped interaction is a gap in our audit trail. We need the trunk diagnostic logs to prove the failure was a technical issue and not an agent intentionally disconnecting the customer.

3

The distinction is architectural:

  • REFER: The platform tells the SBC to redirect the call. The media path changes but GC remains the signaling controller.
  • INVITE with Replaces: The platform creates an entirely new call leg and bridges it, then tears down the original.

GC defaults to REFER for blind transfers and INVITE-with-Replaces for consult transfers. If your SBC doesn’t support REFER (some Ribbon models don’t), configure the trunk to force INVITE-based transfers.

4

The analytics data for failed REFER transfers is incomplete.

When a REFER fails, the conversation record shows the transfer was ‘Attempted’ but doesn’t capture the SIP error code. I have to correlate the conversation ID with the trunk diagnostic logs manually. My executive dashboard just shows ‘Transfer Failed’ with no root cause data.

5

To capture SIP failure codes programmatically, you can configure an AWS CloudWatch log group that receives the Edge’s diagnostic events.

EdgeDiagnosticStream:
  Type: AWS::Logs::LogGroup
  Properties:
    LogGroupName: /genesys/edge/sip-diagnostics
    RetentionInDays: 90

The Edge pushes SIP trace data to CloudWatch if you enable diagnostic logging in the trunk configuration.

6

Before implementing this technical fix, communicate to your transfer-heavy teams that some transfers will fail during the reconfiguration window.

We changed our trunk’s transfer method from REFER to INVITE-with-Replaces during business hours. For 15 minutes, agents experienced a 100% transfer failure rate because the trunk needed to re-register with the SBC under the new signaling profile. Schedule trunk changes during off-hours.

7

Our chatbot flow uses a transfer action that behaves differently from the voice transfer.

When the bot hands off a chat to an agent, it doesn’t use SIP at all - it is an internal platform routing decision. But the bot’s NLU intent for ‘transfer me to a human’ sometimes triggers the voice transfer action instead of the digital handoff action. Ensure your bot flow JSON explicitly specifies the digital transfer type.

8

Under MiFID II, if a REFER-based transfer crosses jurisdictions (e.g., UK agent transfers to EU agent), the recording compliance requirements change mid-call.

The transferred leg may fall under different regulatory retention rules. Ensure your recording policy dynamically adjusts based on the receiving agent’s jurisdiction.

9

Pro tip! :counterclockwise_arrows_button: Test your transfers with EVERY carrier you use!

Don’t assume REFER works universally. Each carrier’s SBC may handle REFER differently. We found that Carrier A supported REFER perfectly, Carrier B required INVITE-with-Replaces, and Carrier C rejected both and needed a custom SIP header. Test each one! :telephone_receiver: