<div dir="auto">Someone speculated that this might be due to the STUN server providing an IPv6 address and that this is being cached.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, 26 Jun 2018, 10:46 pm David P, <<a href="mailto:davidswalkabout@gmail.com">davidswalkabout@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We've started seeing calls that aren't audible but in which both legs of the video conference *are* audible in recordings made at the same time. Here are some of the variables:<div><ol><li>We have two clouds with one FS in each<br></li><li>Both clouds have been configured for TLSv1.2 + SRTP<br></li><li>The network public/private IPs and port openings are the same</li><li>Bria for Windows works fine with "verify TLS certificate" on<br></li><li>Bria for Mac gets no audio regardless of security setting<br></li><li>A verto page pointed at one of the clouds works for Chrome/Windows and Safari/MacOS but doesn't work for either when pointed at the other cloud</li><li>I have looked at the FS log at debug level for one of these silent calls, and all of the codec negotiations go as expected and there are no errors.</li></ol><div>The problem I'd most like help with is finding possible reasons why webRTC calls are silent but have non-silent recordings.</div></div><div><br></div></div>
</blockquote></div>