Thanks — I’m responding to your question about whether LiveKit’s

load-test

CLI can trigger many rapid SIP-style calls (for example, N one-to-one calls with “empty packets”) to stress-test your environment. Short answer • No — the

load-test

CLI (the

chrometester

) is not suitable for SIP call or “empty packet” testing. • Yes — you can simulate large volumes of SIP-style call setups by scripting against the LiveKit Server API (creating SIP participants / dispatch rules) or by using third‑party SIP load tools for SIP-signaling / minimal-media testing. Why

load-test

/

chrometester

isn’t a fit •

chrometester

runs headless Chrome instances to simulate WebRTC participants in rooms. It’s designed to generate realistic WebRTC media and transport traffic for stress-testing WebRTC, not SIP signaling or PSTN trunk behavior. • It does not emulate SIP trunks, SIP signaling (INVITEs, etc.), or the ability to send “empty” RTP packets. It generates actual media/data traffic to test WebRTC performance. What you can use instead • Use the LiveKit Server API to programmatically create SIP participants or trigger outbound SIP calls. You can script many parallel requests to create N one-to-one agent-user calls and test call setup and dispatch scaling. ◦ This tests SIP call setup and how your agent-room dispatching handles concurrency (it does not create “empty packets,” but it does exercise real call flows). • Use a dedicated SIP load-testing tool (open-source or commercial) to generate SIP INVITEs and RTP with minimal or empty payloads if your goal is to flood SIP signaling or emulate minimal-media calls. Those tools are purpose-built for high-volume SIP signaling tests. Suggested next steps (pick what matches your goal) 1. If your goal is to test the LiveKit/WebRTC end-to-end flow and room/agent dispatch under many real calls: ◦ Script parallel calls using the Server API to create SIP participants / calls (scale N up until resource limits appear). 1. If your goal is purely SIP signaling capacity or generating “empty packet” floods: ◦ Use a SIP load generator to produce INVITEs and minimal RTP toward your SIP trunk or gateway, then observe how your LiveKit SIP integration and call dispatch behave. 1. If you’d like, I can help with: ◦ A sample script pattern to create many SIP participants in parallel via the Server API. ◦ Recommendations for open-source SIP load tools and how to configure them for minimal RTP payloads. ◦ What metrics to monitor on LiveKit and your SIP gateway while load-testing (CPU, connection counts, room concurrency, call setup latency). Which option do you want to pursue? If you choose the Server API route, tell me how many simultaneous calls you plan to simulate and whether you want example code in Python, Node, or another language.