[Freeswitch-users] Current timestamp variable in dialplan?

[Antony Stone]

On Friday 11 November 2022 at 16:08:29, Brian West wrote:

> Inline.

Thanks :)

> 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 
server.

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 
elsewhere.

> 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.


Antony.

-- 
"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.