> >The danger here is that in our current integration model, > sipXonfig is > >the master for all configuration. It is through it that IM users, > >Multi-user chatrooms and IM groups can be provisioned. Having the > >sipXconfig as the master makes it very easy to tie the > openfire config > >into our existing backup and restore scheme and concentrates all the > >system's config information in one place which makes thing generally > >simpler. If we were to allow a backdoor (such as the openfire web > >portal) through which openfire config can be modified without > >sipXconfig's knowledge, sipXconfig would no longer be the complete > >master of the configuration and its view of the current openfire > >configuration would only be partial. This creates backup & restore > >issues, loss of config data and opens the door for invalid > >configurations. > > Completely agree. I wasn't suggesting a full wiki page with > step by step instructions on how to enable, but an emergency > back door. ;) > > >other products like sipXecs. The main contention point is > around the > >copyrighted openfire logo I believe. > > Very understandable. > > >accessible via sipXconfig to address the users needs. For our first > >release we picked a modest subset that still delivered a lot of > >functionality. > > I agree there is a lot of functionality, but I do believe > that even in the first "round" you should be able to shut off > federation totally if needed. I'm guessing that the hole > mentioned is indeed a bug... As an enterprise we don't want > users to be able to setup federated IM as a rule. Even if > there is a all or nothing option in Sipx, that would be fine. > In Kraken you can set it per user or with manual > registrations, so hopefully this is something that can be > switched off if wanted before > 4.2 is released. Even if it was a manual hand change to an > file I would be happy. Otherwise I won't be able to implement here...
You can shut off Sever-to-server XMPP federation completely in the subset of openfire we expose. That is, you can prevent your users from adding a gmail, googletalk, jabber or any other XMPP account as a buddy on your openfire account. However, sipXecs cannot do anything about preventing someone from downloading a multiprotocol IM client such as pidgin and connecting it directly to MSN, Yahoo, Googletalk, ICQ, AIM, etc (i.e. without going through sipXecs). You would have to disable those services in your firewall to really lock that down. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
