Re: [Freeswitch-users] rtp-timeout-sec VS media_timeout
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
For media timeout there are the following chan vars: media_timeout, media_hold_timeout, media_timeout, media_hold_timeout_video, media_hold_timeout_audio, media_timeout_audio . They are in milliseconds, not seconds like rtp-timeout-sec . <param name="media_timeout" value="300000"/> On Thu, Mar 4, 2021 at 4:47 AM 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
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
I recall that the rtp_* variable names were changed to media_* some time ago. I updated the wiki to reflect this. Now the question is: what version of code exhibited this behavior? If it was built before the change, then naturally the rtp_* series will be what it uses. --- John Boteler BnC Group U.S.A. From: FreeSWITCH-users <freeswitch-users-bounces@lists.freeswitch.org> On Behalf Of Dragos Oancea Sent: Thursday, 4 March, 2021 04:04 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] rtp-timeout-sec VS media_timeout For media timeout there are the following chan vars: media_timeout, media_hold_timeout, media_timeout, media_hold_timeout_video, media_hold_timeout_audio, media_timeout_audio . They are in milliseconds, not seconds like rtp-timeout-sec . <param name="media_timeout" value="300000"/> On Thu, Mar 4, 2021 at 4:47 AM David P <davidswalkabout@gmail.com <mailto: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 <mailto:freeswitch-users-request@lists.freeswitch.org> > wrote: ---------- Forwarded message ---------- From: Allan Kristensen <ak@hejdu.dk <mailto:ak@hejdu.dk> > To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto: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 _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
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
participants (3)
-
Bote Man
-
David P
-
Dragos Oancea