Skip to main content
Version: Next — unreleased

Transfer a call

Use this task to hand a live voice call to another destination, such as an agent queue or a different number. You choose the target, the egress route for a phone number, the SIP method and any SIP headers. Then you check the result in the conversation record.

Availability: transfer applies to phone and browser voice calls; a text conversation cannot be transferred. The bot no-input give-up transfer is available from 0.9.18. A phone-number target needs an egress route that your administrator configures in SIP routing.

1. Choose where the transfer is configured​

Where you configure itWhen it runsReference
Transfer nodeWhen the flow reaches the nodeTransfer inspector
Voice agent Transfer call toolWhen the agent decides to transferNode inspectors
Final call actionsWhen a terminal failure reaches the callFinal call actions
Flow Settings › Call durationWhen the bot stays silent past the give-up timeoutBot no-input give-up

Each place offers its own list of SIP methods. For what each method sends and whether the platform stays in the call, see call transfer methods.

Outbound egress configuration routes transfer legs from an existing call. It does not provide a campaign dialer or an API for starting independent outbound bot conversations. Creating a trunk or routing pool does not schedule calls to a customer list.

2. Set the target and egress route​

Enter the Transfer target as a phone number, such as tel:+49300000000, or as a SIP address, such as sip:agent@pbx.example.com.

  • SIP address: the call is routed to the address's host. No egress route is needed, and the route selector is hidden.
  • Phone number: select an Egress route, or keep Default (team/base-number, then platform).

With the default, the platform resolves the route in this order:

  1. A route set explicitly on the transfer.
  2. An enabled egress route for the app's egress base number. Team routes come before global routes.
  3. A base number with an enabled egress trunk pool.
  4. The platform default route.

If no route is found, the transfer is blocked with transfer_blocked and code missing_egress_trunk. A route selects one of its trunks by round robin or by priority with failover. Use Create route in the selector, or ask your administrator, when the route you need is missing.

3. Transfer instead of ending a silent call​

A give-up timer can transfer the caller instead of hanging up:

  • Bot no-input give-up: in Flow Settings › Call duration, select Transfer instead of hangup, then set Transfer target and, for a number, Egress route. The call uses SIP REFER and sends no configured transfer headers. See Limit call duration.

If the give-up transfer fails, the call ends, so the caller is never left in silence. Your team's transfer restrictions still apply.

4. Add SIP headers​

How the bot's headers combine with configured headers depends on who requests the transfer:

SourceHeader behavior
Any sourceAn explicit header set replaces the configured headers.

The platform checks the resolved headers against the optional-header budget before it sends anything. If the headers exceed it, the transfer is blocked, not shortened, and the log shows transfer_blocked with code sip_header_budget_exceeded.

5. Choose a method and outcome mode​

With SIP REFER, the platform waits up to 5 seconds for a transfer result:

ResultReported as
AcceptedSuccess
No result, Blind outcome modeSuccess; the transfer counts as dispatched
No result, Notify outcome modeError; the result was not observed
404notReachable
408timeout
480 or 486notAvailable
487 or 603declined
Any other statusError

A blind REFER cannot report a failure. In final call actions, later steps after a blind REFER can never run, and the form warns about it. Select Notify or an INVITE method when the flow must react to a failed transfer.

6. Verify the transfer​

Save and publish the flow, place a test call, and open it in Conversations.

  • Call header: a transferred call shows ended: transferred: <target>; <reason>. A bot no-input give-up shows bot_no_input_give_up instead.
  • Overview › Transfers: lists target, mode, status and duration for INVITE transfers. A REFER transfer adds no row, because the platform leaves the call.
  • Debug › Logs: a blocked transfer appears as transfer_blocked with a code. Codes include missing_egress_trunk, sip_header_budget_exceeded, webrtc_refer_unsupported and missing_team. A target refused by your team's transfer restrictions is also logged here.
  • Debug › SIP ladder: shows the REFER or the new INVITE leg. For INVITE transfers, a Transfer active divider marks the new leg.

A logged dispatch is not proof that the destination answered. To follow the SIP messages, see the transfer method and the new leg.