[Freeswitch-users] "No video stun for a long time!"

[David P]

We've been using FS 10.5 for a year or so...with verto for Chrome, Firefox,
and Safari on all desktop OSs, and we haven't seen a problem like this
before.

0:30 into a call, the mp4 recording of the session starts showing the FS
banner. The user is on Safari 14.0.2, macOS Mojave 10.14.6. The log seems
fine until suddenly "No video stun for a long time!" appears repeatedly
(see below).

The media_timeout should be more than adequate:

<action application="conference_set_auto_outcall"

data="['conference_member_flags=endconf,jitterbuffer_msec=5p:100p,media_timeout=500000']sofia/gateway/[deleted]"/>

The only thing we changed recently that I can think of is that we stopped
echoing the video back to verto. But testing across many client
combinations hasn't revealed any problem with that.

The only posts I can find that mention this warning are specific to iPhone,
but we've had no problem on iPhone/iPad,macOS in general.

Any guesses?

The log snippet...

2021-06-24 17:54:08.219324 [INFO] avformat.c:2576 use video codec
implementation Video: h264 (libx264), yuv420p(pc, gbr/unknown/unknown),
320x240, q=10-31, 82 kb/s
2021-06-24 17:54:08.219324 [NOTICE] avformat.c:785 video thread start
2021-06-24 17:54:08.219324 [DEBUG] switch_vpx.c:703 VPX VER:v1.8.1
VPX_IMAGE_ABI_VERSION:4 VPX_CODEC_ABI_VERSION:8
2021-06-24 17:54:08.219324 [DEBUG] conference_video.c:3380 Setting up video
write codec VP8 at slot 0 group _none_
c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:08.241930 [NOTICE]
switch_core_media.c:15852 Activating write resampler
2021-06-24 17:54:08.299856 [INFO] switch_vpx.c:564 config: vp8
2021-06-24 17:54:08.299856 [NOTICE] switch_vpx.c:599 VPX encoder reset
(WxH/BW) from 0x0/0 to 320x240/1024
c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:08.419309 [DEBUG]
conference_member.c:1764 Raw Codec Activation Success L16 at 8000hz 1 channel
20ms
c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:08.419309 [DEBUG]
conference_member.c:1811 Raw Codec Activation Success L16 at 48000hz 2 channel
20ms
c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:08.439299 [DEBUG]
conference_loop.c:1338 Setup timer soft success interval: 20  samples: 160
from codec PCMU
2021-06-24 17:54:08.679355 [DEBUG] avformat.c:595 colorspace = 0
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
profile Constrained Baseline, level 4.1
264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018
- http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0
analyse=0x1:0x111 me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0
me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11
fast_pskip=1 chroma_qp_offset=0 threads=3 lookahead_threads=1
sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0
constrained_intra=0 bframes=0 weightp=0 keyint=60 keyint_min=30 scenecut=40
intra_refresh=0 rc_lookahead=10 rc=cbr mbtree=1 bitrate=81 ratetol=1.0
qcomp=0.00 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=81 vbv_bufsize=81
nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00
2021-06-24 17:54:08.679355 [INFO] avformat.c:2576 use video codec
implementation Video: h264 (libx264), yuv420p(pc, gbr/unknown/unknown),
320x240, q=-1--1, 81 kb/s
2021-06-24 17:54:08.679355 [NOTICE] avformat.c:785 video thread start
c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:09.559310 [DEBUG]
switch_rtp.c:7793 Correct audio ip/port confirmed.
12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:02.819310 [WARNING]
switch_rtp.c:855 No audio stun for a long time!
12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:03.619308 [WARNING]
switch_rtp.c:855 No video stun for a long time!
12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:34.059362 [WARNING]
switch_rtp.c:855 No video stun for a long time!
12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:56:05.099323 [WARNING]
switch_rtp.c:855 No video stun for a long time!



On Thu, Mar 4, 2021 at 3:46 PM David P <davidswalkabout at gmail.com> wrote:

> Hi Allan,
>
> I don't know if the media_timeout=300 behavior you saw is a bug or not,
> but I wanted to add my own observation of weirdness about hangup
> cause MEDIA_TIMEOUT...
>
> I just noticed a conference end abruptly after one leg spoke for 5
> minutes. The logs aren't clear why this happened, but it seems that <param
> name="rtp-timeout-sec" value="300"/> in our sip_profiles/internal.xml is
> the reason -- it seems that because the *other* leg of the conference
> remained silent, the RTP timeout was reached.
>
> I couldn't find any confluence pages about MEDIA_TIMEOUT by googling.
>
> On Fri, Jan 8, 2021 at 1:08 AM <
> freeswitch-users-request at lists.freeswitch.org> wrote:
>
>>
>> ---------- Forwarded message ----------
>> From: Allan Kristensen <ak at hejdu.dk>
>> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>> Cc:
>> Bcc:
>> Date: Wed, 6 Jan 2021 19:37:33 +0100
>> Subject: [Freeswitch-users] rtp-timeout-sec VS media_timeout
>> We had some problems with "hanging channels" for our webrtc clients (via
>> kamailio).
>> To solve the problem I tried to use "media_timeout" setting but it didn't
>> really work. So I tried the deprecated "rtp-timeout-sec" and this actually
>> works fine?
>>
>> Not working:
>> <param name="media_timeout" value="300"/>
>>
>> Working:
>> <param name="rtp-timeout-sec" value="300"/>
>>
>> How to reproduce: Make a call using webrtc and just close browser window,
>> after some time freeswitch should close the channel because of missing rtp.
>> Instead it just keeps writing: "switch_rtp.c:853 No audio stun for a long
>> time!" forever...
>>
>> Anyway, it works now....just curious why...a typo or bug?
>>
>> /Allan
>>
>> Using:
>> FreeSWITCH Version 1.10.5-release+git~20200818T185121Z~25569c1631~64bit
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20210625/c1440ad5/attachment-0001.html>