If this was the case why can i do this for cold transfers?

Thanks — great question. You’re asking why you can preserve the original caller ID for cold transfers but not for warm transfers when using Twilio. I’ll explain the key technical and policy differences and what that means for your flows. Short answer • Cold transfers can preserve the original caller ID because they use SIP REFER (a direct transfer), which Twilio’s trunking supports with caller-ID passthrough when configured. • Warm transfers typically cannot preserve the original caller ID because they use a bridging/B2BUA approach (a three‑party call) where Twilio or the intermediary rewrites SIP headers and enforces carrier/anti‑spoofing policies. Why cold transfers can pass the original caller ID • Cold transfers use SIP REFER to tell Twilio to place a new outbound call and present the transferee’s (original caller’s) number as the From header. • Twilio trunks can be configured to allow this behavior (for example, using the transfer-caller-id set to from-transferee and enabling PSTN transfer), so the original number can be passed through to the PSTN leg. Why warm transfers usually cannot • Warm transfers create a three‑party bridge (caller + agent + new party) rather than a single direct outbound call from the caller to the target. • In that bridged/B2BUA scenario the provider (Twilio) sits between call legs and often rewrites SIP headers (including From/caller ID). This is both a technical limitation of how bridging works and a deliberate enforcement of carrier and regulatory rules (STIR/SHAKEN, anti‑spoofing). • Because of those rewrites and policies, Twilio may replace an unverified external number with your trunk’s default number for the outbound PSTN leg during warm transfers. Policy and verification constraints • Twilio will only present as outbound caller ID either a Twilio number you own or a verified caller ID on your account. An arbitrary third‑party phone number (the original caller) is typically not verified and therefore may be blocked or replaced. • Even if LiveKit forwards the original number (via

sip_number

), Twilio and downstream carriers have the final say — they can override it to comply with anti‑spoofing and regulatory rules. What you can do • Ensure LiveKit forwards the original number (set

sip_number

) so you’re doing everything correct on the LiveKit side. • For cold transfers: configure your Twilio trunk to allow transfer caller-ID passthrough (

from-transferee

) and ensure SIP REFER/PSTN transfer is enabled. • For warm transfers: accept that PSTN caller ID preservation is unlikely unless the original number is verified/owned by your account. Instead consider these practical alternatives: ◦ Use a company/Twilio number as the outbound caller ID and surface the original caller’s number/identity inside your app or via an audio announcement. ◦ If you control the destination and both ends are verified, you may be able to preserve numbers — otherwise carrier policies will likely block it. If you want, I can: • Walk through the exact LiveKit API call you’re using so you set

sip_number

correctly for the transfer. • Point to the specific Twilio trunk settings to check (transfer-caller-id, PSTN transfer, SIP REFER support). • Help design a fallback UX (in‑call announcement or in‑app display) so transferred parties still see the original caller identity even if PSTN caller ID can’t be preserved. Which of those would you like me to help with next? Sources: Preserve caller ID during SIP transfers with Twilio | LiveKit | How Vicidial Handles Bridging, Transfers, and SIP Calls