Hi list, I've been reading the archives and I know that transfers are unimplemented in the CDR ( http://lists.digium.com/pipermail/asterisk-users/2007-June/189902.html) In my case I'm running Asterisk 1.4.17 as an Office PBX. In this setup just a small group of users are able to make long distance call directly from his/her extension, so the ones who can't needs to ask the operator/receptionist to call these numbers and then transfer (almost always atxfer) the call back to them. In this case, I want to account the whole call duration to the user that have requested it, not the operator, but I cannot manage to find a way to map the CDR generated by the operator with the CDR generated by the transfer. This is an example of the generated CDRs by atxfer: John Doe make a long distance call, talk a few seconds and then make an attended transfer to extension 128. "John Doe <111>","111","128","SIP/128-0071d340","2008-04-15 14:31:31","2008-04-15 14:31:32","2008-04-15 14:31:41","10","9","ANSWERED","1208286068.2256" "John Doe <111>","111","902125555555","Zap/4-1","2008-04-15 14:31:08","2008-04-15 14:31:14","2008-04-15 14:31:41","33","27","ANSWERED","1208286068.2255" "111","111","s","","2008-04-15 14:31:08","2008-04-15 14:31:14","2008-04-15 14:31:41","33","27","ANSWERED","1208286068.2256" "111","111","s","Zap/4-1","2008-04-15 14:31:31","2008-04-15 14:31:32","2008-04-15 14:31:47","16","15","ANSWERED","1208286091.2260" This is an example of the generated CDRs by blind xfer: John Doe make a long distance call, talk a few seconds and then make a blind transfer to extension 128. "John Doe <111>","111","904124172996","Zap/6-1","2008-04-11 13:10:48","2008-04-11 13:10:55","2008-04-11 13:11:13","25","18","ANSWERED","1207935648.5256" "111","111","128","SIP/128-006fec80","2008-04-11 13:11:13","2008-04-11 13:11:22","2008-04-11 13:11:32","19","10","ANSWERED","1207935673.5258" In this case I think you can guess the "uniqueid" of the transferred call by adding the call duration (25 in this example) made by John Doe to the "uniqueid" of the same call, but that's not the case in the atxfer scenario. I think this is a very common scenario so, how are you doing to handle this situation??? -- Raul Gomez Linux Counter #156439 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080416/ef779769/attachment-0001.htm
Hi Raul, CDR's for transfers are beyond the ability of Asterisk. http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html http://bugs.digium.com/view.php?id=11093 It's not something the powers that be want to think about a design for and the solution that's been suggested is to date it to use a different type of server software, such as a SIP Proxy, to generate the CDR's (something easy to suggest and complicated to do). You're not the only one affected by this and there is no fix. Regards, Greyman.
Mojo with Horan & Company, LLC
2008-Apr-17 21:14 UTC
[asterisk-users] CDR and transfers! :(
Ra?l G?mez C. wrote:> Hi list, ><snip>> I think this is a very common scenario so, how are you doing to handle this > situation??? >What if you were to set an account code to the extension that is requesting the long-distance call? So person at extension 111 requests a long distance call to 808-555-1212. Lets say the receptionist dials, then, *111*8085551212... The PBX does something like: exten => _*XXX*NXXNXXXXXX,1,SetAccountCode(${EXTEN:1:3}) exten => _*XXX*NXXNXXXXXX,n,Dial(Zap/G1/${EXTEN:5}) then, the receptionist transfers the call to extension 111, which again sets the account code to111. Seems the account code would help the CDRs to make more sense? Maybe I overlooked something :) When anybody in the office dials 111, however, the accountcode will still be set in my scenario. This might lead to the user at 111 being charged for inter-office calls! So: exten => _XXX,1,Dial(SIP/${EXTEN}) exten => _#XXX,1,SetAccountCode(${EXTEN:1}) exten => _#XXX,2,Goto(${EXTEN:1},1) And the receptionist transfers long distance calls to #111 Moj
On Thu, Apr 17, 2008 at 5:14 PM, Mojo with Horan & Company, LLC <mojo at horanappraisals.com> wrote:> Ra?l G?mez C. wrote: > > Hi list, > > > <snip> > > > > I think this is a very common scenario so, how are you doing to handle this > > situation??? > > > What if you were to set an account code to the extension that is > requesting the long-distance call? > > So person at extension 111 requests a long distance call to > 808-555-1212. Lets say the receptionist dials, then, *111*8085551212... > > The PBX does something like: > > exten => _*XXX*NXXNXXXXXX,1,SetAccountCode(${EXTEN:1:3}) > exten => _*XXX*NXXNXXXXXX,n,Dial(Zap/G1/${EXTEN:5}) > > then, the receptionist transfers the call to extension 111, which again > sets the account code to111. > > Seems the account code would help the CDRs to make more sense? Maybe I > overlooked something :) > > When anybody in the office dials 111, however, the accountcode will > still be set in my scenario. This might lead to the user at 111 being > charged for inter-office calls! So: > > exten => _XXX,1,Dial(SIP/${EXTEN}) > > exten => _#XXX,1,SetAccountCode(${EXTEN:1}) > exten => _#XXX,2,Goto(${EXTEN:1},1) > > And the receptionist transfers long distance calls to #111 > > Moj >Without putting too much thought into it, it would seem that creatively using queues or maybe even a meetme room, you could get accurate billing. Maybe if you use some AGI/AMI mojo along with queue_log you could come up with something solid? Not sure how using app_bridge shows up in CDR either... Just a thought. Thanks, Steve Totaro
On Fri, Apr 18, 2008 at 8:07 PM, Steve Totaro < stotaro at totarotechnologies.com> wrote:> On Thu, Apr 17, 2008 at 5:14 PM, Mojo with Horan & Company, LLC > <mojo at horanappraisals.com> wrote: > > Ra?l G?mez C. wrote: > > > Hi list, > > > > > <snip> > > > > > > > I think this is a very common scenario so, how are you doing to > handle this > > > situation??? > > > > > What if you were to set an account code to the extension that is > > requesting the long-distance call? > > > > So person at extension 111 requests a long distance call to > > 808-555-1212. Lets say the receptionist dials, then, > *111*8085551212... > > > > The PBX does something like: > > > > exten => _*XXX*NXXNXXXXXX,1,SetAccountCode(${EXTEN:1:3}) > > exten => _*XXX*NXXNXXXXXX,n,Dial(Zap/G1/${EXTEN:5}) > > > > then, the receptionist transfers the call to extension 111, which again > > sets the account code to111. > > > > Seems the account code would help the CDRs to make more sense? Maybe I > > overlooked something :) > > > > When anybody in the office dials 111, however, the accountcode will > > still be set in my scenario. This might lead to the user at 111 being > > charged for inter-office calls! So: > > > > exten => _XXX,1,Dial(SIP/${EXTEN}) > > > > exten => _#XXX,1,SetAccountCode(${EXTEN:1}) > > exten => _#XXX,2,Goto(${EXTEN:1},1) > > > > And the receptionist transfers long distance calls to #111 > > > > Moj > > > > > Without putting too much thought into it, it would seem that > creatively using queues or maybe even a meetme room, you could get > accurate billing. > > Maybe if you use some AGI/AMI mojo along with queue_log you could come > up with something solid? Not sure how using app_bridge shows up in > CDR either... > > Just a thought. > > Thanks, > Steve Totaro > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Nacho Linux Counter #156439 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080419/79206c6b/attachment.htm