Feature Type
Nice to have
Feature Description
Allow a Twilio connector warm transfer to present the original inbound customer's caller ID to the supervisor using Twilio's per-call CallToken. Today, the new outbound leg normally presents the business number. Preserving the inbound identity can help the supervisor recognize the caller and continue caller-ID-based lookup during the handoff.
Proposed scope for the Python and JavaScript SDKs:
- Keep the business/verified Twilio number as the default.
- Opt in with a nonempty CallToken and the matching original caller number from the same validated inbound webhook, held in server-side state keyed by CallSid.
- Retry once from the business number without the token only on explicit HTTP 400 caller-ID rejections (Twilio 21210 or 21212). Do not redial ambiguous transport failures or retry a failed fallback.
- Keep tokens out of prompts, participant attributes, TwiML, and logs.
- Preserve cancellation and late-call cleanup without introducing a new transfer teardown delay. In Python, reject incompatible Twilio clients at construction when token preservation is requested.
Does this API and fallback scope fit the intended connector workflow? In particular, feedback on the opt-in number/token pair and the two explicitly rejected caller-ID cases would help settle the public behavior before merge.
Workarounds / Alternatives
Applications can continue presenting the business number, or replace call origination themselves and implement consultation/cancellation cleanup outside the SDK. The proposal keeps the existing workflow available while avoiding that duplication.
Additional Context
Implementations are already open as #7309 and livekit/agents-js#2540. This issue is being opened after those PRs to make the scope discussion explicit; it does not represent prior maintainer approval. Both implementations can be adjusted based on feedback.
The JavaScript PR includes the prerequisite connector workflow from livekit/agents-js#2402 with original authorship. The separate Telnyx documentation PRs describe existing SIP options and are outside this feature's scope.
References: Twilio webhook parameters, Calls API, 21210, 21212.
Feature Type
Nice to have
Feature Description
Allow a Twilio connector warm transfer to present the original inbound customer's caller ID to the supervisor using Twilio's per-call CallToken. Today, the new outbound leg normally presents the business number. Preserving the inbound identity can help the supervisor recognize the caller and continue caller-ID-based lookup during the handoff.
Proposed scope for the Python and JavaScript SDKs:
Does this API and fallback scope fit the intended connector workflow? In particular, feedback on the opt-in number/token pair and the two explicitly rejected caller-ID cases would help settle the public behavior before merge.
Workarounds / Alternatives
Applications can continue presenting the business number, or replace call origination themselves and implement consultation/cancellation cleanup outside the SDK. The proposal keeps the existing workflow available while avoiding that duplication.
Additional Context
Implementations are already open as #7309 and livekit/agents-js#2540. This issue is being opened after those PRs to make the scope discussion explicit; it does not represent prior maintainer approval. Both implementations can be adjusted based on feedback.
The JavaScript PR includes the prerequisite connector workflow from livekit/agents-js#2402 with original authorship. The separate Telnyx documentation PRs describe existing SIP options and are outside this feature's scope.
References: Twilio webhook parameters, Calls API, 21210, 21212.