Data buffering in WebRTC datachannel

[tarun mangla]

Hi,

I am new to WebRTC protocol. I am using WebRTC (unreliable) datachannels to send periodic message (every 20ms of size 160 bytes each) from machine A to machine B.

In some cases, I see there are no messages received by machine B for long periods (order of 10s of seconds). The outstanding data messages are then received all at once. This indicates that the data packets are getting buffered somewhere. To make sure that my sending logic is not the issue, I also add a timestamp the data. Analyzing the timestamp shows that the sending logic sends packet (dataChannel.send) correctly.

On further investigation, I found out that the messages are buffered by the browser. Specifically, I collected packet trace at the sender (machine A). During the period when there are no messages received, the browser is sending STUN binding requests periodically. However, it does not receive any response for these binding requests. As soon as a response for these message is received, the outstanding data is set all at once.

Could someone please share why this could be happening? Specifically, does no response to the STUN binding requests always indicate an issue in the network? Or it could happen because of some issue in the browser (for example, browser window in background)? In case latter, is there a way to isolate issue in the network vs browser?

Thanks,

Tarun

[Nils Ohlmeier]

I’m assuming you are talking about Chrome here. I can’t speak to how the Chrome implementation works, but the STUN bindings quests you see are suppose to be consent requests. Consent requests or responses can go missing. It should not affect the PeerConnection directly on the first missing response. Do you know if this affect audio and/or video as well?

Running your browser in the background should not affect networking. Obviously you could also take a packet trace on the receiving machine as well to find out if the network is dropping packets or if the receiving browser drops/ignores them. Although that information is not really going change anything, as the problem appears to be on the sender side.

Best

  Nils Ohlmeier