<div dir="ltr"><div>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.</div><div><br></div><div>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).</div><div><br></div><div>The media_timeout should be more than adequate:</div><div><br></div><div><action application="conference_set_auto_outcall"<br>                            data="['conference_member_flags=endconf,jitterbuffer_msec=5p:100p,media_timeout=500000']sofia/gateway/[deleted]"/><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any guesses?</div><div><br></div><div>The log snippet...</div><div><br></div><div>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<br>2021-06-24 17:54:08.219324 [NOTICE] avformat.c:785 video thread start<br>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<br>2021-06-24 17:54:08.219324 [DEBUG] conference_video.c:3380 Setting up video write codec VP8 at slot 0 group _none_<br>c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:08.241930 [NOTICE] switch_core_media.c:15852 Activating write resampler<br>2021-06-24 17:54:08.299856 [INFO] switch_vpx.c:564 config: vp8<br>2021-06-24 17:54:08.299856 [NOTICE] switch_vpx.c:599 VPX encoder reset (WxH/BW) from 0x0/0 to 320x240/1024<br>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<br>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<br>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<br>2021-06-24 17:54:08.679355 [DEBUG] avformat.c:595 colorspace = 0<br>using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2<br>profile Constrained Baseline, level 4.1<br>264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - <a href="http://www.videolan.org/x264.html">http://www.videolan.org/x264.html</a> - 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<br>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<br>2021-06-24 17:54:08.679355 [NOTICE] avformat.c:785 video thread start<br>c82798ee-1825-4952-b0dd-8ed7c6969123 2021-06-24 17:54:09.559310 [DEBUG] switch_rtp.c:7793 Correct audio ip/port confirmed.<br>12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:02.819310 [WARNING] switch_rtp.c:855 No audio stun for a long time!<br>12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:03.619308 [WARNING] switch_rtp.c:855 No video stun for a long time!<br>12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:55:34.059362 [WARNING] switch_rtp.c:855 No video stun for a long time!<br>12c6801b-9409-adbc-ba01-15e788df9503 2021-06-24 17:56:05.099323 [WARNING] switch_rtp.c:855 No video stun for a long time!<br></div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 4, 2021 at 3:46 PM David P <<a href="mailto:davidswalkabout@gmail.com">davidswalkabout@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Allan,</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>I couldn't find any confluence pages about MEDIA_TIMEOUT by googling.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 8, 2021 at 1:08 AM <<a href="mailto:freeswitch-users-request@lists.freeswitch.org" target="_blank">freeswitch-users-request@lists.freeswitch.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>---------- Forwarded message ----------<br>From: Allan Kristensen <<a href="mailto:ak@hejdu.dk" target="_blank">ak@hejdu.dk</a>><br>To: FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>Cc: <br>Bcc: <br>Date: Wed, 6 Jan 2021 19:37:33 +0100<br>Subject: [Freeswitch-users] rtp-timeout-sec VS media_timeout<br><div dir="ltr">We had some problems with "hanging channels" for our webrtc clients (via kamailio).<div>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?</div><div><br></div><div>Not working:</div><div><param name="media_timeout" value="300"/><br></div><div><br></div><div>Working:</div><div><param name="rtp-timeout-sec" value="300"/></div><div><br></div><div>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.<br></div><div>Instead it just keeps writing: "switch_rtp.c:853 No audio stun for a long time!" forever...</div><div><br></div><div>Anyway, it works now....just curious why...a typo or bug?</div><div><br></div><div>/Allan</div><div><br></div><div>Using:</div><div>FreeSWITCH Version 1.10.5-release+git~20200818T185121Z~25569c1631~64bit</div></div></blockquote></div></div>
</blockquote></div></div>