[Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19

Sun Nov 26 21:47:06 UTC 2017

Unfortunately Freeswitch does not yet support RFC 4662 aka BLF Resource
Lists. I would recommend you look at Kamiliio or Asterisk which both
support support RFC 4662, and should significantly reduce your BLF load.
Info:

Asterisk does: https://wiki.asterisk.org/wiki/pages/viewpage.
action?pageId=30278158 They have a good overview page

Kamillio does: https://kamailio.org/docs/modules/3.2.x/modules_k/rls.html

Good info from Grandsteam about why to use this: http://www.grandstream.
com/sites/default/files/Resources/GXP21x0_Eventlist_BLF_Guide.pdf

Same with Polycom: http://community.polycom.com/polycom/
attachments/polycom/VoIP/19112/1/Technical%20Brief%20-%
20Busy%20Lamp%20Field.pdf

How do we make this a feature request for Freeswitch?

On Fri, Nov 24, 2017 at 4:00 AM, Shaun Stokes <
shaun.stokes at itec-support.co.uk> wrote:

> Performance using PostgreSQL seems better but possibly too soon to tell,
> however we now have the ability to analyse the data and have identified
> that there is one domain that accounts for over 90% of the entries (over
> 12000, 11000 of which are presence) in our sip_subscriptions table. All
> domains use presence but others typically have around 100 entries in
> sip_subscriptions.
>
> If the bottleneck was the DB file then PostgreSQL should have solved this,
> but I'm still concerned by the number of presence events in our
> sip_subscriptions table. How many presence events does FreeSWITCH support
> in the sip_subscriptions table? Are there are any other recommendations to
> get the best performance out of FreeSWITCH in this scenario?
>
> We have 32 logical cores (8 physical) but CPU usage rarely goes above 10%.
>
> Thanks,
> Shaun
> ________________________________________
> From: FreeSWITCH-users [freeswitch-users-bounces at lists.freeswitch.org] on
> behalf of Shaun Stokes [shaun.stokes at itec-support.co.uk]
> Sent: 23 November 2017 09:45
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19
>
> Thanks, will give that a try and provide some feedback.
> ________________________________________
> From: FreeSWITCH-users [freeswitch-users-bounces at lists.freeswitch.org] on
> behalf of António Silva [asilva at wirelessmundi.com]
> Sent: 23 November 2017 09:32
> To: freeswitch-users at lists.freeswitch.org
> Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19
>
> Hi,
>
> We had the same problem using sqlite files as core db, under heavy load
> sqlite backend is not that fast... switching it to postgresql solved the
> issue.
>
> Hope it helps.
>
>
> On 11/23/2017 10:15 AM, Shaun Stokes wrote:
> > Does anyone have experience with presence on FreeSWITCH when under load?
> We've considered offloading presence to a Kamailio proxy but it would great
> if we could understand the limitations of presence on FreeSWITCH and
> recommended configuration for best performance under load.
> >
> > We've been experiencing issues with presence (BLF) intermittently not
> working or being delayed by 5 minutes or more. The BLF lights may show an
> extension as available when they're on the phone, as ringing when they're
> available etc. This problem can only be re-produced on a system which has
> been under load but it doesn't occur immediately unless the system has been
> running for a couple of weeks. This effects multiple SIP profiles in a
> multi-tenant (multi domain) environment with roughly 800 registrations, 500
> registrations on one SIP profile and 300 on another.
> >
> > The FreeSWITCH DB files use a 512MB RAM disk and we've balanced
> extensions across multiple SIP profiles using separate (not shared) DB
> files to distribute load.
> >
> > What we've noticed is the internal DB files (i.e. sofia_reg_internal.db)
> appear to increase exponentially over time after roughly 22MB we often
> start to run into problems with presence while the system is under load,
> restarting FreeSWITCH and flushing the internal DB files clears the problem.
> >
> > Interestingly we didn't have this problem on FreeSWITCH 1.4
> >
> > We've recently adjusted the following settings on our internal SIP
> profiles and are continuing to monitor:
> > force-subscription-expires [900] -> [1800]
> > sip-subscription-max-deviation [300] -> [600]
> > max-proceeding [1000] -> [5000]
> > initial-event-threads [2] -> [4]
> >
> > Here is a snippet of our internal SIP profile configuration:
> > nonce-ttl [60]
> > outbound-codec-prefs [G722,PCMA,H264]
> > pass-rfc2833 [true]
> > record-path [/path/freeswitch/recordings]
> > record-template [${domain_name}/archive/${strftime(%Y)}/${strftime(%b)}/
> ${strftime(%d)}/${uuid}.${record_ext}]
> > multiple-registrations [contact]
> > inbound-reg-force-matching-username [true]
> > inbound-reg-in-new-thread [true]
> > initial-event-threads [4]
> > local-network-acl [localnet.auto]
> > manage-presence [true]
> > unregister-on-options-fail [true]
> > tls-version [tlsv1.2]
> > tls-cert-dir [/path/freeswitch/certs]
> > tls-bind-params [transport=tls]
> > tls [true]
> > stun-enabled [false]
> > stun-auto-disable [false]
> > sip-trace [no]
> > sip-subscription-max-deviation [600]
> > sip-port [xxxx]
> > sip-ip [x.x.x.x]
> > sip-force-expires [900]
> > sip-expires-max-deviation [300]
> > sip-capture [no]
> > rtp-timeout-sec [0]
> > rtp-timer-name [soft]
> > rtp-ip [x.x.x.x]
> > rtp-hold-timeout-sec [0]
> > tls-verify-in-subjects []
> > tls-verify-depth [2]
> > tls-verify-date [true]
> > tls-sip-port [xxxx]
> > tls-passphrase []
> > tls-only [false]
> > inbound-codec-prefs [G722,PCMA,H264]
> > inbound-codec-negotiation [greedy]
> > log-auth-failures [true]
> > user-agent-string [FreeSWITCH]
> > watchdog-enabled [no]
> > watchdog-event-timeout [30000]
> > watchdog-step-timeout [30000]
> > ext-rtp-ip [x.x.x.x]
> > accept-blind-auth [false]
> > accept-blind-reg [false]
> > aggressive-nat-detection [true]
> > apply-inbound-acl [domains]
> > apply-nat-acl [nat.auto]
> > auth-all-packets [false]
> > auth-calls [true]
> > challenge-realm [auto_from]
> > context [public]
> > debug [0]
> > dialplan [XML]
> > dtmf-duration [2000]
> > dtmf-type [rfc2833]
> > enable-timer [true]
> > ext-sip-ip [x.x.x.x]
> > registration-thread-frequency [240]
> > rfc2833-pt [101]
> > force-subscription-expires [1800]
> > forward-unsolicited-mwi-notify [false]
> > hold-music [local_stream://default]
> > nat-options-ping [true]
> > NDLB-force-rport [safe]
> > max-proceeding [5000]
> >
> > ______________________________________________________________________
> > This message has been checked for all known viruses by  MessageLabs
> Virus Scanning Service.
> > ______________________________________________________________________
> >
> > ____________________________________________________________
> _____________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
>
> --
> Saludos / Regards / Cumprimentos
> António Silva
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> ______________________________________________________________________
> This message has been checked for all known viruses by MessageLabs Virus
> Scanning Service.
> ______________________________________________________________________
>
> ______________________________________________________________________
> This message has been checked for all known viruses by  MessageLabs Virus
> Scanning Service.
> ______________________________________________________________________
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> ______________________________________________________________________
> This message has been checked for all known viruses by MessageLabs Virus
> Scanning Service.
> ______________________________________________________________________
>
> ______________________________________________________________________
> This message has been checked for all known viruses by  MessageLabs Virus
> Scanning Service.
> ______________________________________________________________________
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171126/016e94e6/attachment.html>