FreeSWITCH timeout
Felipe Cecagno
Richard Alam
> Hi,
> We have seen that if a client crashes his name remains in the listeners list
> for a long time. Where can I configure the timeout for the automatic kick?
It's set to 5 min (300sec) by default.
See http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#rtp-timeout-sec
Let us know if it's different.
Richard
> Regards,
>
> --
> Felipe Cecagno
> Mconf Development Team - http://mconf.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton
Felipe Cecagno
Richard Alam
> Hi Richard,
> Running a grep looking for this parameter, I found:
> /opt/freeswitch/conf/sip_profiles/internal-ipv6.xml: <param
> name="rtp-timeout-sec" value="300"/>
> /opt/freeswitch/conf/sip_profiles/internal.xml: <param
> name="rtp-timeout-sec" value="300"/>
> /opt/freeswitch/conf/sip_profiles/external.xml: <param
> name="rtp-timeout-sec" value="10800"/>
Hmmmm....this should be 300...
I thought I reverted this to 300 but I guess not...
https://github.com/bigbluebutton/bigbluebutton/blob/master/bbb-voice-conference/config/freeswitch/conf/sip_profiles/external.xml
Doing it now.
Felipe Cecagno
<!--Set the RTP timeout for 3 hours to prevent FS from hanging up bbb clientswho are muted and not sending any audio.-->
Darren Schreiber
There are multiple ways to control when FreeSWITCH considers a channel to still be up. Unfortunately some of them are tricky.
First, there is something called a session timer. This is perhaps the most effective way – it means that a phone or user’s device (soft phone) sends a sort-of “Hello, are you still here?” message to the other end every X seconds. If the other end doesn’t reply, then it’s assumed they have hungup. This is probably the safest method when it works but the problem is many phones, carriers, etc. have this feature disabled. If it’s disabled, then one side may attempt to validate the call is up and when the other side ignores the request, the call is assumed dead and the call is dropped.
In FreeSWITCH, you can enable session timers and they will be used only if both ends agree they are supported, so this is usually safe to activate. http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#enable-timer has more details.
Second, there is RTP timeouts. RTP timeouts are a sort-of OK way to detect if someone has dropped out in some situations – it basically means “if I haven’t seen any audio from a user in X seconds, assume they have hungup. It’s good for setting to, say, 2 hours or something in case the call really has died and session timers weren’t available. The danger in using RTP timeouts is simple – if someone pushes mute on their phone, some phones stop sending RTP to save bandwidth. This will trigger a hangup after X seconds of being muted. Therefore, I don’t usually use this method, but you can … More details are at http://wiki.freeswitch.org/wiki/Sofia_Configuratio_Files#rtp-timeout-sec
If it were me, I’d set the RTP timeout seconds to 1800 (an hour) and I’d set the session timers to active. Then I’d make sure both the phone, and the carrier I use, support session timers. They’re theoretically more reliable though can be difficult to get working if you’re not sure what you’re doing.
- Darren
Richard Alam
>
>
> <!--
>
>
> Set the RTP timeout for 3 hours to prevent FS from hanging up bbb
The idea was that let users listen only. But FS hangs up the user if
it's not receiving RTP packets from that user after 5 minutes
(default).
But you see the problem where if a user is disconnected, the listener
window doesn't get cleaned up because FS will not hangup.
That's why even if the user needs to listen only. We have to need a
mic so that Flash sends a "silence" packets so that FS won't
disconnect the user.
We have plans to optimize this in the future when we work on
supporting webinar mode of meetings.
Richard
HostBBB.com
to talk on one of my servers, noticed 2 different classy audios
commented out in config.xml, one with push to talk. it looked like
it was working, but have not had time to really test, or look at the
source code yet.
Can you give us quick info, on state of that module, and whats still
missing to make this work. Ideally freeswitch would utilize a lot
less CPU if the audio in the webinar just played back thru red5
stream in listen only mode. I know its still experimental and not
focus currently.
I have an 8 core HI-CPU EC2 server (takes entire hardware one
instance) and wanted to test the scaling >25 in a controlled
environment, using some test scripts and Desktop Ubuntu Clould Servers
in same availability zone.
I am playing with BB collaborate and they allow the moderator to
select just 1-5 talkers, just stream oneway audio to the larger
audience, the same with video publish limiting it to just a few.
There is no authentication of their client, once a room is created
with meeting id, you can add other name users to conference, just
by editing a jnlp file and email to others, was surprised on the lack
of security.
Thanks for your help.
Stephen
On Sep 23, 3:18 pm, Richard Alam <ritza...@gmail.com> wrote:
>
> > <!--
>
> > Set the RTP timeout for 3 hours to prevent FS from hanging up bbb
> > client who are muted and not sending any audio.
>
> The idea was that let users listen only. But FS hangs up the user if
> it's not receiving RTP packets from that user after 5 minutes
> (default).
> But you see the problem where if a user is disconnected, the listener
> window doesn't get cleaned up because FS will not hangup.
>
> That's why even if the user needs to listen only. We have to need a
> mic so that Flash sends a "silence" packets so that FS won't
> disconnect the user.
>
> We have plans to optimize this in the future when we work on
> supporting webinar mode of meetings.
>
> Richard
>
>
>
>
>
>
>
> > -->
>
> > It means that if a client is just listening without sending his audio,
> > eventually he will be kicked from the voice conference?
>
>
> >> On Fri, Sep 23, 2011 at 2:38 PM, Felipe Cecagno <fceca...@gmail.com>
> >> > Hi Richard,
> >> > Running a grep looking for this parameter, I found:
> >> > /opt/freeswitch/conf/sip_profiles/internal-ipv6.xml: <param
> >> > name="rtp-timeout-sec" value="300"/>
> >> > /opt/freeswitch/conf/sip_profiles/internal.xml: <param
> >> > name="rtp-timeout-sec" value="300"/>
> >> > /opt/freeswitch/conf/sip_profiles/external.xml: <param
> >> > name="rtp-timeout-sec" value="10800"/>
>
> >> Hmmmm....this should be 300...
>
> >> I thought I reverted this to 300 but I guess not...
>
> >> Doing it now.
>
> >> > /opt/freeswitch/conf.dist/sip_profiles/internal-ipv6.xml: <param
> >> > name="rtp-timeout-sec" value="300"/>
> >> > /opt/freeswitch/conf.dist/sip_profiles/internal.xml: <param
> >> > name="rtp-timeout-sec" value="300"/>
> >> > /opt/freeswitch/conf.dist/sip_profiles/external.xml: <param
> >> > name="rtp-timeout-sec" value="300"/>
> >> > I don't know which one is used, but see that external.xml set the value
> >> > to 3
> >> > hours.
> >> > Regards,
> >> > wrote:
>
> >> >> On Fri, Sep 23, 2011 at 11:49 AM, Felipe Cecagno <fceca...@gmail.com>
> >> >> > Hi,
> >> >> > We have seen that if a client crashes his name remains in the
> >> >> > listeners
> >> >> > list
> >> >> > for a long time. Where can I configure the timeout for the automatic
> >> >> > kick?
>
> >> >> It's set to 5 min (300sec) by default.
>
> >> >> See
>