packet loss in about:webrtc is not updating

NEW
Unassigned

Status

()

Core
WebRTC
P3
normal
Rank:
25
3 years ago
4 months ago

People

(Reporter: Rohit Gupta, Unassigned)

Tracking

39 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

1. Make a webrtc call using firefox observe the about:webrtc
2. Make a webrtc call from the same machine using chrome, observer chrome://webrtc-internals
3. Add network issues to drop packets
4. chrome://webrtc-internals updates the packet loss but on firefox it show no loss even when the voice was choppy.



Actual results:

packet loss didn't get updated on the firefox about:webrtc page. Stays at 0 all along.


Expected results:

Expected the packet loss to update
(Reporter)

Comment 1

3 years ago
The above is NOT applicable for codec like OPUS / VP8. Also codecs are not reported by the firefox but always available in chrome. I do see packet loss updates for OPUS/iSAC codec but the number still varies from the chrome. So not able to find a consistent results between 2 browsers.

For PCMU codec the packet loss is not updated on the received stream. I believe this has something to do with RTCP data not getting send back to the browser. Is this correct understanding ? 
Though the same setup works on chrome, do we know why ?

Updated

3 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
A couple of issues: one, we don't update about:webrtc 'live', you have to reload.  It's not clear in your steps to reproduce that you reloaded.

Comment 1 is confusing; it's not clear how OPUS/VP8 come into this or how that's different than what's in comment 0.

Packet losses on the two sides will never be guaranteed to match; RTP/RTCP doesn't guarantee that.

RTCP should not be affected by codec; PCMU is not handled differently than Opus.  RTCP not getting through would manifest itself with no RTT visible, etc.

Please give more explanation of what you're seeing and what's confusing about it.  Packet traces (Wireshark PCAPs) would help along with about:webrtc info
Flags: needinfo?(rgupta)
(Reporter)

Comment 3

2 years ago
Apologizes for the delay in response, I understand the live update. We are actually calling getCallStats() periodically to access the stats.

"Packet losses on the two sides will never be guaranteed to match; RTP/RTCP doesn't guarantee that." hmm...When you say both sides is it ( RTCP & about:webrtc ) since as per my understanding about:webrtc displays rtcp data received from the remote endpoint.

"RTCP should not be affected by codec; PCMU is not handled differently than Opus.  RTCP not getting through would manifest itself with no RTT visible, etc." Agree and thanks for clarifying.

Better than pcap, I was able to reproduce this issue using webrtc sample project.

1. git clone git@github.com:webrtc/samples.git
2. cd webrtc-samples
3. python2.7 -m SimpleHTTPServer 3000
4. http://localhost:3000/src/content/peerconnection/constraints/
5. After running it for sometime, add some network impairment

Check reports on both firefox and chrome, they should atleast be in same ball park, In multiple runs on my side the packet drops on firefox didn't update. Please try and let me know if you see something different.
Flags: needinfo?(rgupta)
Flags: needinfo?(rjesup)
Needinfo to jesup to follow up

Updated

2 years ago
Flags: needinfo?(rjesup)
Cleared this by mistake.  I looked at this before and hadn't come to any conclusions.  I don't normally have a network-impairment setup, so I'll need to play with that again.
Flags: needinfo?(rjesup)

Updated

2 years ago
Status: UNCONFIRMED → NEW
Rank: 25
Ever confirmed: true
Flags: needinfo?(rjesup)
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.