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'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

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

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

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.

straight away I can think of a scenario that would cause a problem. If I supply toll free numbers that need to be billed for incoming calls and that can be forwarded out to billable destinations then I want a CDR for both ends of the bridge. In your first blind transfer example what if the initial incoming call to A is billable? I can't see any easy way to get the duration of that call leg.

Hi list! Running Asterisk 20.0.0 on CentOS 7, logging CDRs using cdr_adaptive_odbc to mariadb-server-5.5.68 (via mariadb-connector-odbc-3.1.7-ga-rhel7) Using chan_sip. I'm facing the problem when there is a sudden spike of calls, some of the calls that are being made during those spikes hang forever basically. This looks like this: [root at voip]# asterisk -rx 'core show channels

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

Greetings list, Whilst running through a routine check of some CDRs, I've noticed that the originating channel's accountcode isn't preserved on creating a local channel. For example, if we start with: exten => 123,1,Set(CDR(accountcode)=foo) exten => 123,n,Queue(bar,nrtw,,,) And the queue 'bar' is defined as follows: [bar] member => Local/456 at outbound member

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

Hello, I'm working on some dialplan rules to pull multiple users into a conference call. I have some fairly straightforward rules which start up a new MeetMe conference, allow escape with the * key to invite more users, then use a features.conf sequence to bring the new user into the conference with ChannelRedirect. The problem I'm running into is the time in the MeetMe conference

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

When I compare my total minutes on the bill from VoIP Innovations, to the number from our CDRs, I'm finding a smalish (3-4%) discrepancy in the count of minutes. I'm wondering why it's there. Are there different methods of counting the billable start or end point of a phone call? If it matters, I'm counting more termination minutes than they are and they're counting more

Hello: I'm building asterisk for a bcm96348GW board, wich has a usb capable device to timming ztdummy, kernel is 2.6.8.1. This board will be serve as a prototype for an IAX2 trunk "bridge" in the form SIP/IAX2<--->IAX2trunk<--Inet-->IAX2trunk<-->LucentCS/SIP<-->SS7/POTS The parameters are known.. in the sense that only g729.a will be used, the two

My cdrs are missing accountcodes for incoming calls from other asterisk servers.. I've seen a few people mentioning this on the list and the solution seems to be setting up a dialplan for incoming calls from a particular sip peer.. in my opinion this does not scale well at all and I am looking for a solution to correct this problem. example sip peer: [asterisk_gw] type=friend

Hi to all, following the suggestion of Matteo Brancaleoni to solve my problem of anonymous call in CDRS i implemented the accountcode in any peer that i have in the sip.conf so i can use the SetCallerID to accountcode to identify the caller. When i make the sip show users the accountcode is correctly displayed but when i try to access the variable ${ACCOUNTCODE} from the extensions.conf to

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

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

How is the billsec field calculated in CDRs? I have a situation where billsec is being reported as 0 despite the call being answered and a conversation occurring. An example record follows: '2007-11-06 21:36:50', '6495566778', '6495566778', '0116495566778', '1100012_1', 'Local/0116495566778 at 1100012_1-887b,2',

> > That is possible, how could I check that? > > I can see that IRQ 17 is shared between eth0 and my fritz!card > but I > > don't know if it changes anything: > > Can you try it (or eth0) in a different slot (or change IRQ's in the > BIOS if possible) to see if it makes any difference? That's the > only way > to know for sure, anything else is