[Freeswitch-users] rtp-timeout-sec VS media_timeout
davidswalkabout at gmail.com
Thu Mar 4 02:46:11 UTC 2021
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
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 at lists.freeswitch.org> wrote:
> ---------- Forwarded message ----------
> From: Allan Kristensen <ak at hejdu.dk>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> 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
> 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"/>
> <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?
> FreeSWITCH Version 1.10.5-release+git~20200818T185121Z~25569c1631~64bit
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FreeSWITCH-users