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

[David P]

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>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200829/8970600e/attachment.html>