One of the reasons for WebRTC blank / empty video is having high packet loss. In that scenario, in server and client logs it will show as the connection is successful and video is playing normally, so you won't see any warning or error.
To check if there is a high packet loss, you can go to `about:webrtc` on firefox, or `chrome://webrtc-internals` on chrome. For firefox, you can navigate to "RTP Stats". You'll see it shows `Received: ... packets` and `Lost: ... packets`. You can calculate packet loss ratio using these counts. For chrome, there is a graph for packet loss ratio. You might have a very high packet loss such as 70% for example.
If you have this extreme high packet loss, one reason is having a smaller MTU https://en.wikipedia.org/wiki/Maximum_transmission_unit on the client network interface than the MTU used by the server. For example, your client network interface can have MTU=1500 bytes when not connected to VPN, and MTU=1250 bytes when connected to VPN. If the server is sending RTP packets (over UDP) with MTU=1400, it can be received by the client if the client is not using VPN, but the packets larger than 1250 bytes will get dropped by the client network interface.
If you want to check the client MTU locally, you can run `ifconfig` on mac or linux.
Mac example, without example vpn:
``` en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ... inet SOME_IP netmask 0xffffff00 broadcast 192.168.1.255 media: autoselect status: active ```
Mac example, with example vpn:
``` utun2: flags=80d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1250 inet SOME_IP --> SOME_IP netmask 0xffffffff nd6 options=201<PERFORMNUD,DAD> ```
How to configure MTU for server:
If you are using GStreamer for WebRTC server, the payload generator element, for example `rtpvp8pay` has a property to set desired MTU value. By using `gst-inspect-1.0 rtpvp8pay` you can see that it uses 1400 as MTU by default which can be larger than your client network interface can handle (e.g. 1250 on above example). You can make it work by setting lower MTU on your GStreamer pipeline so that your client network interface won't drop majority of the packages anymore (package loss ratio can reduce to 0.01% just by changing MTU on GStreamer pipeline on the server).
When this is the case, the incoming video can work for ~10 seconds when VPN is freshly reconnected, then the incoming video can freeze and subsequent page refreshes can lead to just blank video with 70%+ packet loss.
This is a very specific scenario but when it happens it is a complete silent/hidden error so hopefully this helps someone.

One of the reasons for WebRTC blank / empty video is having high packet loss. In that scenario, in server and client logs it will show as the connection is successful and video is playing normally, so you won't see any warning or error.
To check if there is a high packet loss, you can go to `about:webrtc` on firefox, or `chrome://webrtc-internals` on chrome. For firefox, you can navigate to "RTP Stats". You'll see it shows `Received: ... packets` and `Lost: ... packets`. You can calculate packet loss ratio using these counts. For chrome, there is a graph for packet loss ratio. You might have a very high packet loss such as 70% for example.
If you have this extreme high packet loss, one reason is having a smaller MTU https://en.wikipedia.org/wiki/Maximum_transmission_unit on the client network interface than the MTU used by the server. For example, your client network interface can have MTU=1500 bytes when not connected to VPN, and MTU=1250 bytes when connected to VPN. If the server is sending RTP packets (over UDP) with MTU=1400, it can be received by the client if the client is not using VPN, but the packets larger than 1250 bytes will get dropped by the client network interface.
If you want to check the client MTU locally, you can run `ifconfig` on mac or linux.
Mac example, without example vpn:
``` en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ... inet SOME_IP netmask 0xffffff00 broadcast 192.168.1.255 media: autoselect status: active ```
Mac example, with example vpn:
``` utun2: flags=80d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1250 inet SOME_IP --> SOME_IP netmask 0xffffffff nd6 options=201<PERFORMNUD,DAD> ```
How to configure MTU for server:
If you are using GStreamer for WebRTC server, the payload generator element, for example `rtpvp8pay` has a property to set desired MTU value. By using `gst-inspect-1.0 rtpvp8pay` you can see that it uses 1400 as MTU by default which can be larger than your client network interface can handle (e.g. 1250 on above example). You can make it work by setting lower MTU on your GStreamer pipeline so that your client network interface won't drop majority of the packages anymore (package loss ratio can reduce to 0.01% just by changing MTU on GStreamer pipeline on the server).
When this is the case, the incoming video can work for ~10 seconds when VPN is freshly reconnected, then the incoming video can freeze and subsequent page refreshes can lead to just blank video with 70%+ packet loss.
This is a very specific scenario but when it happens it is a complete silent/hidden error so hopefully this helps someone.