can you forward the caller id with warm transfer? meaning they see the initial phone number that called in not the agent that forwards it

Thanks for reaching out, luisa. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Twilio

Thanks — great, Twilio is helpful because it supports caller ID passthrough with a specific trunk setting. What you need to do • When you create the SIP participant for the transfer, set the

sip_number

field to the original caller’s phone number so LiveKit will attempt to present that number to the transfer recipient. • On the Twilio trunk, enable the transfer caller ID passthrough option by configuring the trunk to allow transfers to show the transferee’s (original caller’s) number. In Twilio this is controlled via the trunk setting

transfer-caller-id from-transferee

. Things to verify in Twilio • Ensure the phone number you want to present is allowed by Twilio for outbound caller ID on that trunk. If your Twilio account or trunk requires caller ID verification, the original number must be verified or Twilio may replace it with the trunk’s default number. • Confirm your Twilio SIP trunk or TwiML is not overriding the caller ID in a Voice or SIP Origination/Termination rule. Next steps I can help with • If you share the transfer request payload you’re using (remove any secrets), I can point exactly where to set

sip_number

. • If you want, I can walk you through the specific Twilio Console setting location and the API parameter to update on the trunk. Would you like me to review your transfer payload or show the exact Twilio Console steps? , with interactive elements

yes it does have it, just that when we use warm transfer it doesn’t work

Thanks — I understand: Twilio’s trunk setting is enabled, but warm transfers still show the agent’s number instead of the original caller. I can help diagnose this — to narrow the cause I need a bit more info. Quick checklist (things that commonly cause this) • Make sure the transfer request that creates the new SIP participant includes the original inbound number in the

sip_number

field. If

sip_number

is omitted or set to the agent/trunk number, Twilio will show that instead. • Confirm the original number is permitted by Twilio for outbound caller ID on that trunk (even with

transfer-caller-id from-transferee

enabled, Twilio may block or replace unverified numbers). • Verify the transfer uses the same trunk/route that you configured for caller ID passthrough. Different trunk or TwiML rules can override the presented caller ID. Can you share these details (redact any secrets or tokens)? • The warm-transfer request payload you send to create the SIP participant (JSON or relevant fields). • The original inbound caller number and the number the recipient actually sees. • Which Twilio trunk you’re using and whether you confirmed

transfer-caller-id from-transferee

is set on that exact trunk. If you prefer, paste the payload and I’ll point out exactly where

sip_number

should be set and any other fields that could affect caller ID. If you’ve already included

sip_number

, I’ll review it and the transfer flow to find what Twilio may be rejecting or overriding. , with interactive elements

but it is possible to have twilio livekit and warm transfer and pass in the caller id?

Short answer: Yes — Twilio + LiveKit warm transfers can preserve the original caller ID, but two prerequisites must be met. What to do • When you initiate the warm transfer in LiveKit, create the SIP participant for the transfer and set the

sip_number

field to the original inbound caller’s phone number. That tells LiveKit/Twilio which caller ID to present to the transfer recipient. • On the Twilio trunk you use for the transfer, enable the transfer caller ID passthrough setting:

transfer-caller-id from-transferee

. This allows the transferee’s (original caller’s) number to be shown. Important limitations to verify • Twilio may require the outbound caller ID number to be verified or permitted on that trunk. If Twilio blocks the number, it will replace it with the trunk’s default or the transfer may fail. • The transfer must route through the same trunk (or a trunk configured for passthrough). Different trunks or TwiML/SIP rules can override the presented caller ID. • WarmTransferTask or the LiveKit transfer workflow handles the hold/briefing/connect steps, but caller ID presentation is controlled by the

sip_number

you send plus the trunk configuration. If you’d like, I can: • Review the transfer payload you’re sending (remove secrets) and point out where to set

sip_number

. • Suggest a short test flow to confirm Twilio accepts the passed caller ID and to capture any Twilio error/response if it’s being rejected. Which would you prefer — share your transfer payload for a quick review, or I can outline a minimal test example payload and steps to try? , with interactive elements

so is this possible with SIP refer?

Thanks — good question. You want to know whether SIP REFER can be used (with LiveKit + Twilio) so a warm transfer preserves the original caller’s number. Short answer • SIP REFER can preserve caller ID for transfers, but it’s typically used for cold transfers in LiveKit. • For warm transfers LiveKit usually creates a new SIP outbound leg (via

CreateSIPParticipant

) and you preserve caller ID by setting the

sip_number

to the original caller’s number. • In all cases, Twilio trunk configuration must allow caller-ID passthrough (

transfer-caller-id from-transferee

) — otherwise Twilio may rewrite the number. More detail and what that means for you • SIP REFER: LiveKit supports SIP REFER and will forward the From header (caller ID) for cold transfers. This means SIP REFER can present the original caller ID if the SIP path and trunk allow it. • Warm transfers: LiveKit’s warm-transfer flow normally uses

