1190554 - packet loss in about:webrtc is not updating

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P3)

Description

[Rohit Gupta]

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

Comment 1

[Rohit Gupta]

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 ?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 3

[Rohit Gupta]

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 [e-mail]: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.

Comment 4

[Maire Reavy [:mreavy]]

Needinfo to jesup to follow up

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 6

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 7

[Dan Minor [:dminor]]

This is now working. I have a wip for live updates on Bug 976669, and I can see the packet loss increasing over time.