Getting this error while testing could not connect Sub 1844: could not dial signal connection

Thanks for reaching out, Nouman. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

when i load test it 1800 users with audio and vedio i get this error

When you're load testing LiveKit with 1800 users using audio and video, here are some friendly steps to help you troubleshoot and get the best performance: • Run the Load Test: Try using the

lk load-test

command to simulate users. For example:

lk load-test \
  --room test-room \
  --video-publishers 150 \
  --subscribers 150 \
  --video-resolution high \
  --num-per-second 5

• Keep an Eye on Metrics: Take a look at the summary report for things like bitrate, latency, and packet loss—these can help spot where things might be slowing down. • Check Your System Resources: Make sure you have enough CPU, memory, and network bandwidth. Also, don’t forget to set

ulimit -n 65535

to increase file descriptor limits. • Audio Troubleshooting: If you see errors like "failed to capture frame," try increasing

queue_size_ms

to 2000ms in your audio source settings. For "silence detected," double-check your microphone or consider temporarily turning off noise suppression. • Video Performance Tips: Watch your CPU and memory usage closely, especially with high-res video. You might need to tweak the number of publishers and subscribers to keep things running smoothly. If you hit any snags or want help with specific errors or settings during your load test, just let me know—I’m here to help!

pc ERROR: 2025/08/06 065513 dropping candidate with ufrag ogxmpaGtrTfmGnlK because it doesn't match the current ufrags

Hey there! The error "dropping candidate with ufrag" usually pops up because of a hiccup with ICE (Interactive Connectivity Establishment) credential validation when setting up a WebRTC connection. No worries though—here are some friendly steps to help you troubleshoot: • Check Version Compatibility: Make sure all your LiveKit components are running compatible versions, since ICE handling can differ between them. • Review Logs: Take a peek at your logs for any specific messages like "ICE ufrag mismatch" or "could not parse SDP fragment." • Examine Network Configuration: Double-check your network setup, including firewall rules and that your STUN/TURN servers are correctly configured. • Validate SDP Processing: See if the issue happens during the initial offer/answer exchange, ICE trickle, or ICE restart steps. • Monitor ICE State: Confirm that the ICE ufrag fragment matches the remote ICE ufrag and that your SDP fragments are formatted just right. If you’re still stuck after trying these, feel free to share more details like room IDs, timestamps, full error logs, and client/server versions. We’re here to help you get this sorted!

how much time does the livekit load test will take to send the all load?

Hey there! The length of a LiveKit load test really depends on the

--duration

parameter you set when you run it. You can choose seconds (like

30s

), minutes (like

5m

), or even hours (like

1h

). Here’s a quick example:

lk load-test \
  --room test-room \
  --video-publishers 150 \
  --subscribers 150 \
  --duration 10m

This will run the load test for 10 minutes. And just so you know, if you don’t set a duration, the test keeps going until you stop it yourself.

turnc ERROR: 2025/08/06 073743 Fail to refresh permissions: transaction closed turnc ERROR: 2025/08/06 073743 Fail to refresh permissions: transaction closed turnc ERROR: 2025/08/06 073744 Fail to refresh permissions: all retransmissions failed for RZjHbkwdCfXFU2dr caught panic in consumeTrack runtime error: invalid memory address or nil pointer dereference caught panic in consumeTrack runtime error: invalid memory address or nil pointer dereference turnc ERROR: 2025/08/06 073753 Fail to refresh permissions: transaction closed

Hey there! That "Fail to refresh permissions: transaction closed" error usually pops up when there’s a hiccup with token refresh or permission updates in LiveKit. No worries though, here are some friendly steps to help you troubleshoot: • Check Token Refresh: Make sure your client is handling token refresh properly. LiveKit tokens expire every 10 minutes, so they need to be refreshed regularly. • Verify Permissions Update: Double-check that permissions are being updated on the fly using the UpdateParticipant API, and that your client is applying these changes correctly. • Network and Connectivity: Take a look at your network setup—firewalls can sometimes block TURN/ICE configurations. Also, ensure proper NAT traversal and whitelist

*.turn.livekit.cloud

on TCP/443 if that’s relevant for you. • Session Management: If you’re seeing “transaction closed,” it might mean the session expired. Make sure your client handles session expiration gracefully and reconnects when needed. • Logs and Debugging: Peek at both server and client logs for any errors related to token refresh or permission updates. These clues can help figure out if the issue is on the client side, server side, or somewhere in the network. • Client-Side Handling: Ensure your client properly unpublishes and republishes tracks after refreshing tokens or changing permissions. If you want, feel free to share more about your setup—I’m here to help you get this sorted out! Sources: Authentication | LiveKit Docs | Authentication | LiveKit Docs | Firewall Tips | Community & Support | livekit/livekit_composite | DeepWiki | livekit/src/room/mod.rs

it while load testing the livekit server

Hey there! If you’re running into TURN-related errors like "Fail to refresh permissions: transaction closed" during LiveKit load testing, no worries—here are some friendly troubleshooting tips to help you out: • Network Connectivity: First, double-check that your TURN server is reachable. Make sure TCP/443 is open for TURN traffic, and if you need UDP, confirm that’s allowed too. • Transport Configuration: It’s good to verify that your client is set up to use TURN as a fallback when direct connections don’t work. Also, ensure the fallback reconnects to the same media node smoothly. • Authentication and Permissions: Take a look at your access token—does it have the right permissions for media access? And are tokens refreshing properly when permissions change? That’s key. • Logs and Debugging: Checking both server and client logs can reveal a lot. Look out for errors related to TURN, DTLS, or permissions to figure out if the problem is on the client side, server side, or network. • Reconnection Handling: Make sure your clients can reconnect properly after a failure or permission update, following the reconnection logic in the RoomManager and RTC Engine. If you want, I’m here to help you dive deeper into any of these steps—just let me know!

possible errors of livekit while testing

When you're doing LiveKit load testing, you might come across some common errors like these: • Connection Errors: Things like the server being unreachable, internal errors popping up, connection timeouts, or media not working properly. • Server-Side Issues: Situations such as the server shutting down, a room being deleted, state mismatches, join failures, or duplicate identities. • Resource Limitations: When the server’s capacity is maxed out, a node goes over its limits, or other resource constraints come into play. • Media Device Issues: Problems like the device not being found, access being denied, capture format troubles, or issues with FPS and resolution. • Track-Related Errors: Errors such as a track not found, not bound, lacking permission, or subscription limits being exceeded. If any of these sound familiar or you want a hand digging into a specific error, just let me know—I’m here to help! Sources: Sources/LiveKit/Protos/livekit_models.pb.swift | pkg/service/errors.go