[Freeswitch-users] Billsec in dialplan

Fri Apr 15 21:42:32 MSD 2016

Thank you all for your replies.

1- Definitely going to change from billsec to billusec
2- Going to setup tcpdump to capture traffic to see what it has to say when
it fails

Currently, our FS servers are doing a POST request to 2 ActiveMQ's setup
with a load balancer in front of them.

Will update when I have more info.

Thanks!
Joel.

On Fri, Apr 15, 2016 at 8:43 AM, François <fdelawarde at wirelessmundi.com>
wrote:

> Watch out with billsec is the integer part of the "real" billing seconds.
>
> So if a call has duration of 10.9 seconds, billsec will be 10 seconds,
> but your provider will bill you 11 seconds.
>
> One should use billusec!
>
> F
>
> On 2016-04-15 16:19, Michael Giagnocavo wrote:
> > One easy way, PCAP your HTTP. You can setup a rotating set of files,
> then when you have an issue, break the capture and hunt for the failed
> POST. That should give you "ground truth" as to what's going on and may
> point you to the issue.
> >
> > -Michael
> >
> > From: freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Sergey Safarov
> > Sent: Wednesday, 13 April, 2016 22:11
> > To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> > Subject: Re: [Freeswitch-users] Billsec in dialplan
> >
> > Please also check mod_format
> >
> > On Thu, Apr 14, 2016, 02:16 Ken Rice <krice at freeswitch.org> wrote:
> > The correct answer here is you must check more often i would say at a
> minimum every 15 seconds. Search the list for me discussing cdrs in volume
> in the past or contact me off list if you need pro help
> >
> > Sent from my iPhone
> >
> > On Apr 13, 2016, at 5:52 PM, Joel Serrano <joel at gogii.net> wrote:
> > Hi Michael,
> >
> > The problem is that occasionally we see the following in FS log:
> >
> > 2016-04-13 02:33:11.143230 [ERR] mod_xml_cdr.c:385 Got error [0] posting
> to web server [http://cdrs.example.com/queue]
> > 2016-04-13 02:33:11.143230 [ERR] mod_xml_cdr.c:392 Retry will be with
> url [http://cdrs.example.com/queue]
> >
> > When that happens, the CDR gets written to disc (so the CDR is not
> processed on time, thus our user is not billed for that call yet).
> >
> > We have a task that checks every 5 minutes for failed CDRs and we
> resubmit them to the processing queue, but I need to find out why FS is
> failing.
> >
> > I have checked the access logs on the receiving side, but all requests
> return a 200 OK.
> >
> > Now I have enabled logs in the loadbalancer between FS and the queues to
> see if I get more vision from there...
> >
> >
> > A workaround was to make API requests directly from the dialplan with
> the billsec info, but as all suggest going with CDRs, I am now focussed on
> finding the root cause for that error.
> >
> > Any help/suggestion is more than welcome.
> >
> >
> > Thank you.
> >
> > Best regards,
> > Joel.
> >
> >
> >
> >
> > On Tue, Apr 12, 2016 at 1:42 PM, Michael Jerris <mike at jerris.com> wrote:
> > I'm probably going to push towards cdr, but what are you trying to
> actually do with that info?
> >
> > On Apr 12, 2016, at 2:39 PM, Joel Serrano <joel at gogii.net> wrote:
> >
> > Hi Michael,
> >
> > I want to call an API basically with the following info:
> >
> > sip_from_uri
> > destination_number
> > billsec
> >
> > I found away using "api_hangup_hook=lua script.lua" +
> "session_in_hangup_hook=true", but, I don't like it... I would prefer using
> curl from within the dialplan.
> >
> > Can you give me your suggestion? I have also asked in IRC and using the
> CDRs looks like the best way to go, so we will probably follow that, but I
> would still like to now if it is possible and how.
> >
> > Thanks!
> > Joel.
> >
> >
> >
> > On Tue, Apr 12, 2016 at 12:22 PM, Michael Jerris <mike at jerris.com>
> wrote:
> > Billsec is set in reporting state, after you are out of dial plan.
>  What are you trying to do based on that, I can suggest a few approaches
> >
> >
> > On Monday, April 11, 2016, Joel Serrano <joel at gogii.net> wrote:
> > Hi,
> >
> > Is it possible to access ${billsec} in the dialplan after the bridge
> application (having hangup_after_bridge=false)??
> >
> > I want to log the billsec but currently it is always empty.
> >
> > I have a workaround in a test server using api_hangup_hook to call a lua
> script with session_in_hangup_hook=true, and inside the lua script I can
> access the billsec variable and thus write it to the logs.
> >
> > Is there no way to do this within the XML dialplan?
> >
> > Thanks!
> >
> > Best regards,
> > Joel.
> >
> >
> >
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.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
> > http://www.freeswitch.org
> >
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.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
> > http://www.freeswitch.org
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.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
> > http://www.freeswitch.org
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.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
> > http://www.freeswitch.org
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.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
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160415/2b872b6b/attachment.html 