User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36 Steps to reproduce: I was connecting two WebRTC clients (Client A and Client B) through my server (my private Janus GW Plugin). I have one Audio/Video full duplex RTP session setup between the WebRTC Client and my Janus GW plugin, and three one way (from my Janus GW plugin to WebRTC Clients) audio RTP sessions. Actual results: Audio seems to work ok, but have an issue with video where I see very few seconds of video clip and then frozen - it may or may not recover from this state. Even if it recovers, it works very few seconds again and goes back to frozen state. ollowing is the topology, where Firefox (version 35.0.1) WebRTC client A and B are connected back-to-back through my private Janus plugin: WebRTC Client A <====> (My Janus GW Plugin) <====> WebRTC Client B I am hitting an issue where there are packets are dropped in both WebRTC clients itself (when I ran the Wireshark in the laptop where the WebRTC clients run, I can see the packet drops from the Wireshark trace - meaning that the missing packets didn't leave my laptop). Remember that the packets are not dropped in the network, rather that the packets are dropped before hitting the wire in my laptop itself where the FF browser is running - this happens in both of my laptop. Observations from the logs and traces: 1. Basically, when H264 video packets are missing from Client A and when Client B requests for those missing packets, my Janus GW plugin doesn't have those packets for retransmission. Same thing from Client B to A. 2. Noticed the packet loss from the wireshark trace provided for both Client A and Client B: For Client A: Src Addr: 192.168.1.79:55516, Dst Addr: 188.8.131.52:51817 For example, watch out for the missing sequence numbers from the given sequence numbers range below: 5233 to 5239, 5703 to 5708, 6140 to 6145, 6835 to 6840, many packets from 6738 to 6900 For Client B: Src Addr: 192.168.1.88:65091, Dst Addr: 184.108.40.206:5434 For example, watch out for the missing sequence numbers from the given sequence numbers range below: 2394 to 2404, 3255 to 3259, 3380 to 3384, 3589 to 3597, 3606 to 3614, 3754 to 3764, 3834 to 3842 2. Noticed the Frame drop in the Firefox "about_webrtc" log - for example, check out the RTP statistics for the first RTP session for both the Clients. Note: You may notice 3 additional one way audio RTP sessions for which there is no issues. Expected results: The back to back video (to/from Client-A/Client-B) should be working fine.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Can you upload the traces/logs? They likely will need to be compressed. If that's a problem, you could provide them to me directly. "frame drops" in stats is fairly meaningless here. Packet loss *before* transmission would be very unusual.
Created attachment 8560901 [details] Client_B_Logs.zip I have uploaded the logs/trace into two zip files - one from the Client A and the other from the Client B.
Is this still an issue in Dev Edition (Fx40) or Nightly (Fx41)?
The issue is no more reproducible. We can close this ticket.
Thanks for retesting
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.