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