SIP transfers
Transfer calls to SIP-compatible endpoints.
SIP transfers hand off the active call to SIP endpoints such as PBX systems, SIP phones, or softphones. The destination is a SIP URI rather than a phone number, which makes SIP transfers the right choice when TEL handling is unsupported by your carrier or when you need to attach metadata to the transfer leg.
The shared building blocks of any transfer (modes, caller ID behavior, outcome states, hold experience) live on the Call transfers overview. This page covers the settings and behaviors that are specific to SIP transfers.
Prerequisites
- The SIP endpoint must be reachable from Synthflow.
- SIP (UDP/TCP 5060) and RTP ports open and forwarded.
Setup
Configure the transfer mode (warm with message or summary, or cold) and the answer timeout.
Cold transfers use SIP REFER, which requires telephony-provider support. Twilio and Telnyx are confirmed; with other providers, prefer a warm mode (which uses SIP INVITE).
Custom X-headers
You can define custom X-headers in the UI to pass additional metadata with the SIP INVITE. This is useful for routing logic, caller identification, or integration with your PBX.
Header values can be populated using variables or info extractors.
Variables
Use {} syntax to inject dynamic values into a header.
If a custom action runs before the transfer, the transfer waits for that action to resolve so its output is available in the SIP headers.
Info extractors
An info extractor lets the AI agent pull a specific piece of information from the conversation and pass it as a header value. Each extractor has two fields:
The agent evaluates the prompt against the conversation at transfer time and writes the result into the specified header. Use info extractors when the value you need does not exist as a variable, for example a caller’s intent, sentiment, or a summary of the conversation so far.
Example: passing call context for agent handoff
A common pattern is to combine variables and info extractors so the human agent receives full context on transfer.
Field requirements
Avoid adding too many X-headers. Excessive headers increase the size of SIP INVITE packets, which can lead to packet fragmentation and loss, especially over UDP. Keep headers minimal and only include data your PBX or routing logic actually needs.
User-to-User (UUI) header
Some providers ignore individual X-headers on a cold transfer and read call metadata only from the SIP User-to-User header. Turn on Send as UUI header in the transfer action to combine your header values into that single header instead of sending one parameter per header.
The toggle appears under SIP Headers only when the transfer mode is cold. Warm transfers create a new call leg over SIP INVITE and always send your X-headers individually, so the setting does not apply to them.
Only the header values are sent, joined in the order you list them. The header names are dropped, so the receiving flow recovers each value by splitting on the delimiter and relying on that order. Reordering or removing a header changes what the receiving side reads.
Settings
Pick a delimiter that cannot appear inside your header values. If a value contains the delimiter, the receiving flow splits it into the wrong number of parts.
What goes on the wire
With headers X-Customer-Intent: billing and X-Caller-Name: Jane Doe, a cold transfer normally sends one URI parameter per header:
With Send as UUI header enabled and a | delimiter, the same transfer sends a single parameter. In ASCII the payload stays readable:
In Hex the payload is hex encoded, which avoids any question of how intermediate systems handle punctuation in the values:
Both forms carry a protocol discriminator of 00, which marks the payload as opaque application data. Synthflow sets this for you and it is not configurable.
Supported SIP URI formats
When the destination requires the transport to be TLS, the SIP URI cannot include ;transport=tls. Instead, add a SIP header on the transfer action instead: Name X-tls, Value 1. See the Zoom integration for an example.
Security
Synthflow supports Access Control Lists (ACL) to secure inbound SIP calls. Configure your SIP server to accept connections only from Synthflow’s IP addresses. Username and password authentication is not currently supported for inbound call transfers.
Related links
FAQ
Why does Synthflow use SIP REFER for cold transfers and SIP INVITE for warm transfers?
A cold transfer hands the call off entirely to your telephony provider via SIP REFER, which is why the receiving party sees the original caller’s number. A warm transfer needs Synthflow to stay in control to deliver the whisper or summary, so it creates a new outbound leg over SIP INVITE, and the agent’s number is shown instead. See Caller ID.
My PBX rejects the SIP REFER. What should I do?
Switch the transfer mode to warm so Synthflow uses SIP INVITE instead, or configure your PBX to accept SIP REFER from Synthflow’s IP range. SIP INVITE is universally supported.
Can I authenticate inbound SIP transfers with a username and password?
Not at this time. Use IP-based ACLs against Synthflow’s outbound IP addresses to secure inbound traffic.
What happens if the SIP endpoint does not respond?
The transfer follows the standard outcome states. Cold transfers end the call on failure; warm transfers let the agent retry, fall back to an alternate destination, or resume the conversation.
My provider receives the transfer but sees none of my X-headers. What should I do?
Some providers only read call metadata from the SIP User-to-User header on a cold transfer. Enable Send as UUI header so the header values are combined into that one header, then confirm with your provider whether the receiving flow expects Hex or ASCII.
Should I pick Hex or ASCII encoding for the UUI header?
Whichever the receiving flow is built to parse. ASCII keeps the payload readable in a packet capture, which makes troubleshooting easier. Hex encodes the payload, so punctuation inside your header values cannot be misread by systems in the path. See User-to-User (UUI) header.
Why are my header names missing from the UUI payload?
Only the values are sent, joined by the delimiter in the order you list the headers. The receiving flow splits on the delimiter and relies on that order, so keep the header order stable once the flow is built against it.