https://livekit.io logo
Join Slack
Powered by
I have a customer support callcenter pbx supportin...
# ask-ai
m
I have a customer support callcenter pbx supporting sip in intranet i want to answer with livekit agent what are the possibilities? 1.On prem in intranet raise infra on prem connected to sip with livekit and open source models? 2. Pstn to a twilio number then using livekit cloud or self hosted? How dowe transfer number phone of original number caller(not the pbx one) and i will transfer back to human agent transferring also the original end customer number
✅ 1
t
Thanks for reaching out, Jeremy. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — this is a great question. I’ll respond to the two scenarios you asked about and then highlight how to preserve the original caller’s number when handing calls back to humans. Before diving deeper, could you confirm whether you plan to host AI models on-premises (no cloud models) or whether a hybrid/cloud model is acceptable? That will help me give the most practical next steps. Summary of the two options you asked about 1) On‑prem (fully intranet) with PBX → LiveKit agent • This is possible. You can run LiveKit on your internal infrastructure and connect it to your SIP PBX via a SIP trunk. • Flow: PBX INVITE → LiveKit SIP endpoint → LiveKit creates a SIP participant in a room → the AI agent (self‑hosted STT/LLM/TTS or locally hosted models) joins the same room and interacts with the caller. • Benefits: full data locality and control, no media leaving your intranet if you keep AI and LiveKit self‑hosted. • Requirements/considerations: ◦ Configure SIP trunking between your PBX and LiveKit (signaling, codecs, RTP). ◦ Ensure media transcoding and WebRTC if agents or dashboards expect WebRTC. ◦ Enable SIP features you need (DTMF, SRTP/SIP-TLS if you require encrypted signaling/media). ◦ If using self‑hosted models, provision CPU/GPU and low latency networking for STT/TTS/LLM pipelines. 2) PSTN via Twilio number → LiveKit Cloud or self‑hosted LiveKit • You can receive PSTN calls on a Twilio number and forward them to LiveKit (either LiveKit Cloud or your self‑hosted LiveKit). • Flow: Caller → PSTN → Twilio number → SIP trunk to LiveKit → LiveKit room with AI agent. • Options: ◦ LiveKit Cloud + Twilio: faster to deploy, leverages LiveKit Cloud for media and orchestration. ◦ Self‑hosted LiveKit + Twilio: hybrid model—Twilio handles PSTN termination, your LiveKit runs where you choose. • Considerations: ◦ Twilio may require caller ID verification or restrict arbitrary caller ID; check Twilio settings for ANI passthrough. ◦ This approach makes it easy to scale and use global phone numbers. Preserving the original caller number when transferring back to a human agent • Goal: ensure the human agent (or the next PSTN endpoint) sees the original caller’s phone number (not the PBX or LiveKit trunk number). • How to do it: ◦ When initiating the outbound leg from LiveKit to a human (or another PBX), set the outbound caller ID to the original caller’s number. In LiveKit this is done by providing the original phone number in the 
sip_number
field of the outbound 
CreateSIPParticipantRequest
. ◦ Example conceptually: ▪︎ Create outbound SIP participant to target_agent_number ▪︎ Set 
sip_number = original_from_number
so the receiving endpoint sees the true caller ID • Important prerequisites: ◦ Your SIP trunk or PSTN provider must allow caller ID passthrough (ANI passthrough). Some providers require the outbound caller ID to be a verified/owned number, or block non‑verified caller IDs. ◦ If your PBX enforces its own outbound caller ID policies, those may override passthrough—check PBX and trunking configs. • Transfer types: ◦ Cold transfer (SIP REFER) and warm transfer flows are supported; for warm transfers you can dial the human, confirm, then bridge everything while preserving caller ID. ◦ Use LiveKit’s transfer tasks (e.g., WarmTransferTask) or SIP REFER flows depending on desired behavior. Next practical steps and questions for me to help further • Confirm whether you want fully on‑prem (AI + LiveKit) or hybrid (Twilio/LiveKit Cloud acceptable). • Tell me which PBX vendor and SIP trunk/provider you use (examples: Asterisk, FreePBX, Cisco UCM, Twilio, etc.) so I can call out vendor‑specific gotchas. • Do you need DTMF IVR, call recording, or encryption (SRTP/TLS) requirements? • Will the AI be real‑time (interactive agent) or a staged workflow (voicemail transcription, callback)? If you confirm those details, I’ll provide: • A recommended call flow diagram tailored to your choice (on‑prem vs hybrid). • Concrete SIP request fields and example request payload (how to set 
sip_number
) and any PBX/trunk settings to check. • Notes on provider restrictions you should verify (caller ID verification, supported codecs, allowed SIP headers). Happy to walk through a sample configuration once you tell me which hosting option and PBX/trunk you’re using. Sources: Pricing | LiveKit | sip | livekit/livekit_composite | DeepWiki | Agents on LiveKit Cloud | Deploy voice AI on global infrastructure | LiveKi... | LiveKit Phone Numbers | Connect voice agents to phone lines | LiveKit | Agents telephony integration | LiveKit Documentation, with interactive elements
m
First Caller pbx pstn twillio livekit. In that flow how the caller id is transferred to livekit agent?
t
Thanks — I’ll explain exactly how the original caller ID travels from your PBX → PSTN → Twilio → LiveKit agent and how you can read/use it in the agent. How caller ID is propagated • Your PBX sets the caller’s number in the SIP From/ANI fields when it places the call to PSTN. • As the call traverses the PSTN and reaches Twilio, Twilio typically carries that caller ID along when forwarding the call to your SIP endpoint, unless Twilio or an intermediate carrier strips or replaces it. • When LiveKit receives the incoming SIP INVITE from Twilio, LiveKit extracts the caller ID from the SIP signaling and creates a SIP participant representing the caller in the LiveKit room. Where the caller ID appears in LiveKit • The caller’s phone number is exposed on the SIP participant as an attribute: sip.phoneNumber. • Other SIP metadata is also available (for example: sip.callStatus, sip.callID, sip.trunkID). How to use it in an agent • In your agent code, read the caller number from the participant attributes when the SIP participant connects and use it in prompts, routing, or logging. Example (conceptual):
Copy code
if participant.kind == rtc.ParticipantKind.PARTICIPANT_KIND_SIP:
    phone_number = participant.attributes.get('sip.phoneNumber', 'Unknown')
    await agent.session.say(f"Thank you for calling from {phone_number}. How can I help?")
