[Freeswitch-users] Current timestamp variable in dialplan?
Antony.Stone at freeswitch.open.source.it
Fri Nov 11 15:40:28 UTC 2022
On Friday 11 November 2022 at 16:08:29, Brian West wrote:
> On Fri, Nov 11, 2022 at 5:03 AM Antony Stone wrote:
> > 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?
> You found app_stamp, that's microseconds epoch
So, I take it that that is the only format available - no chance of ISO 8601?
> > 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?
> No way to limit the info, also this info is very handy for figuring out
> what took place after the fact.
I regard that as "debug level logging" and I wouldn't run a production server
with debugging permanently enabled.
I'd say I'm looking for the "info" equivalent.
> > 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?
> Syslog for CDR? Just load mod_syslog and configure it for logging.
Already doing that - doesn't output the timestamps I see in xml_cdr.
> You should use the post method with fallback and isolate the CDR processing
> infrastructure and not intermingle that into syslog.
As I've said previously, I am not trying to do this logging for any purpose to
do with billing, so although we've got onto the topic of CDRs here, I'm not
trying to use them for any "traditional" purpose of CDRs - it just seems that
that's the way to get this sort of data out of FreeSwitch.
> > 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.
> Do you currently experience this 'workload' that is impacting anything?
1. I don't know, but every little helps - if I can focus one machine on
processing phone calls, and another one on analysing the timing data of those
calls, I think that's a better approach than trying to do everything on one
2. There are already multiple machines handling phone calls, all forwarding
syslog data to a central aggregator (partly because I need to combine timing
data from different machines which interact with each other during call
processing, so that the entire call flow (across several machines) is visible
in a single log).
3. The system needs to be scaleable, and one of my approaches to that is to
separate different tasks to different machines, so that if the workload of one
type of task increases, I can implement more of that type of machine, without
its workload having been driven up by something that should have been handled
> I want to make sure you're not wasting your time trying to wax your car to
> get better gas mileage.
I'm half-way between a development and a production environment with this.
There are already production servers handling "real-world" calls and I don't
intend to perform such detailed logging (although still some, and requiring
good timestamps) on those. On the development machines, though, I want the
timestamps at many more stages during call processing (across several machines
which interact to handle a single call) so that I can actually measure the
aerodynamics (to extend your analogy) of the system and identify where it
might be worth reshaping some body part.
Until I get the data, I don't know where to focus the effort, so I'm currently
trying to collect the data in the best way possible.
Is there somewhere I can read up on what session pools are and what sorts of
things cause them to swell? I hadn't come across the term bofore you
mentioned it a couple of days ago.
"Measuring average network latency is about as useful as measuring the mean
temperature of patients in a hospital."
- Stéphane Bortzmeyer
Please reply to the list;
please *don't* CC me.
More information about the FreeSWITCH-users