Question: Support for Jitter Buffer Statistics from M115+ WebRTC?

[Carsinalys]

Summary

I've noticed that the @roamhq/wrtc package doesn't currently expose some of the jitter buffer statistics that were introduced in Chrome M115+ WebRTC implementation. I'm wondering if there are any plans to support these statistics in future releases?

These statistics would be incredibly helpful for monitoring audio quality, debugging network issues, and optimizing real-time communication applications.

Statistics Fields of Interest

Based on the WebRTC Statistics Identifiers specification and Chrome M115+ implementation, I'm particularly interested in these jitter buffer statistics:

RTCInboundRtpStreamStats

• jitterBufferMinimumDelay (double): The minimum delay (in seconds) introduced by the jitter buffer
• jitterBufferTargetDelay (double): The target delay (in seconds) for the jitter buffer
• jitterBufferEmittedCount (unsigned long long): Total number of audio samples emitted by the jitter buffer
• jitterBufferDelay (double): The sum of the time each audio sample spent in the jitter buffer
• totalSamplesReceived (unsigned long long): Total number of audio samples received
• concealedSamples (unsigned long long): Number of concealed audio samples
• silentConcealedSamples (unsigned long long): Number of silent concealed samples
• concealmentEvents (unsigned long long): Number of concealment events
• insertedSamplesForDeceleration (unsigned long long): Samples inserted for deceleration
• removedSamplesForAcceleration (unsigned long long): Samples removed for acceleration

RTCRemoteInboundRtpStreamStats

• jitter (double): Packet jitter measured in seconds
• fractionLost (double): Fraction of RTP packets lost

Why These Statistics Would Be Valuable

Having access to these statistics would help with:

Audio Quality Monitoring

• Measuring jitter buffer effectiveness
• Monitoring audio concealment events
• Detecting sample rate adjustments

Network Diagnostics

• Packet loss fraction measurements
• Jitter measurements for network condition assessment
• Better debugging of audio quality issues

Performance Optimization

• Tuning jitter buffer parameters based on real conditions
• Providing metrics for adaptive bitrate algorithms
• Enhanced insight into end-to-end audio pipeline performance

Our Use Cases

We're particularly interested in these statistics for:

1. Meeting Quality Analytics: Understanding why audio quality degrades
2. Network Monitoring: Detecting network congestion and packet loss
3. Real-time Diagnostics: Providing users with connection quality feedback
4. Performance Tuning: Optimizing jitter buffer settings for different network conditions
5. Compliance: Meeting telecommunications quality standards

Comparison with Browser Implementation

Modern browsers (Chrome M115+, Firefox, Safari) expose these statistics through the standard WebRTC Stats API:

// Browser WebRTC Stats API
pc.getStats().then(stats => {
    stats.forEach(report => {
        if (report.type === 'inbound-rtp' && report.mediaType === 'audio') {
            console.log('Jitter Buffer Minimum Delay:', report.jitterBufferMinimumDelay);
            console.log('Jitter Buffer Target Delay:', report.jitterBufferTargetDelay);
            console.log('Concealed Samples:', report.concealedSamples);
            // ... other jitter statistics
        }
    });
});

Potential Implementation Approach

If you're considering adding support for these statistics, we thought a phased approach might work well:

Phase 1: Core Jitter Statistics

The most critical ones might be:

• jitterBufferMinimumDelay
• jitterBufferTargetDelay
• jitter (for remote inbound stats)
• concealedSamples

Phase 2: Extended Audio Quality Metrics

Additional audio quality statistics could include:

• jitterBufferEmittedCount
• totalSamplesReceived
• concealmentEvents
• Sample adjustment metrics

Phase 3: Complete Standards Compliance

Eventually achieving full compatibility with WebRTC Statistics specification for jitter-related fields.

Of course, this is just a suggestion - you know the codebase best!

Questions About Implementation

I'm curious about a few things:

Underlying Library Support

Do you know if the underlying native WebRTC library (libwebrtc) currently exposes these statistics? I believe recent versions should include these fields.

API Design

Would these statistics fit naturally into the existing @roamhq/wrtc API design? For example:

// How these might fit into the existing API
pc.getStats((err, stats) => {
    stats.forEach(stat => {
        if (stat.type === 'inbound-rtp') {
            // New jitter buffer fields would be available here
            console.log(stat.jitterBufferMinimumDelay);
            console.log(stat.concealedSamples);
        }
    });
});

Backward Compatibility

I imagine these would be additive fields that wouldn't break existing applications?

Potential Benefits

If these statistics were available, they could help the community with:

• Better Debug Capabilities: Developers could more easily diagnose audio issues
• Quality Monitoring: Applications could provide real-time quality feedback
• Standards Alignment: Keeping pace with modern WebRTC implementations
• Enterprise Use Cases: Supporting professional conferencing and telecommunications applications

References

• WebRTC Statistics Identifiers Specification
• Chrome M115 WebRTC Stats Changes
• MDN WebRTC Statistics API
• WebRTC Native API Documentation

Environment

• Package: @roamhq/wrtc
• Node.js Version: [Specify your version]
• Platform: [Specify your platform]
• Use Case: Real-time audio quality monitoring and network diagnostics

---

Thank you so much for maintaining this excellent WebRTC implementation for Node.js! We really appreciate all the work you've put into it.

Main Question: Are there any plans to support these jitter buffer statistics in future releases? Or is this something that might be considered for the roadmap?

Thanks again for all your great work! 🙏

[hazelduvall]

Hi @Carsinalys,

Thanks for the detailed feature request! From the description, it does seem like we'd need to update the underlying libwebrtc version to M115+ in order to support this feature.

Unfortunately, that's a fairly large undertaking on it's own. The current version is M98, and the next version I plan on supporting is M106 (https://github.com/WonderInventions/node-webrtc/tree/M106). Each release comes with its own set of API/semantic changes that need to be accounted for in a lot of the binding code, not a trivial thing.

After M106, according to https://chromiumdash.appspot.com/branches the next targets would be M110, M114, or M118 (green means LTS/extended support I believe, which is why I've chosen those releases). I will prioritize "simple libwebrtc upgrade process" over "try to force M118 immediately after M106" if it comes to it, just fyi. So, given I don't get a lot of time at work to contribute to this library, it may take a while to get to this 😔

Here's a draft roadmap:

1. 0.10.0: M106
2. 0.11.0: M114
3. 0.12.0: M122 + jitter buffer statistics

[Carsinalys]

Hi @duvallj ,

Thank you for the detailed explanation and roadmap! That makes perfect sense - upgrading libwebrtc versions is clearly a major undertaking with all the API changes involved.

Your planned roadmap looks great. We're absolutely fine waiting for the M122 release - quality and stability are much more important than speed.

Thanks again for maintaining this excellent library!