Hi, I'm operating a cluster of three FS boxes "behind" an OpenSIPs balancer/proxy that's not in the media path, but proxies everything SIP related in- and outbound. The central brain is a mysql master/slave setup and I'm using a combination of NFS and rsync to keep configs and voicemail synced. I want to balance registrations and calls to all three boxes, but because of the following issues, currently only one FS is active, the others on hot standby. The things that are still troubling me are: 1) Group intercept (*8) isn't working 2) Presence subscriptions aren't working 3) mod_callcenter is misbehaving badly - nonworking. I was thinking, that with everything moved to the database, the single boxes should be aware of callstates and uuids on the other boxes, like they know about which user is registered to which FS. Now I'm not sure if I've forgotten something, or if a multie-active setup would be a trade-off between redundancy and loss of features? All FreeSWITCHes are up-to-date, odbc-dsn has been set for all important modules: /usr/local/freeswitch/conf/autoload_configs$ grep dsn * | grep -v '!--' callcenter.conf.xml: <param name="odbc-dsn" value="freeswitch"/> db.conf.xml: <param name="odbc-dsn" value="freeswitch"/> switch.conf.xml: <param name="core-db-dsn" value="freeswitch" /> voicemail.conf.xml: <param name="odbc-dsn" value="freeswitch"/> and for both profiles: $ grep dsn /usr/local/freeswitch/conf/sip_profiles/* | grep -v '!--' /usr/local/freeswitch/conf/sip_profiles/external.xml: <param name="odbc-dsn" value="freeswitch"/> /usr/local/freeswitch/conf/sip_profiles/internal.xml: <param name="odbc-dsn" value="freeswitch"/> track-calls is also set for both of them, even though I guess this isn't relevant for my problems as long as I don't use recovery? $ grep track /usr/local/freeswitch/conf/sip_profiles/* | grep -v '!--' /usr/local/freeswitch/conf/sip_profiles/external.xml: <param name="track-calls" value="true"/> /usr/local/freeswitch/conf/sip_profiles/internal.xml: <param name="track-calls" value="true"/> As for group intercept, the log says (yes, I stripped most of it, you all know the default dialplan I guess ;) --- Dialplan: sofia/internal/1001@sip.example.org Regex (PASS) [group-intercept] destination_number(*8) =~ /^\*8$/ break=on-false Dialplan: sofia/internal/1001@sip.example.org Action answer() Dialplan: sofia/internal/1001@sip.example.org Action set(intercept_unanswered_only=true) Dialplan: sofia/internal/1001@sip.example.org Action intercept(${hash(select/${domain_name}-last_dial/${call_group})}) Dialplan: sofia/internal/1001@sip.example.org Action sleep(2000) EXECUTE sofia/internal/1001@sip.example.org set(call_direction=local) EXECUTE sofia/internal/1001@sip.example.org answer() 2012-07-27 22:31:35.693292 [NOTICE] mod_dptools.c:1148 Channel [sofia/internal/1001@sip.example.org] has been answered EXECUTE sofia/internal/1001@sip.example.org set(intercept_unanswered_only=true) EXECUTE sofia/internal/1001@sip.example.org intercept() 2012-07-27 22:31:35.693292 [ERR] mod_dptools.c:714 Usage: [-bleg] <uuid> --- in extension local_extension, the needed information gets stored in this hash: <action application="hash" data="insert/${domain_name}-last_dial/${called_party_call_group}/${uuid}" /> and this is working just fine, when enabling only one of the FS boxes. Did I miss something to share the content of hash's memory? What could I have missed, that subscriptions aren't working cross FS? (sip_subscriptions is filled pretty good, but BLF isn't working anyway) Any ideas if mod_callcenter should be working at all? I'm not quite sure how to interpret this note in the config: <!-- WARNING: Agents and Tiers XML config shouldn't be used in a multi FS shared DB setup (Not currently supported anyway) --> does that mean, mod_callcenter doesn't support multi FS setups or does it mean, that XML config isn't supported for multi FS environments, but it should be working fine with odbc? All of it's config exists in the database (callcenter_config works and confirms the config on all of the FS boxes), but it doesn't work since the moment more than one FS box accessed the database... Well, I know this is quite a beast of an email, but I'd really appreciate any pointers in the right direction! Thanks!