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