Unable to receive WebRTC / RTP stream in Safari when behind VPN

[Joe Hocker]

let me apologize upfront for asking questions, asking for help but not being able to provide much in the way of logs or traces.  

The problem I'm having is I don't receive media when using Safari and using my work VPN. 

(Being on Work VPN is why I can provide a lot of log or traces, my work would likely have issue with sharing anything that has IP Addresses). 

I am using the following demo to do a simple test... 

https://janus.conf.meetecho.com/echotest.html

Successful use cases...

This echo test works as expected with both Safari and Chrome, when I'm at home, behind my home router and of course on Wifi NAT.

Problem use cases...

My problem comes when I start my VPN client from work.  Chrome seems to run the Demo without issue, but Safari fails 

Initial assumption is that the firewall for VPN is blocking the incoming stream.  However, it works with Chrome and I'm not sure why?

Looking at the console, I think it may be that ICE is not resolving the working SDP for the Janus server to use.  This may explain why Chrome is working, maybe it successfully communicates the correct ICE candidate?

Question... How can I tell what SDP was used at the far end, by Janus, to stream to my local browser?

[Alessandro Toppi]

Since you are using our public demo server, you have not the chance to debug on the remote end.

Open webrtc-internals on Chrome and compare the involved candidates with a Safari sessions. Check what candidates pair is working on Chrome and if that pair is being tried by Safari.

The SDPs used by Janus are basically the same SDP offer/answer that you see on your browser.

That said, it's not clear from your description if the issue is related to ICE candidates. It could also be in the DTLS handshake, since the VPN is greatly interfering with the network stack (e.g. MTU)