Inline below.

On Fri, Nov 4, 2022 at 11:06 AM Antony Stone <Antony.Stone@freeswitch.open.source.it> wrote:
On Friday 04 November 2022 at 16:05:39, Brian West wrote:

> The way the dial plan is compiled and executed will vary depending on a lot
> of factors, what purpose are you using this for? because it's a metric that
> will show little to no variance, your best bet is to turn on xml_cdr and
> use that it has all the info and history of what and when things took
> place.  Don't burden the dialplan with these sorts of tasks as freeswitch
> wasn't designed to be used like that.

Okay, I'll look at xml_cdr.

I'm currently using cdr_odbc - do you see any problem in using both?

No issue at all, cdr_odbc gives you a fraction of the info that xml_cdr does.
 

Also, just for a definitive answer, do I take it that there is no variable
which the dialplan can reference in order to get the current timestamp?

I'd not recommend doing that, because every time you do a get var, you cause a pool allocation and doing this in a loop will make your session pool swell at the rate of whatever you're calling get_var on.  Doing anything at all inline with the dialplan is not the right approach.  your logic and info should be all external, keying off events either on ESL or custom modules you wrote.
 


Antony.

> On Wed, Nov 2, 2022 at 2:03 PM Antony Stone wrote:
> > On Wednesday 02 November 2022 at 18:25:52, Brian West wrote:
> > > What problem are you trying to solve?  I still can't clearly
> > > understand what you're trying to accomplish.
> >
> > Oh, I didn't realise you wanted to know what I planned to *do* with the
> > information - I thought you were just trying to understand exactly what
> > information I need.
> >
> > So, to answer your question about why I need these timestamps, I have
> > specific points throughout the dialplan where I need to know the current
> > (accurate) timestamp, in order to collect statistics on the efficiency
> > of different parts of the dialplan (basically, how long does *this* section
> > take to complete, how long does *that* section take, etc).
> >
> > These timing values are then combined with similar timestamps from other
> > parts of the system (which includes Asterisk, database lookups, and other
> > external services) to give an overall measure of the performance of
> > individual parts of the whole thing.
> >
> > Ultimately I do not intend to collect this quantity of data from
> > production systems, but on development and test systems I need to be able
> > to spot quickly when some part of what FreeSwitch is doing, or anything
> > else we are collecting these timestamps from, changes (for better or for
> > worse) in how long the processing takes.
> >
> > Does that answer your question sufficiently to be able to guide to me
> > where I can find the current timestamp inside the dialplan?
> >
> > I didn't realise that this could be a complicated question, but perhaps
> > the fact that I didn't find the answer easily indicates that it is?
> >
> > > On Wed, Nov 2, 2022 at 12:12 PM Antony Stone wrote:
> > > > On Wednesday 02 November 2022 at 17:18:26, Brian West wrote:
> > > > > Ok let's step back, what do you mean by this?
> > > >
> > > > I mean that I wish either to assign the current timestamp to a
> > > > variable in the format 2022-11-02 12:34:56.789789, or to find a
> > > > system variable which will provide this when I reference something
> > > > like ${now}.
> > > >
> > > > I hope that's clear?
> > > >
> > > > As a workaround until I find out how to do this the correct way, the
> > > > following command does what I want, however I suspect it's not very
> > > > efficient:
> > > >
> > > > <action
> > > >
> > > >         application="set"
> > > >         data="now=${regex(${system date '+%F %T.%N'}|(.+)|%1)}"
> > > >
> > > > />
> > > >
> > > > I got the somewhat complicated syntax of that command from
> >
> > https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools:+system
> >
> > > > Antony.

--
.evah I serutangis sseltniop tsom eht fo eno eb tsum sihT

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

_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com


--

Brian West | Co-founder and Developer

Need Commercial support? email sales@freeswitch.com

FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045

Email: brian@freeswitch.com

Mobile: 918-424-9378

Website: https://www.FreeSWITCH.com

https://www.facebook.com/signalwireinc?src=email https://twitter.com/freeswitch