similar to: No subject

Hi All, PLEASE READ if you depend on Asterisk CDR's and support transfers. Apologies for the shout but I'm desperate to get others to agree Asterisk has a big problem with the CDR's that are generated for transfers. I can understand why not too many people are interested as transfers are complicated and messy. However for those of us having to support transfers and depending on

I'm using all sip, no zap, or iax, so I don't know if the same problem exists when using zap, or iax. When device 1 calls device 2, and device 2 blind transfers to device 3, the following happens: The cdr record shows that 1 called 3, and ignores completly the fact that 1 called 2 and 2 called 3. In normal billing I think that the duration of the entire call should be billed to device 1

correct for a transfer. In the traditional Telco World the src (or A Number) field tends to be both the callerid of the customer and an identifier that ties the CDR to the customer for billing purposes. With Asterisk and a lot of other modern day softswitches there's usually a field called accountcode or similar which can be used to tie a CDR to a customer. The src field is then only

Hi All, I have been running a environment with asterisk 1.4.20.1 for some time now with no issue but have recently added some extra functionality (enabled call recording via MixMonitor) and ran into some deadlock issues which seem to be well documented with earlier 1.4.x releases so have decided to take the plunge and upgrade. I decided to start testing with 1.6.2 but have run into a couple

Hello! It's me again. I began a fairly large modification to my CDR proposal some weeks ago, and finally yesterday and this morning got enough accomplished to allow a commit and some peer review. Check the docs out via " svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs " This is a directory; in it you will find: CDRfix2.rfc.doc CDRfix2.rfc.docx CDRfix2.rfc.pdf The docx

I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation

Hi Steve, > .. I'll try to sort all this out, and then I'll attack this > problem. Hopefully, I get it all into svn before the next release of > 1.4...! Just wondering if any new CDR functionality made it into the 1.4.16.2 release? I have looked through the ChangeLog for the 1.4.15 and 1.4.16.2 releases but didn't spot anything to do with changes in CDR handling. I for one

I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation

Hi asterisk-users, We have recently moved to the 13.x branch of Asterisk from 11.x, and we're trying to correlate CDR records from multiple-legs for billing purposes. As part of this change we have added 'linkedid' to our CDR table schema in an attempt to join the multiple records into one billable record. The call path can be simplified as (transport types in brackets): SIP

Hello, I'm working on an Asterisk configuration for a call center, and they bill based on the time spent talking to an agent, but not for any time spent waiting in a queue. The CDR information contains the entire duration of the call as billable seconds, including time spent waiting in the queue. I would like the billable seconds to only include the time spent actually talking to an agent.

On Sat, 2009-02-07 at 15:51 -0500, Alexander Lopez wrote: > > > -----Original Message----- > > From: Steve Murphy [mailto:murf at digium.com] > > Sent: Saturday, February 07, 2009 1:59 PM > > To: Alexander Lopez > > Subject: RE: [asterisk-dev] 1.4 and CDRs -- The Breaking Point > > > > On Fri, 2009-02-06 at 12:28 -0500, Alexander Lopez wrote: >

Hello! Most are probably bored seeing another letter about this, but I've put in a fair amount work on a spec for rewriting the CDR system in Asterisk, and I have some questions: First, please look at what I've written so far: svn co http://svn.digium.com/svn/asterisk/team/murf/RFCs and look at the file "CDRfix2.rfc.txt" in the RFCs dir. The spec SIGNIFICANTLY alters the way

Hi, Would just like to ask about cdr, i have an asterisk and i would like to bill only outbound calls not extension to extension, when i'm looking at the CDR, i can't figure out which fields i need to filter all outbound calls only. e.g if i dial 00. or 9XXXXXX (for local pstn calls) those are billable, 100 101 or 102 (all local extensions) not billable. *97 for voicemail not billable,

hello, First of all i am using Asterisk 1.6.2.9-2 The following problem seem like a bug to me but im not sure. Any help or comment will be great.. We are trying to implement our own billing software with AGI - Php Scripts. When a hangup received, i am calling a script to calculate the bill and we are trying to write the results to cdr database. We added two fileds to cdr table as rate

Hi all, Just thought I'd update this thread in case anyone else is Googling trying to find out how to do this... I found the solution to my problem to be to use the IAXVAR() function to pass the accountcode between the Asterisk boxen and update the CHANNEL(accountcode) with that variable. Thanks to Richard @ Digium for the reply that clarified my misunderstanding. Calum On Wed, 2018-10-03

Hi all, i am wondering if i can make two leg cdr in mysql cdr table. 1st Leg : Registrar the ATA which registered to the asterisk and it normally logging in cdr table. 2nd Leg : The CDR of carrier for the example if i send call like exten => _x.,1,Dial(SIP/${EXTEN}@AT&TIP) I this cause i can get the accrue duration of call because currently we are facing some call missing not coming

Greyman-- I'm taking this discussion to the list. Folks, what we are talking about here, is me trying to get a grasp around Greyman's (Aaron's) request for a bare-bones CDR generation that describes just total connect time for channels, stripping out all the details. Who cares about xfer, park, hold, etc.? So in the following is our discussion about what *should* be there, and in

Hi all, I need 2 CDR Records of below 2 numbers for outgoing calls, detail is given as below: *96XXXXXXXX88XXXXXXXX* *=> Call file : outbound call generate through below file* Test.call ====== Channel: local/s at outgoing/n WaitTime: 45 Context: outgoing_ivrs Extension: s Priority: 1 Set: contact_no=96XXXXXXXX extensions.conf ============ [outgoing] exten => s,1,NoOP(----- First LEG

I'm currently working on a perl script convert csv logs to a http log equiv: LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" Right now I have output something similar to this: 111 - - [02/Aug/2003:16:39:15 -0500] "GET /300 HTTP/1.0" 200 6144 "sipext" "ANSWERED" INCOMING - -

Hi I'm using asterisk 1.8.23.1 but I've seen this same issue in previous versions of 1.8. I have created some work arounds but the behaviour is incorrect. This is the scenario: Call comes in and goes to appropriate dialplan In the dialplan the call is forwarded to another number using a Local channel (and using /n ) e.g. Dial(Local/<my-number>@outbound-context/n,60) The number is