[Freeswitch-users] Billsec in dialplan

[Michael Jerris]

Most likely those failures are due to not enough workers on your web server, but yes, the pcap will help find it.

> On Apr 15, 2016, at 10:19 AM, Michael Giagnocavo <mgg at giagnocavo.net> 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.
> 
>