[Freeswitch-users] Current timestamp variable in dialplan?

Brian West brian at freeswitch.com
Fri Nov 4 17:25:21 UTC 2022


Inline below.

On Fri, Nov 4, 2022 at 11:06 AM Antony Stone <
Antony.Stone at 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 at 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 at 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 at freeswitch.com

FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045
<https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g>

Email: brian at freeswitch.com

Mobile: 918-424-9378

Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/>

[image: https://www.facebook.com/signalwireinc?src=email]
<https://www.facebook.com/freeswitch> [image:
https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20221104/abe4af75/attachment.html>


More information about the FreeSWITCH-users mailing list