Ubuntu Question posted in
The official Ubuntu documentation can be found here.

webRTC video streaming – Chrome chooses wrong candidates with ubuntu 20

I am streaming video over webRTC in AWS environments, all ports are open, no firewall.

Server 1: Ubuntu 18.04.5 LTS

Server 2: Ubuntu 20.04.6 LTS

With Server 1 after at most 2-3 retries, webRTC chooses the correct candidate pair that has my pc public IP and the remote public IP:

enter image description here

With Server 2 – no matter how many retries, webRTC always chooses the host candidate with my local IP with the remote public IP, thus the connection fails. my PC public IP does appear in the ice candidate list:

enter image description here

enter image description here

All peers on all sides and servers use the same Google stun server stun:stun.l.google.com:19302. I only stream video data from server to client, so there is no need for TURN.

Also, if all peers over the same network and not AWS, i.e locally, it all works well.

I’ve debugged with wireshark it and also saw that there are responses to the STUN requests but once there is a binding request to the remote server there are no responses (74.125.250.129 is the google stun IP) marked packets have no response.

enter image description here

Stack: client-side written with javascript and native browser API. backend uses python and aiortc lib. latest chrome.

Tags:

2

Answers


  1. 0

    You are not receiving any STUN responses from the remote side in the second case, shown by responsesReceived still being zero. For AWS this typically suggests that you have not opened up the UDP port.

    The binding requests that receive a response are the binding requests sent to the STUN server, it can probably be left out in this case.

    Login or Signup to reply.
  2. 0

    In you example for server2, browser will start probing 192.168.1.142->54.73.239.178. In Wireshark you would see UDP packets being sent to the server. I’d check that on server-side you actually see these packets coming using tcpdump. If not – there’s clearly a firewall issue or udp gets blocked somewhere else.

    Also I’d double-check that during signalling you do receive your srflx candidate on server-side. Aiortc doesn’t have ICE trickle support, so i would just log what’s in "setRemoteDescription".

    I’d also check the behaviour in Firefox as their implementation of webrtc is different. Maybe it’ll provide some additional debug information on about:webrtc page.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search