Presence BLF problems on FreeSWITCH 1.6.19
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. ______________________________________________________________________
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@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@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
Thanks, will give that a try and provide some feedback. ________________________________________ From: FreeSWITCH-users [freeswitch-users-bounces@lists.freeswitch.org] on behalf of António Silva [asilva@wirelessmundi.com] Sent: 23 November 2017 09:32 To: freeswitch-users@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@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@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@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@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. ______________________________________________________________________
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@lists.freeswitch.org] on behalf of Shaun Stokes [shaun.stokes@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@lists.freeswitch.org] on behalf of António Silva [asilva@wirelessmundi.com] Sent: 23 November 2017 09:32 To: freeswitch-users@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@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@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@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@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@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@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. ______________________________________________________________________
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@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@lists.freeswitch.org] on behalf of Shaun Stokes [shaun.stokes@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@lists.freeswitch.org] on behalf of António Silva [asilva@wirelessmundi.com] Sent: 23 November 2017 09:32 To: freeswitch-users@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
We’re still getting presence delays but it’s isolated to a single SIP profile, appears to be a bottleneck on the number of entries in the sip_subscriptions table (over 10k), we have second internal SIP profile which has less than 1000 entries and no presence issues. I’ve looked at a few articles, Kamailio looks like a good solution for presence, would be great if there was a similar module for FreeSWITCH. Using Kamailio as a SIP proxy to improve presence is one thing, but I imagine we’ll have similar problems with presence using Verto\WebRTC via FreeSWITCH. From: FreeSWITCH-users [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: 26 November 2017 21:47 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 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_B... Same with Polycom: http://community.polycom.com/polycom/attachments/polycom/VoIP/19112/1/Techni... How do we make this a feature request for Freeswitch? On Fri, Nov 24, 2017 at 4:00 AM, Shaun Stokes <shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of Shaun Stokes [shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of António Silva [asilva@wirelessmundi.com<mailto:asilva@wirelessmundi.com>] Sent: 23 November 2017 09:32 To: freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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. ______________________________________________________________________
I have found that freeswitch does not scale well with presence. I've seen it hit a bottleneck at around that same number of subscriptions (10,000). freeswitch's presence is SQL heavy so when you are dealing with that many subscriptions and presence updates it becomes a problem. I would recommend using something like Kamailio for presence. You can "extract" presence events from freeswitch and "publish" presence updates to kamailio using freeswitch's esl and kamailio's presence modules. I've seen kamailio operate under extremely high volume (~100,000 subscriptions) On Mon, Nov 27, 2017 at 4:00 PM, Shaun Stokes < shaun.stokes@itec-support.co.uk> wrote:
We’re still getting presence delays but it’s isolated to a single SIP profile, appears to be a bottleneck on the number of entries in the sip_subscriptions table (over 10k), we have second internal SIP profile which has less than 1000 entries and no presence issues.
I’ve looked at a few articles, Kamailio looks like a good solution for presence, would be great if there was a similar module for FreeSWITCH. Using Kamailio as a SIP proxy to improve presence is one thing, but I imagine we’ll have similar problems with presence using Verto\WebRTC via FreeSWITCH.
*From:* FreeSWITCH-users [mailto:freeswitch-users- bounces@lists.freeswitch.org] *On Behalf Of *Colton Conor *Sent:* 26 November 2017 21:47 *To:* FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
*Subject:* Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19
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@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@lists.freeswitch.org] on behalf of Shaun Stokes [shaun.stokes@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@lists.freeswitch.org] on behalf of António Silva [asilva@wirelessmundi.com] Sent: 23 November 2017 09:32 To: freeswitch-users@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@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@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@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@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@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@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@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@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@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@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 sounds like a great idea, however not sure how to change BLF lights on phones registered to FreeSWITCH without using PRESENCE_IN\PRESENCE_OUT events. If the phones are registered to FreeSWITCH but Kamailio is handling presence via FS ESL events then how do we can change the BLF lights on the phones? Using PRESENCE_IN\PRESENCE_OUT events results in FreeSWITCH checking the sip_subscriptions table which is our bottleneck. Thanks, Shaun ________________________________________ From: FreeSWITCH-users [freeswitch-users-bounces@lists.freeswitch.org] on behalf of E. Schmidbauer [eschmidbauer@gmail.com] Sent: 30 November 2017 22:37 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 I have found that freeswitch does not scale well with presence. I've seen it hit a bottleneck at around that same number of subscriptions (10,000). freeswitch's presence is SQL heavy so when you are dealing with that many subscriptions and presence updates it becomes a problem. I would recommend using something like Kamailio for presence. You can "extract" presence events from freeswitch and "publish" presence updates to kamailio using freeswitch's esl and kamailio's presence modules. I've seen kamailio operate under extremely high volume (~100,000 subscriptions) On Mon, Nov 27, 2017 at 4:00 PM, Shaun Stokes <shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@itec-support.co.uk>> wrote: We’re still getting presence delays but it’s isolated to a single SIP profile, appears to be a bottleneck on the number of entries in the sip_subscriptions table (over 10k), we have second internal SIP profile which has less than 1000 entries and no presence issues. I’ve looked at a few articles, Kamailio looks like a good solution for presence, would be great if there was a similar module for FreeSWITCH. Using Kamailio as a SIP proxy to improve presence is one thing, but I imagine we’ll have similar problems with presence using Verto\WebRTC via FreeSWITCH. From: FreeSWITCH-users [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Colton Conor Sent: 26 November 2017 21:47 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 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_B... Same with Polycom: http://community.polycom.com/polycom/attachments/polycom/VoIP/19112/1/Techni... How do we make this a feature request for Freeswitch? On Fri, Nov 24, 2017 at 4:00 AM, Shaun Stokes <shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of Shaun Stokes [shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of António Silva [asilva@wirelessmundi.com<mailto:asilva@wirelessmundi.com>] Sent: 23 November 2017 09:32 To: freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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. ______________________________________________________________________
Unless of course you are referring to using Kamailio as the registrar, we've been looking at this option but may need to bring in a Kamailio consultant. Thanks, Shaun ________________________________________ From: FreeSWITCH-users [freeswitch-users-bounces@lists.freeswitch.org] on behalf of Shaun Stokes [shaun.stokes@itec-support.co.uk] Sent: 01 December 2017 12:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 This sounds like a great idea, however not sure how to change BLF lights on phones registered to FreeSWITCH without using PRESENCE_IN\PRESENCE_OUT events. If the phones are registered to FreeSWITCH but Kamailio is handling presence via FS ESL events then how do we can change the BLF lights on the phones? Using PRESENCE_IN\PRESENCE_OUT events results in FreeSWITCH checking the sip_subscriptions table which is our bottleneck. Thanks, Shaun ________________________________________ From: FreeSWITCH-users [freeswitch-users-bounces@lists.freeswitch.org] on behalf of E. Schmidbauer [eschmidbauer@gmail.com] Sent: 30 November 2017 22:37 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 I have found that freeswitch does not scale well with presence. I've seen it hit a bottleneck at around that same number of subscriptions (10,000). freeswitch's presence is SQL heavy so when you are dealing with that many subscriptions and presence updates it becomes a problem. I would recommend using something like Kamailio for presence. You can "extract" presence events from freeswitch and "publish" presence updates to kamailio using freeswitch's esl and kamailio's presence modules. I've seen kamailio operate under extremely high volume (~100,000 subscriptions) On Mon, Nov 27, 2017 at 4:00 PM, Shaun Stokes <shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@itec-support.co.uk>> wrote: We’re still getting presence delays but it’s isolated to a single SIP profile, appears to be a bottleneck on the number of entries in the sip_subscriptions table (over 10k), we have second internal SIP profile which has less than 1000 entries and no presence issues. I’ve looked at a few articles, Kamailio looks like a good solution for presence, would be great if there was a similar module for FreeSWITCH. Using Kamailio as a SIP proxy to improve presence is one thing, but I imagine we’ll have similar problems with presence using Verto\WebRTC via FreeSWITCH. From: FreeSWITCH-users [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Colton Conor Sent: 26 November 2017 21:47 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Presence BLF problems on FreeSWITCH 1.6.19 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_B... Same with Polycom: http://community.polycom.com/polycom/attachments/polycom/VoIP/19112/1/Techni... How do we make this a feature request for Freeswitch? On Fri, Nov 24, 2017 at 4:00 AM, Shaun Stokes <shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of Shaun Stokes [shaun.stokes@itec-support.co.uk<mailto:shaun.stokes@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] on behalf of António Silva [asilva@wirelessmundi.com<mailto:asilva@wirelessmundi.com>] Sent: 23 November 2017 09:32 To: freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@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@lists.freeswitch.org<mailto:FreeSWITCH-users@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@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@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. ______________________________________________________________________
You can easily make kamailio the registrar and handle presence but you can just as easily move only presence to kamailio. regardless of that, what i meant by using ESL was: subscribe to channel events (i use CHANNEL_CALLSTATE), use the `Channel-Presence-Data` event header (and some other useful ones) to "track" calls/channels you can even filter events to you only get "user" related events send updates to kamailio via xhttp or nsqd or amqp (kazoo module) based on the events from freeswitch. kamailio will update it's presence data, send out the NOTIFYs
participants (4)
-
António Silva
-
Colton Conor
-
E. Schmidbauer
-
Shaun Stokes