Thanks — I’m responding to your question about whether you can integrate Exotel’s WebSocket-based microphone audio stream into LiveKit and whether there’s any advantage to doing so. Short answer • Yes — you can integrate a WebSocket audio stream into LiveKit, but LiveKit does not consume raw WebSocket audio as a direct input out-of-the-box. You’ll need a small media gateway that receives the WebSocket audio from Exotel, converts it into a WebRTC-compatible stream (or uses LiveKit Ingress/WHIP), and then injects that stream into a LiveKit room. • Whether it’s worth the extra work depends on what you want to achieve. SIP integration is the simpler, standard path; WebSocket streaming gives you more control for preprocessing, firewall friendliness, and some latency/processing tradeoffs. How you can integrate (high level) 1. Build a WebSocket-to-WebRTC bridge: ◦ Receive Exotel’s WebSocket audio on a backend service. ◦ Convert frames into a media pipeline (decode/encode or packetize) and create a WebRTC peer connection. ◦ Use that peer connection to publish audio into LiveKit via the Ingress API (or a WHIP/RTCPeerConnection path). 1. Alternative: SIP -> LiveKit (simpler) ◦ If Exotel supports SIP trunking directly, connect Exotel as a SIP endpoint into LiveKit’s SIP/outbound calling flow. This is typically lower-effort and is the common pattern. Advantages of using the WebSocket route • Flexibility for real-time processing: you can run transcription, moderation, or analytics on the audio before sending it into LiveKit. • Firewall/NAT friendliness: WebSocket over TLS commonly uses port 443, which is less often blocked than SIP/RTP ports. • Easier backend integration: WebSocket streams are often simpler to parse and handle in modern server stacks (Node, Python) than raw RTP/SIP. • Potential for custom low-latency framing or metadata: if Exotel’s WebSocket includes call metadata or optimized framing, you can leverage that directly. Trade-offs / drawbacks • Extra complexity: you must host and maintain the bridge (encoding/decoding, timing, jitter buffering, resampling). • Resource cost: media processing will add compute and possibly latency if not tuned. • No direct built-in LiveKit input for raw WebSocket audio — conversion is necessary. When I recommend each approach • Use SIP integration when you want the simplest, supported path for PSTN calls and minimal infrastructure work. • Use WebSocket-to-Ingress when you need preprocessing (AI, transcription, moderation), need guaranteed 443-only connectivity, or want to use WebSocket-specific metadata/features Exotel provides. Next steps I can help with • Outline a simple architecture diagram and required components for a WebSocket-to-WebRTC bridge. • Provide an implementation checklist (required media codecs, buffering/resampling considerations, handling RTP/RTCP if you choose WebRTC). • Help you decide which approach fits your latency, reliability, and processing requirements if you share: ◦ Do you have a hard requirement to preprocess audio (transcription/moderation) before LiveKit? ◦ Are you constrained to port 443 / cannot use SIP/RTP ports? ◦ Which audio format/frame format does Exotel send over the WebSocket? Tell me which of those details apply and I’ll give a concrete implementation plan or checklist you can follow. Sources: Universal Egress | Universal Egress | Universal Egress | Python SDKs | livekit/livekit_composite | DeepWiki | server-sdk-js | livekit/livekit_composite | DeepWiki