Important caveats and checks • Twilio and/or your SIP trunk/carrier must allow caller ID passthrough (ANI passthrough). Some providers require the outbound caller ID to be a verified number or will overwrite anonymous/unverified numbers. • If Twilio or a carrier has configured privacy/anonymization, the original number may be hidden unless you change those settings. • If you see unexpected numbers (trunk number or masked values), check Twilio’s SIP trunk configuration and any PBX outbound caller ID policies. • You can also enable options to hide or reveal phone numbers in LiveKit dispatch rules; ensure those aren’t active if you need the original number available. If you’d like, I can: • Show an exact code snippet for your agent platform to read 
sip.phoneNumber
. • Walk through the Twilio SIP trunk settings to confirm caller ID passthrough rules. • Help map the exact SIP headers LiveKit looks at if you want to verify headers on an incoming INVITE. Which would be most helpful next? Sources: Agents telephony integration | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki, with interactive elements
m
I had been told to make automatic dtmf after pstn. Transferred from twillio to livekit. Is it easy complex for dealing with 30 concurrent calls
t
Thanks — great details. I’ll focus on the Twilio → LiveKit flow and specifically on automatic DTMF after PSTN transfer and whether it’s practical for ~30 concurrent calls. Short answer • Yes — you can automatically send DTMF after Twilio transfers a PSTN call into LiveKit. • It’s well supported and is moderately complex to implement, but handling 30 concurrent calls is feasible with proper scaling and worker configuration. How it works (high level) • Twilio forwards the inbound PSTN call to your LiveKit SIP endpoint (INVITE). • LiveKit creates a SIP participant for that incoming call and exposes the call to your agent logic. • From your agent you can programmatically send DTMF to the SIP leg using the prebuilt send_dtmf_events tool (or equivalent SIP DTMF send APIs). • You can also collect DTMF from the caller (GetDtmfTask) if you need two‑way IVR interactions. Practical details you’ll want to implement • Use the send_dtmf_events helper to send tones sequentially (it uses a short pause between tones). Example usage pattern: ◦ When the SIP participant connects, call send_dtmf_events with the sequence you need (e.g., menu navigation digits + #). • If you must detect prompts or audio cues before sending tones, add a short delay or use speech/activity detection to ensure the remote IVR is ready to accept tones. • For receiving DTMF from callers, use the GetDtmfTask (prebuilt task) so your agent can react to keypad input. Scaling to ~30 concurrent calls • Each active call is typically handled by one agent session/worker. To support 30 concurrent calls you should run multiple agent workers (at least 30 capacity; add headroom for spikes). • Use horizontal scaling and load balancing for agent workers so calls are distributed across instances. • Watch these limits/considerations: ◦ CPU/memory for real‑time STT/TTS/LLM (if models run on your side). ◦ Network bandwidth and RTP capacity for concurrent audio streams. ◦ Agent framework timeouts/retries—ensure workers have stable connectivity and error handling. • LiveKit Cloud or managed agent workers simplify scaling; self‑hosting will require you to provision and autoscale agent workers yourself. Caller ID and DTMF interactions • Caller ID from the PSTN/Twilio leg is available in the SIP participant attributes (e.g., 
sip.phoneNumber
) so your agent can use it for logging, prompts, or passing as 
sip_number
when dialing out. • DTMF sending does not affect caller ID propagation—preserve caller ID by setting 
sip_number
when creating outbound legs if you later bridge or transfer to a human. Operational best practices • Test with a small set of concurrent calls first to tune delays between DTMF events and to validate various IVR vendors behave consistently. • Monitor call success rates, DTMF delivery, and latency. Add retries/backoff if a remote IVR doesn’t respond. • Keep a pool of warmed agent workers to reduce cold start latency when calls spike. • Confirm Twilio and any downstream carriers allow DTMF in-band or RFC2833 (choose the mode supported by your trunk), and ensure your SIP trunk configuration matches. Questions that help me give exact steps • Do you plan to run agents and STT/TTS on-premises or use LiveKit Cloud? • Which DTMF mode does your Twilio->SIP trunk use (RFC2833/DTMF via RTP events, or in-band)? If you don’t know, I can point to where to check in Twilio. • Do you need the agent to detect spoken prompts before sending DTMF, or are you sending fixed sequences immediately after connect? If you confirm those, I’ll: • Provide a short agent code snippet showing how to call send_dtmf_events after a SIP participant connects. • Outline an autoscaling/worker sizing suggestion for 30 concurrent calls (and headroom). • Provide the Twilio trunk settings to verify (DTMF mode, caller ID passthrough) so your DTMF and caller ID work reliably. Sources: send_dtmf_events | LiveKit Documentation | Preserving Caller ID During SIP Transfers in LiveKit Agents | examples/dtmf | livekit/livekit_composite | DeepWiki | SIP Lifecycle Management Agent | LiveKit Documentation | Agents Framework | livekit/livekit_composite | DeepWiki, with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by