[Freeswitch-users] One-way audio but not video on 10.4

Tue Sep 15 23:36:07 UTC 2020

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.

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.

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?

On Tue, Sep 1, 2020 at 12:22 AM <
freeswitch-users-request at lists.freeswitch.org> wrote:

> ---------- Forwarded message ----------
> From: David P <davidswalkabout at gmail.com>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> Cc:
> Bcc:
> Date: Mon, 31 Aug 2020 08:36:05 +1200
> Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4
>
>> 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.
>
> 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.
>
> --------- Forwarded message ----------
>> From: Nathan Stratton <nathan at robotics.net>
>> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>> Cc:
>> Bcc:
>> Date: Sat, 29 Aug 2020 11:13:24 -0400
>> Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4
>> 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.
>>
>> ><>
>> nathan stratton
>>
>>
>> On Sat, Aug 29, 2020 at 3:00 AM David P <davidswalkabout at gmail.com>
>> wrote:
>>
>>> The client is current verto running on current Chrome/Win10.
>>>
>>> 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.
>>>
>>> ---------- Forwarded message ----------
>>>> From: Mike Jerris <mike at freeswitch.org>
>>>>
>>>> If client still isn’t putting in non rfc1918 candidates in audio you
>>>> need to figure out why that is first.
>>>>
>>>> On Aug 26, 2020, at 7:17 PM, David P <davidswalkabout at gmail.com> wrote:
>>>>
>>>> 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.
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>>> From: Mike Jerris <mike at freeswitch.org>
>>>>> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>>>>> Cc:
>>>>> Bcc:
>>>>> Date: Wed, 26 Aug 2020 16:19:56 -0400
>>>>> Subject: Re: [Freeswitch-users] One-way audio but not video on 10.4
>>>>>
>>>>
>>>>
>>>>> Configure stun in your client so you get proper candidates that are
>>>>> reachable.
>>>>>
>>>>> On Aug 19, 2020, at 6:18 PM, David P <davidswalkabout at gmail.com>
>>>>> wrote:
>>>>>
>>>>> 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).
>>>>>
>>>>> I was using:
>>>>> FreeSWITCH Version
>>>>> 1.10.4-release+git~20200805T110119Z~133fc2c870~64bit (git 133fc2c
>>>>> 2020-08-05 11:01:19Z 64bit)
>>>>> from Chrome84/Win10
>>>>>
>>>>> I noticed the video candidates included a relay but the audio ones
>>>>> didn't:
>>>>>
>>>>> 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
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 192.168.208.1
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp
>>>>> 2122260223 192.168.208.1 62058 typ host generation 0 network-id 1
>>>>> 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
>>>>> 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
>>>>> 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
>>>>>
>>>>> 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
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e c=IN IP4 35.160.47.89
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=rtcp:9 IN IP4 0.0.0.0
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:1252570982 1 udp
>>>>> 2122260223 192.168.208.1 62060 typ host generation 0 network-id 1
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e a=candidate:3112167340 1 udp
>>>>> 25042943 35.jj.kk.mm 13143 typ relay raddr 210.55.134.98 rport 53504
>>>>> generation 0 network-id 2 network-cost 10
>>>>>
>>>>> 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...
>>>>>
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568
>>>>> [DEBUG] switch_core_media.c:4338 Choose rtp candidate, index 2,
>>>>> 35.jj.kk.mm:13143
>>>>> 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
>>>>> 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 35.jj.kk.mm:13143
>>>>> 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
>>>>> 35.jj.kk.mm:13143 based on candidate
>>>>> f6e23797-4ad2-b761-2a6d-97846c122d7e 2020-08-19 05:14:33.753568
>>>>> [DEBUG] switch_core_media.c:4436 Setting remote rtcp video addr to
>>>>> 35.jj.kk.mm:13143 based on candidate
>>>>> 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
>>>>>
>>>>> Am I interpreting the log correctly?
>>>>>
>>>>> Is there a way to avoid this?
>>>>>
>>>>> 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):
>>>>>     <list name="disallow-privateIPv4" default="allow">
>>>>>         <node type="deny" host="10.0.0.0" mask="255.0.0.0"/>
>>>>>         <node type="deny" host="172.16.0.0" mask="255.240.0.0"/>
>>>>>         <node type="deny" host="192.168.0.0" mask="255.255.0.0"/>
>>>>>     </list>
>>>>>
>>>>>
>>>>
>>> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200916/572ec6f6/attachment-0001.html>