clean-night-66919
08/06/2025, 5:16 AMtall-airline-16756
08/06/2025, 5:17 AMtall-airline-16756
08/06/2025, 5:17 AMRecordPublishTime
and RecordSubscribeTime
. These track attempts, success rates, and failures.
• Check for jitter buffer delays and quality limitation durations caused by bandwidth or CPU constraints.
• Use client-side monitoring tools such as the MetricsManager in the Swift SDK or the collectMetrics()
function in the Android SDK to gather detailed metrics.
• Analyze RTT (Round Trip Time) metrics, including Publisher RTT, Server Mesh RTT, and Subscriber RTT, to identify network-related delays.
Since you mentioned delays in receiving the remote description answer, it might be helpful to investigate network conditions, signaling server performance, and any potential bottlenecks in the signaling process.
Let me know if you need further assistance with any specific step or tool.
Sources: Sources/LiveKit/Protos/livekit_metrics.pb.swift | pkg/sfu/utils/owd_estimator.go | livekit-android-sdk/src/main/java/io/livekit/android/room/metrics/RTCMetric... | protobufs/livekit_metrics.protoclean-night-66919
08/06/2025, 5:19 AMtall-airline-16756
08/06/2025, 5:19 AMNewRTTInterceptorFactory
function. You’ll provide a callback to handle RTT updates like this:
interceptorFactory := interceptor.NewRTTInterceptorFactory(func(rtt uint32) {
// Here’s where you can work with the RTT value
log.Printf("Current RTT: %d ms", rtt)
})
1. Next, add the interceptor to your LiveKit transport to start tracking RTT:
transport.AddInterceptor(interceptorFactory)
This RTT interceptor listens for RTCP packets and figures out RTT using info from ReceiverReport
blocks. Every time the RTT updates, your callback will be called, so you can log it or dig into the data.
If you want me to walk you through any part of this or have questions, just let me know—I’m here to help!