[Freeswitch-users] Current timestamp variable in dialplan?

[Antony Stone]

On Wednesday 09 November 2022 at 20:23:50, Brian West wrote:

> All of this is already present in the XML CDR, each action, every step all
> time stamped down to microseconds and more accurate than setting
> variables.  Did you happen to load xml_cdr and do a call and see the
> information?

So, I have this morning had a chance to get back to this, and it turns out 
that <load module="mod_xml_cdr"/> was already in modules,conf.xml and I have a 
large number of large files under /var/log/freeswitch/xml_cdr from previously 
placed calls.

Comments / questions:

1. Aside from the timestamp variable assignment which I have put into the 
dialplan myself (the one which has already been discussed and you say is a bad 
idea because of session pool swell) I do not see any timestamps anywhere in 
the xml file - how do I enable these?

2. The xml file is enormous (20kbytes for a single call) and would take 
considerable parsing - where do I find the options to limit what information 
goes in there?

3. https://freeswitch.org/confluence/display/FREESWITCH/mod_xml_cdr tells me 
that this module can log to a file or using an HTTP POST.  Does this mean there 
is no way to get it to write to syslog?

I do nearly all logging (of everything that's running) to syslog, forward this 
with no further processing to a central syslog server, and then process / 
parse / aggregate / filter the data there, so as to reduce the workload on 
"worker" machines which generate the logs.

This also makes it easy to combine log output from different applications which 
are running independently (sometimes on different machines) but whose actions 
in processing one "transaction" (for want of a better word) are important to 
see in sequence.


So, I still wonder what is the best way to get microsecond-resolution 
timestamps for key events ("key" being defined by me) in FreeSwitch during the 
processing of a call.

Any suggestions on how to do this (preferably efficiently and without longer-
term drawbacks such as session pool swell) are welcome.


Thanks,


Antony.

-- 
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

                                                   Please reply to the list;
                                                         please *don't* CC me.