On Thu, 16 Jul 2009 15:22:32 -0400, Robert Joly wrote: > Folks, > I noticed that XX-5547 calls for the addition of many information > elements related to a user. One of those elements is the IM Handle > which is defined as the IM handle to be used on the sipXecs system. As > part of our Openfire integration work, we have added an IM ID field to > the 'Add User' page. Upon creating a new SIP user with a non-blank IM > ID, sipXconfig executes the appropriate XML-RPC requests to have the > corresponding IM account created in Openfire. My question is about the > relationship between the IM ID field in the 'add user' page and the 'IM > handle' in the user portal requested in XX-5547. Are these fields one > and the same? Will sipXconfig request openfire account creation upon > initialization/modification of the 'IM handle' from the user portal? >
My apologies if this is a slight hijacking, as I probably won't answer the actual question... The current way that sipXconfig handles the openfire configuration is probably going to need to be modified. Ranga and I spoke about this yesterday and are planning a talk in the morning on #sipx. I notified the sipXconfig crew this morning so those who are interested can be there. The short story is that any configuration that is done via sipXconfig should be stored in the sipXconfig database. Therefore, any new fields that are added to support openfire, such as the user's IM handle, need to be modeled as part of a sipXconfig user and stored locally. Any replication to the openfire server should then go through the regular channels, or a new channel, such as XML-RPC direct to the openfire process, but still through the standard sipXconfig replication mechanism. So, more to the point, if these handles are one and the same (it sounds like they are), there should only be one master copy of that data, living in sipXconfig. The openfire server will be updated with that new/changed data when replication takes place. Kevin _______________________________________________ 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/
