> > 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"
2- [sipXconfig] Replicate the selected "IM Message Logger" setting is
sipxopenfire.xml using a new XML parameter
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/

Reply via email to