CreateSIPParticipant

to call the third party (so the agent can brief them). You pass the original caller number in the

sip_number

field there to request that caller ID be shown to the recipient. • Twilio limitation: Twilio must permit the outbound caller ID. With Twilio you need the trunk setting

transfer-caller-id from-transferee

and possibly verification of the number. If Twilio blocks the caller ID, the recipient will see the trunk/agent number instead. Practical recommendation • If you want the briefing step (warm transfer), use the LiveKit warm transfer flow and ensure your transfer request includes

sip_number

= original caller number. • If you must use SIP REFER for the transfer leg, it can work for caller ID preservation, but warm-transfer implementations typically do not rely on REFER for the briefing outbound call. If you try REFER in a warm flow, you may run into differences in how LiveKit and your trunk handle headers/routing. • Verify the Twilio trunk used for that outbound call has

transfer-caller-id from-transferee

enabled and that the original number is allowed on the trunk. If you want, I can: • Review the warm-transfer payload you’re sending (redact secrets) and confirm where to set

sip_number

. • Suggest a minimal test: do a warm transfer calling a PSTN endpoint via the same Twilio trunk and capture the SIP INVITE to confirm the From header and Twilio behavior. Which would you like to do next? Sources: Agents telephony integration | LiveKit Documentation | Preserve caller ID during SIP transfers with Twilio | LiveKit | Preserving Caller ID During SIP Transfers in LiveKit Agents | The Human-in-the-Loop (HITL) Pattern for Voice Agents | LiveKit | The Human-in-the-Loop (HITL) Pattern for Voice Agents | LiveKit, with interactive elements

how about sip dial what’s that?

Thanks — I’ll explain what "SIP dial" means, how it differs from SIP REFER, and how it relates to caller ID and warm transfers with LiveKit + Twilio. What SIP dial is • SIP dial means initiating a new outbound call from LiveKit to a phone number via a SIP trunk. In LiveKit this is done by creating a SIP participant (e.g.,

CreateSIPParticipantRequest

/

add_sip_participant

), which places an outbound SIP/PSTN call and joins the answered leg into the LiveKit room. • Use case examples: calling a supervisor for a warm transfer briefing, placing an outbound callback, or dialing external agents. How SIP dial differs from SIP REFER • SIP dial (CreateSIPParticipant): creates a brand-new outbound call leg. LiveKit waits for that leg to connect, can run briefing/hold logic, and then bridges participants. • SIP REFER: instructs a SIP endpoint to transfer an existing call to another target without creating a new outbound leg from LiveKit. REFER is commonly used for cold transfers and hands off the call to the recipient’s SIP endpoint. Caller ID behavior • With SIP dial you control the outbound caller ID by setting the

sip_number

field in the create request. Setting

sip_number

to the original caller’s number requests that number be presented to the recipient. • With SIP REFER the From header (caller ID) can be preserved as part of the REFER flow, but behavior depends on the SIP path and trunk. • In both cases, the SIP trunk/provider (Twilio) is the ultimate gatekeeper: Twilio must allow the passed caller ID (or it will rewrite it). For Twilio you need

transfer-caller-id from-transferee

and possibly verification of the number on the trunk. Which to use for warm transfer • For warm transfers (hold → brief → connect) LiveKit usually uses SIP dial (creates an outbound SIP participant) so the agent can brief the third party before connecting. Use

sip_number

on that outbound dial to preserve the original caller ID. • SIP REFER can be used if you prefer a transfer that hands the call off directly (cold transfer), but REFER is not typically the mechanism used for the briefing step in a warm transfer. Practical checklist to preserve caller ID with SIP dial + Twilio 1. When you create the outbound SIP participant, set

sip_number

= original caller number. 2. Ensure the call is routed through the Twilio trunk that has

transfer-caller-id from-transferee

enabled. 3. Verify the original number is permitted/verified on your Twilio trunk (Twilio may block unverified numbers). 4. If you still see the agent/trunk number, capture the SIP INVITE or Twilio logs to see whether Twilio accepted the requested From header or rewrote it. If you want, I can: • Show a minimal example

CreateSIPParticipantRequest

with

sip_number

set. • Review your warm-transfer payload (redact secrets) and Twilio trunk settings and point out what to change. Which would be most helpful? Sources: SIP Lifecycle Management Agent | LiveKit Documentation | Outbound Calling Script | LiveKit Documentation | Preserving Caller ID During SIP Transfers in LiveKit Agents | Agents telephony integration | LiveKit Documentation | The Human-in-the-Loop (HITL) Pattern for Voice Agents | LiveKit, with interactive elements