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@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@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@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@lists.freeswitch.org> wrote:
---------- Forwarded message ---------- From: Allan Kristensen <ak@hejdu.dk> To: FreeSWITCH Users Help <freeswitch-users@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