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

Tue Sep 22 02:05:00 UTC 2020

Thanks for confirming, Mike. To me, that sounds like FSv10 supports
peer-reflexive candidates. In fact, I realize now that I've verified this
feature recently.

However, we still get one-way media at one of our test sites. A pcap with
this display filter...

ip.dst == <public IP number of my FS 10.4>

...shows only TLSv1.3 and TCP packets to port 8082, which indicate that the
handshake succeeded but verto on Chrome85 never sent any media.

When I test from my site with a different Win10 machine but also using
Chrome85 and the same FS, my pcap reveals TLSv1.2 and media goes both ways.

We're going to do additional tests by varying the client machine and client
network, but if something so far suggests a reason for one-way audio,
please let me know.

---------- Forwarded message ----------
> From: Mike Jerris <mike at freeswitch.org>
>
> 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.
>
> On Sep 15, 2020, at 7:36 PM, David P <davidswalkabout at gmail.com> wrote:
>
> 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>
>>>>>>
>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20200922/d65e3b1c/attachment-0001.html>