Hi all, I have a problem with CDRs when doing call transfers. I am using * 1.8.2.3 with cdr_odbc. As most of you may already know, CDRs and call transfers dont go along very well in *. I mean the developers team have done their best to bring it to an acceptable level. But still it cannot meet the needs of all of the users, some like me are too.... Whats happening here is when i transfer a call upto two or three or more times, not all the cdrs are generated all the time, hence if i lose one of them, i lose money. It happens with both attended and blind transfers. Bad news is my system cannot afford to not have call transfers facility. I also created call transfers in dialplan with the combination of call parkling and blind transfer (blind transfer seems to generate correct cdrs most of the times). Anyways it did not work (call transfer worked but CDRs didnt) Now I am working on another plan. I am using the builtin transfer facility of * but I have modified some of the code of these features so that whenever these features execute, they send a manager event stating a transfer occured with the following information: Event: Dial Privilege: call,all Timestamp: 1299577784.825096 SubEvent: *Blind Transfer* *Transferer: SIP/pepsi-00000002 Transferee: SIP/coke-00000003* UniqueID1: 1299577741.2 UniqueID2: 1299577741.3 LinkedID1: 1299577741.2 LinkedID2: 1299577741.3 Transfer To: 17142545586 Transfer Context: siga-external I plan to watch for this event thru AMI, and record who was invloved in transfers, hopefully correct the bill sec and duration with the help of some other events and their timestamps (UnLink Event, Hangup Event etc) in the cdr after it has been inserted in DB, or if its not there in DB, i will insert my own :) This is the best supposed solution i have come up with. But, I am here to ask you people for your ideas and thoughts on my solution. I am still in search for a better solution. So please share your ideas. Thanks PS. I am sending this message to both users and developers list coz i am not sure where this message truly belongs. -- Best Ragards Rizwan Qureshi VoIP/Asterisk Engineer Axvoice Inc. V: +92 (0) 3333 6767 26 E: rizwanhasham at gmail.com W: www.axvoice.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110308/a231a271/attachment.htm>
Klaus Darilion
2011-Mar-08 10:27 UTC
[asterisk-users] [asterisk-dev] CDR and call transfers :)
Am 08.03.2011 11:05, schrieb Rizwan Hisham:> Hi all, > I have a problem with CDRs when doing call transfers. I am using * 1.8.2.3 > with cdr_odbc.> This is the best supposed solution i have come up with. But, I am here to > ask you people for your ideas and thoughts on my solution. I am still in > search for a better solution. So please share your ideas.Sounds like you are trying to re-implement CEL: https://wiki.asterisk.org/wiki/display/AST/Call+Event+Log+%28CEL%29+Driver+Modules https://wiki.asterisk.org/wiki/display/AST/CEL+Design+Goals klaus PS: I prefer a dedicated GW-Asterisk which does accounting: /---trunk1 / /-----trunk2 SIP --------> PBX <--------> GW Asterisk <-------ISDN phones Asterisk \------ISDN2 \---....... So, all the transfers happens in the PBX Asterisk. All calls which will be billed are routed via the GW-Asterisk into the PSTN via several uplinks or back to the same or another PBX Asterisk. So, I generate CDRs only at the GW-Asterisk, and as there never happens any transfers on the GW-Asterisk, those CDRs are always 100% correct (as long as you signal proper CLIs from the PBX Asterisk to the GW-Asterisk).
Rizwan Hisham
2011-Mar-08 10:36 UTC
[asterisk-users] [asterisk-dev] CDR and call transfers :)
Thanks Klaus, Actually I got my idea from CEL. But I am more familiar with AMI, plus CEL generates too many events for a single call. I dont want that, I already have a library of routines which read manager events, i just have to plug in my new idea. But still I will think about CEL once again. I never gave it a second thought. I like your idea of a gateway asterisk as well. Will try it. Thanks On Tue, Mar 8, 2011 at 3:27 PM, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:> > > Am 08.03.2011 11:05, schrieb Rizwan Hisham: > > Hi all, > > I have a problem with CDRs when doing call transfers. I am using * > 1.8.2.3 > > with cdr_odbc. > > > This is the best supposed solution i have come up with. But, I am here to > > ask you people for your ideas and thoughts on my solution. I am still in > > search for a better solution. So please share your ideas. > > Sounds like you are trying to re-implement CEL: > > > https://wiki.asterisk.org/wiki/display/AST/Call+Event+Log+%28CEL%29+Driver+Modules > https://wiki.asterisk.org/wiki/display/AST/CEL+Design+Goals > > klaus > > PS: I prefer a dedicated GW-Asterisk which does accounting: > > /---trunk1 > / > /-----trunk2 > SIP --------> PBX <--------> GW Asterisk <-------ISDN > phones Asterisk \------ISDN2 > \---....... > > > So, all the transfers happens in the PBX Asterisk. All calls which will > be billed are routed via the GW-Asterisk into the PSTN via several > uplinks or back to the same or another PBX Asterisk. So, I generate CDRs > only at the GW-Asterisk, and as there never happens any transfers on the > GW-Asterisk, those CDRs are always 100% correct (as long as you signal > proper CLIs from the PBX Asterisk to the GW-Asterisk). > >-- Best Ragards Rizwan Qureshi VoIP/Asterisk Engineer Axvoice Inc. V: +92 (0) 3333 6767 26 E: rizwanhasham at gmail.com W: www.axvoice.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110308/7f7ca935/attachment.htm>
Rizwan Hisham
2011-Mar-08 11:31 UTC
[asterisk-users] [asterisk-dev] CDR and call transfers :)
Anymore suggestions please. On Tue, Mar 8, 2011 at 3:36 PM, Rizwan Hisham <rizwanhasham at gmail.com>wrote:> Thanks Klaus, > Actually I got my idea from CEL. But I am more familiar with AMI, plus CEL > generates too many events for a single call. I dont want that, I already > have a library of routines which read manager events, i just have to plug in > my new idea. But still I will think about CEL once again. I never gave it a > second thought. > > I like your idea of a gateway asterisk as well. Will try it. > > Thanks > > > On Tue, Mar 8, 2011 at 3:27 PM, Klaus Darilion < > klaus.mailinglists at pernau.at> wrote: > >> >> >> Am 08.03.2011 11:05, schrieb Rizwan Hisham: >> > Hi all, >> > I have a problem with CDRs when doing call transfers. I am using * >> 1.8.2.3 >> > with cdr_odbc. >> >> > This is the best supposed solution i have come up with. But, I am here >> to >> > ask you people for your ideas and thoughts on my solution. I am still in >> > search for a better solution. So please share your ideas. >> >> Sounds like you are trying to re-implement CEL: >> >> >> https://wiki.asterisk.org/wiki/display/AST/Call+Event+Log+%28CEL%29+Driver+Modules >> https://wiki.asterisk.org/wiki/display/AST/CEL+Design+Goals >> >> klaus >> >> PS: I prefer a dedicated GW-Asterisk which does accounting: >> >> /---trunk1 >> / >> /-----trunk2 >> SIP --------> PBX <--------> GW Asterisk <-------ISDN >> phones Asterisk \------ISDN2 >> \---....... >> >> >> So, all the transfers happens in the PBX Asterisk. All calls which will >> be billed are routed via the GW-Asterisk into the PSTN via several >> uplinks or back to the same or another PBX Asterisk. So, I generate CDRs >> only at the GW-Asterisk, and as there never happens any transfers on the >> GW-Asterisk, those CDRs are always 100% correct (as long as you signal >> proper CLIs from the PBX Asterisk to the GW-Asterisk). >> >> > > > -- > Best Ragards > Rizwan Qureshi > VoIP/Asterisk Engineer > Axvoice Inc. > V: +92 (0) 3333 6767 26 > E: rizwanhasham at gmail.com > W: www.axvoice.com > >-- Best Ragards Rizwan Qureshi VoIP/Asterisk Engineer Axvoice Inc. V: +92 (0) 3333 6767 26 E: rizwanhasham at gmail.com W: www.axvoice.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110308/dd889dc7/attachment.htm>