> Robert Joly wrote: > >>> Hi, > >>> There are a few parameters editable via sipXconfig (or that > >> sipXconfig > >>> will hardcode for start). > >>> Most probably sipXconfig will store these params as user > >> settings; the > >>> question is where does sipXopenfire need to retrieve > those settings > >>> from? > >>> (Is it sipxopenfire.xml, or from another location)? > >> I think we need to take a giant step back on that one. > The tracker > >> states a requirement and proposes a solution based on > message audits. > >> I'm not at all convinced at this point that this feature should be > >> done via message audits. I'm hoping that there are better ways to > >> get at the logged messages than to do some post processing on the > >> entirety of XMPP messages that have been exchanged between clients. > >> > >> The first step towards the resolution of this problem is > to appoint > >> someone to evaluate the possible approaches to solving > this issue. > >> Once this is done, the sipXconfig requirements will become clear. > >> > >> > >> [Forwarding this to the list, as I've sent to wrong list > address in > >> the first place] > > > > I had conversations with other team members about the requirements > > around that feature and all that is effectively required for this > > release is for conversations to be recorded somewhere on the hard > > drive and for that file to be retrievable from the system. > There is > > no need (for this release at least) to offer within > sipXconfig a way > > to filter or even render that file. Under this set of > requirements, I > > can envision a solution that would be very simple. Here is what I'm > > proposing. > > > > Our sipXopenfire plugin, being a packet interceptor for @call and > > @conf directives support, already sees and logs every message > > exchanged on the server. The issue with this current > scheme is that > > the logging is intermixed with all the other stuff that > sipXopenfire > > is logging (FSM state changes, SIP messages). I'm > proposing to change > > sipXopenfire to log the XMPP IM and chat messages specifically to a > > separate file so that it only contains a recording of the > conversations and nothing else. > > Here are the changes that I believe would be required in the system: > > 1- [sipXconfig] Add a new component under system->Logging level for > > "IM Message Logger" and have a pull-down with two options: > "Enabled" > > or "Disabled" > > > I don't think this is the right place. Message Logging is > different from Diagnostics logs, and diagnostics logs have a > very different set of options. > Let's just put it on IM Messaging screen.
Sounds logical. > > 2- [sipXconfig] Replicate the selected "IM Message Logger" > setting is > > sipxopenfire.xml using a new XML parameter > > Make sense: what do you want the exact name/syntaxt of the > setting to be? > Do we want this to be enabled by default? Here are the proposed names and defaults. <IM-message-logging>true</IM-message-logging> <IM-message-logging-directory>/var/log/sipxpbx</IM-message-logging-direc tory> > > Is there any connection between this setting and 'log-conversations' > setting for a conference? Good point. I need to look into this but my initial feeling would the that this parameter should be nuked (or at least hidden). > > > 3- [sipXopenfire] Extract the "IM Message Logger" setting from > > sipxopenfire.xml and log IM messages to a dedicated log > file if enabled. > > > > An administrator interested in getting access to the generated log > > file can do so via the existing snapshot facilities. > > > > I believe that it his is every simple solution that does > address the > > requirements. We can re-visit the whole topic if/when we want to > > pretty up the feature to make it more admin-accessible via > sipXconfig. > > > > Comments? > > _______________________________________________ > 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/ > _______________________________________________ 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/
