<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">If they start sending to us we will auto -adjust to the right ip after a few packets. Its a bit slower to set up but should work.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 15, 2020, at 7:36 PM, David P <<a href="mailto:davidswalkabout@gmail.com" class="">davidswalkabout@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Although we have STUN+TURN coturn (and FS) deployed in Oregon, a verto user in San Francisco today made a call in which only (private) host candidates were in the offer bundle SDP.</div><div class=""><br class=""></div><div class="">They use IT-managed Ethernet, so any slowness in getting STUN is probably in their IT management of the connection...and not something we can do anything about unless our FS can support peer-reflexive candidates.</div><div class=""><br class=""></div><div class="">They tell me their network has worked fine with Zoom, which is grating to hear. Is there any prospect of FS supporting peer-reflexive candidates?</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2020 at 12:22 AM <<a href="mailto:freeswitch-users-request@lists.freeswitch.org" class="">freeswitch-users-request@lists.freeswitch.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br class="">From: David P <<a href="mailto:davidswalkabout@gmail.com" target="_blank" class="">davidswalkabout@gmail.com</a>><br class="">To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank" class="">freeswitch-users@lists.freeswitch.org</a>><br class="">Cc: <br class="">Bcc: <br class="">Date: Mon, 31 Aug 2020 08:36:05 +1200<br class="">Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4<br class=""><div dir="auto" class=""><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div dir="auto" class="">I strongly suspect the problem is due to FS choosing a different port than is offered. I've seen this a few times by comparing the offer SDP a=candidate entries with the address:port in FS log entries containing 'Choose rtp'. This won't work if the user is behind a firewall that allows incoming response only through ports opened for outgoing requests.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Another thing I wonder about is when verto provides a BUNDLE offer, should it use the same address and port for both audio and video. I think I've seen that it doesn't, but maybe BUNDLE doesn't require it.</div><div dir="auto" class=""><br class=""></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">--------- Forwarded message ----------<br class="">From: Nathan Stratton <<a href="mailto:nathan@robotics.net" rel="noreferrer" target="_blank" class="">nathan@robotics.net</a>><br class="">To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" rel="noreferrer" target="_blank" class="">freeswitch-users@lists.freeswitch.org</a>><br class="">Cc: <br class="">Bcc: <br class="">Date: Sat, 29 Aug 2020 11:13:24 -0400<br class="">Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4<br class=""><div dir="ltr" class="">Looks like your client is not hitting a stun server to get the public IP address, however, I have been wondering why it's not possible to make FreeSWITCH work without using STUN on the client as long as FreeSWITCH is on a public IP. <br clear="all" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><br class="">><><br class="">nathan stratton</div></div></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 29, 2020 at 3:00 AM David P <<a href="mailto:davidswalkabout@gmail.com" rel="noreferrer" target="_blank" class="">davidswalkabout@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">The client is current verto running on current Chrome/Win10.</div><div class=""><br class=""></div><div class="">The client's SDP shows srflx and relay candidates from Twilio at same network cost as the "private" host candidates, and FSv10.4 chooses the host candidates.</div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br class="">From: Mike Jerris <<a href="mailto:mike@freeswitch.org" rel="noreferrer" target="_blank" class="">mike@freeswitch.org</a>><br class=""><br class=""><div class="">If client still isn’t putting in non rfc1918 candidates in audio you need to figure out why that is first.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 26, 2020, at 7:17 PM, David P <<a href="mailto:davidswalkabout@gmail.com" rel="noreferrer" target="_blank" class="">davidswalkabout@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class="">I've introduced Twilio STUN and TURN to our iceServers since then. All have the same network cost in the SDP and FSv10.4 chooses a host. Verto reports the remote stream arrived but getStats shows zero audio bytes in or out, and it's silent to our user. I applied a display filter using our Freeswitch's public IP ip.src == 52.xx.yy.zz or ip.dst == ip.src == 52.xx.yy.zz and in addition to TLS I see some TCP ACKs from our user's 10.0.0.189 but I don't know what else to look for.<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br class="">From: Mike Jerris <<a href="mailto:mike@freeswitch.org" rel="noreferrer" target="_blank" class="">mike@freeswitch.org</a>><br class="">To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" rel="noreferrer" target="_blank" class="">freeswitch-users@lists.freeswitch.org</a>><br class="">Cc: <br class="">Bcc: <br class="">Date: Wed, 26 Aug 2020 16:19:56 -0400<br class="">Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4<br class=""></blockquote><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Configure stun in your client so you get proper candidates that are reachable.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2020, at 6:18 PM, David P <<a href="mailto:davidswalkabout@gmail.com" rel="noreferrer" target="_blank" class="">davidswalkabout@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Yesterday I had a verto call in which the <video> contained a remote echo (which is how we configure it) but there was no audio out nor in (confirmed by getStats showing zero audio bytes out or in).<div class=""><br class=""></div><div class="">I was using:</div><div class="">FreeSWITCH Version 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit (git 133fc2c 2020-08-05 11:01:19Z 64bit)<br class=""></div><div class="">from Chrome84/Win10</div><div class=""><br class=""></div><div class="">I noticed the video candidates included a relay but the audio ones didn't:</div><div class=""><br class=""></div><div class="">f6e23797-4ad2-b761-2a6d-97846c122d7e m=audio 62058 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp 2122194687 172.20.4.169 62059 typ host generation 0 network-id 2 network-cost 10<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 network-cost 10<br class=""><br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e m=video 13143 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:854729925 1 udp 2122194687 172.20.4.169 62061 typ host generation 0 network-id 2 network-cost 10<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:69946262 1 tcp 1518280447 192.168.208.1 9 typ host tcptype active generation 0 network-id 1<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:2087835701 1 tcp 1518214911 172.20.4.169 9 typ host tcptype active generation 0 network-id 2 network-cost 10<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp 25042943 <a href="http://35.jj.kk.mm/" rel="noreferrer" target="_blank" class="">35.jj.kk.mm</a> 13143 typ relay raddr 210.55.134.98 rport 53504 generation 0 network-id 2 network-cost 10<br class=""></div><div class=""><br class=""></div><div class="">The relay was chosen for video, and it appeared that the same candidate was going to be chosen for audio, but then an "AUDIO RTP" suggests it chose a private IPv4. And it seems that private IPv4 wasn't treated as a peer-reflexive candidate, so the media couldn't be routed...</div><div class=""><br class=""></div><div class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4338 Choose rtp candidate, index 2, <a href="http://35.jj.kk.mm:13143/" rel="noreferrer" target="_blank" class="">35.jj.kk.mm:13143</a><br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4104 verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4 choosing family v4<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4349 Choose same candidate, index 0, for rtcp based on rtcp-mux attribute <a href="http://35.jj.kk.mm:13143/" rel="noreferrer" target="_blank" class="">35.jj.kk.mm:13143</a><br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4401 setting remote video ice addr to index 2 <a href="http://35.jj.kk.mm:13143/" rel="noreferrer" target="_blank" class="">35.jj.kk.mm:13143</a> based on candidate<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:4436 Setting remote rtcp video addr to <a href="http://35.jj.kk.mm:13143/" rel="noreferrer" target="_blank" class="">35.jj.kk.mm:13143</a> based on candidate<br class="">f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568 [DEBUG] switch_core_media.c:8663 AUDIO RTP [verto.rtc/1200_a6dd33a4-1def-447c-a62a-ae807bb92da6_v-1*s-4] 10.0.0.100 port 26610 -> 192.168.208.1 port 62058 codec: 111 ms: 20<br class=""></div><div class=""><br class=""></div><div class="">Am I interpreting the log correctly?</div><div class=""><br class=""></div><div class="">Is there a way to avoid this?</div><div class=""><br class=""></div><div class="">Note that in /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml we already deny private IPv4 (although I think we should allow them so they could be used peer-reflexively):</div><div class=""> <list name="disallow-privateIPv4" default="allow"><br class=""> <node type="deny" host="10.0.0.0" mask="255.0.0.0"/><br class=""> <node type="deny" host="172.16.0.0" mask="255.240.0.0"/><br class=""> <node type="deny" host="192.168.0.0" mask="255.255.0.0"/><br class=""> </list></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div><br class=""></blockquote></div></div><br class=""></blockquote></div></blockquote></div></div>
_________________________________________________________________________<br class="">
<br class="">
The FreeSWITCH project is sponsored by SignalWire <a href="https://signalwire.com/" rel="noreferrer" target="_blank" class="">https://signalwire.com</a><br class="">
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.<br class="">
Build your next product on our scalable cloud platform.<br class="">
<br class="">
Join our online community to chat in real time <a href="https://signalwire.community/" rel="noreferrer" target="_blank" class="">https://signalwire.community</a><br class="">
<br class="">
Professional FreeSWITCH Services<br class="">
<a href="mailto:sales@freeswitch.com" target="_blank" class="">sales@freeswitch.com</a><br class="">
<a href="https://freeswitch.com/" rel="noreferrer" target="_blank" class="">https://freeswitch.com</a><br class="">
<br class="">
Official FreeSWITCH Sites<br class="">
<a href="https://freeswitch.com/oss" rel="noreferrer" target="_blank" class="">https://freeswitch.com/oss</a><br class="">
<a href="https://freeswitch.org/confluence" rel="noreferrer" target="_blank" class="">https://freeswitch.org/confluence</a><br class="">
<a href="https://cluecon.com/" rel="noreferrer" target="_blank" class="">https://cluecon.com</a><br class="">
<br class="">
FreeSWITCH-users mailing list<br class="">
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank" class="">FreeSWITCH-users@lists.freeswitch.org</a><br class="">
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank" class="">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br class="">
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank" class="">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br class="">
<a href="https://freeswitch.com/" rel="noreferrer" target="_blank" class="">https://freeswitch.com</a></blockquote></div></div>
_________________________________________________________________________<br class=""><br class="">The FreeSWITCH project is sponsored by SignalWire <a href="https://signalwire.com" class="">https://signalwire.com</a><br class="">Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.<br class="">Build your next product on our scalable cloud platform.<br class=""><br class="">Join our online community to chat in real time <a href="https://signalwire.community" class="">https://signalwire.community</a><br class=""><br class="">Professional FreeSWITCH Services<br class=""><a href="mailto:sales@freeswitch.com" class="">sales@freeswitch.com</a><br class="">https://freeswitch.com<br class=""><br class="">Official FreeSWITCH Sites<br class="">https://freeswitch.com/oss<br class="">https://freeswitch.org/confluence<br class="">https://cluecon.com<br class=""><br class="">FreeSWITCH-users mailing list<br class="">FreeSWITCH-users@lists.freeswitch.org<br class="">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br class="">UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br class="">https://freeswitch.com</div></blockquote></div><br class=""></body></html>