We do cold transfers via TransferSIPParticipant (SIP REFER). The caller ID shown on the transfer target’s phone changed from our DID (the “transferor”) to the original caller’s number (the “transferee”) — with no changes on our side. We want to understand what controls this on LiveKit Cloud and whether we can force it back to the DID.
Environment
- LiveKit: LiveKit Cloud
- Agents SDK: livekit-agents==1.5.9 (Python)
- Carrier: Twilio (Japan / Tokyo PSTN — Elastic SIP Trunking)
- Trunks provisioned via CreateSIPInboundTrunk / CreateSIPOutboundTrunk
Flow
- Inbound: customer +81xxxxxxxxxx → our DID +81 50… (via Twilio).
- Agent handles the call, then cold-transfers to a third number +81yyyyyyyyyy.
- We call:
```await livekit_api.sip.transfer_sip_participant(
api.TransferSIPParticipantRequest(
participant_identity=sip_participant_identity,
room_name=room_name,
transfer_to=“tel:+81yyyyyyyyyy”,
play_dialtone=True,
)
)```
No From/headers/identity set on the request.
Observed vs expected
- Expected (and prior behavior): transfer target sees our agent number (transferor).
- Now: transfer target sees the original caller’s number (transferee).
Questions
- On LiveKit Cloud, when we call TransferSIPParticipant, what does LiveKit put in the outgoing REFER (e.g. Refer-To, Referred-By, and any identity like From / P-Asserted-Identity)? We want to understand what Twilio keys off when it decides transferor vs transferee.
- Did any recent LiveKit Cloud SIP change alter how the REFER (or its identity/Referred-By header) is constructed, which could make Twilio switch from showing the transferor to the transferee — explaining a regression with no app change on our side?
- Is there any way to influence the transfer caller ID from LiveKit — trunk-level config, headers on TransferSIPParticipantRequest, or asserting P-Asserted-Identity — or is it strictly the carrier’s transfer-caller-id decision?
- If the carrier setting can’t reliably present our DID, is there any recommended alternative?