Call forward to human agent — human's phone shows our number instead of the caller's

Telephony
1

Hi LiveKit Team,

Quick question about a “call forward to human agent” feature we’re
building on LiveKit Cloud + SIP.

WHAT WE’RE DOING
We have a voice AI agent that picks up incoming calls. When the
caller asks to be transferred to a human, we use LiveKit SIP to
forward / bridge the call to the human agent’s mobile phone.

WHAT WE WANT
When the human agent’s phone rings, we want the screen to show the
ORIGINAL CALLER’S NUMBER — so the human knows who is calling before
they pick up.

WHAT HAPPENS TODAY
Instead, the human’s phone shows OUR number (the number the caller
originally dialed to reach the AI). The caller’s number is not
displayed.

When we configure LiveKit to forward the caller’s number on the
outgoing forward, the carrier rejects the call:

sip status: 403: Caller ID is unauthorized.
A Valid Caller ID is either a DID you have purchased from Twilio
or a verified Caller ID.

QUESTIONS

  1. For the “call forward to human agent” pattern on LiveKit Cloud,
    what is the recommended way to make the original caller’s number
    appear on the human agent’s phone?

  2. Is there any LiveKit-side configuration we are missing that would
    allow this — either on the project, on the SIP integration, or in
    the way we initiate the forward?

  3. If the answer is “this is a carrier-side approval (Twilio)” and
    not something LiveKit controls, please confirm so we know to focus
    our effort there.

  4. Are there alternative approaches LiveKit supports for letting the
    human agent know who is calling without depending on the carrier
    displaying the original caller’s number on the phone screen — e.g.
    any kind of metadata channel that the human-side endpoint can
    read?

2

@Nithish_Kumar welcome, and thanks for the very clear writeup.

That 403 you’re seeing is the carrier (Twilio) enforcing its outbound caller‑ID rules; it isn’t something LiveKit can fix from our side.

3

The 403 from Twilio is fixable it’s a trunk configuration issue, not a permanent limitation.

Twilio requires you to explicitly enable caller ID forwarding on the SIP trunk before it allows the transferee’s number to pass through. By default it blocks it, which is why you’re seeing the 403.

Two ways to fix it:

Via CLI:

twilio api trunking v1 trunks update --sid <your-trunk-sid> \
  --transfer-mode enable-all \
  --transfer-caller-id from-transferee

Via Twilio Console:

  • Elastic SIP Trunking → Manage → Trunks → your trunk

  • Enable “Call Transfer (SIP REFER)”

  • Set “Caller ID for Transfer Target” to “From Transferee”

  • Enable PSTN Transfer

  • Save

After that, TransferSIPParticipant should pass the original caller ID through cleanly. We ran into the same 403 on a production call forwarding setup that trunk-level config was the missing piece.

One thing to note: caller ID is set at the trunk level, not per-transfer via the API. So this config applies to all transfers on that trunk.

4

@khan this won’t work because the outbound call is not placed as a SIP REFER