[cisco-voip] CDR Record for transferred call question

[Lelio Fulgenzi]

Eric, I think the whole list would benefit from the outcome of this.....could you post your findings? 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
"Bad grammar makes me [sic]" - Tshirt 


----- Original Message ----- 
From: "Erick Bergquist" <erickbee at gmail.com> 
To: "Wes Sisk" <wsisk at cisco.com> 
Cc: "cisco-voip mailinglist" <cisco-voip at puck.nether.net> 
Sent: Tuesday, February 24, 2009 10:03:14 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [cisco-voip] CDR Record for transferred call question 

Thanks Wes. 

On Tue, Feb 24, 2009 at 6:32 PM, Wes Sisk <wsisk at cisco.com> wrote: 
> A fine question for cm-cdr-sdp at cisco.com. 
> 
> Regards, 
> Wes 
> 
> On Tuesday, February 24, 2009 7:14:14 PM, Erick Bergquist 
> <erickbee at gmail.com> wrote: 
> 
> Well, back to the original topic, upon further investigation the CDR 
> info matches up for transfers on calls between phones (not voicemail 
> legs) but when the call leg is transferred to voicemail is when the 
> identifiers don't match as expected per the docs. 
> 
> Just was wondering if anyone had ran into this behavior with the raw 
> data, not interested in the who's who in the reports. 
> 
> Thanks 
> 
> On Tue, Feb 24, 2009 at 10:39 AM, Mark Holloway <mh at markholloway.com> wrote: 
> 
> 
> Under normal circumstances, 1234 should be charged as the referring party. 
> 
> 
> 
> From: cisco-voip-bounces at puck.nether.net 
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Lelio Fulgenzi 
> Sent: Tuesday, February 24, 2009 9:18 AM 
> To: Erick B. 
> Cc: cisco-voip mailinglist 
> Subject: Re: [cisco-voip] CDR Record for transferred call question 
> 
> 
> 
> transferred calls CDRs are a pain. and a possible toll fraud vehicle if not 
> monitored/audited. 
> 
> take for example, extension 1234 calls an LD number then transfers to 
> extension 4567. 
> 
> unless you track the transfer, the call is not logged properly. questions do 
> arise, if you can track the transfer who do you charge? 1234 or 4567? 
> 
> i know this doesn't help, but i would hope that CallManager CDRs would keep 
> the same callLegIdentfiers when necessary. 
> 
> --- 
> Lelio Fulgenzi, B.A. 
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> "Bad grammar makes me [sic]" - Tshirt 
> 
> 
> ----- Original Message ----- 
> From: "Erick B." <erickbee at gmail.com> 
> To: "cisco-voip mailinglist" <cisco-voip at puck.nether.net> 
> Sent: Tuesday, February 24, 2009 10:47:25 AM GMT -05:00 US/Canada Eastern 
> Subject: [cisco-voip] CDR Record for transferred call question 
> 
> Hi, 
> 
> I am working with ISI Infortel, and having issue with reporting on 
> transferred calls. They are saying that in the CDR flat files 
> generated that the following fields should match up across all the 
> call legs involved in a transfer. 
> 
> origLegCallIdentifier and the destLegIdentifier fields should match 
> across the call legs. 
> 
> In the CDR file, there are 3 legs part of the transferred call and the 
> origLegCallIdentifer field matches on the 1st and 3rd leg but is 
> different on the 2nd leg which is the phone that transferred the call 
> to the final phone. This is on Call Manager version 5.1.1 and I've 
> also compared against same sample call flow on version 6.1.2.1000-13 
> and 7.0(2) and the CDR flat file records look the same. I've also 
> tested with transfer softkey for the whole call flow and using hold 
> and new call then transfer and the CDRs look the same so the method 
> used doesn't effect the CDRs it appears. 
> 
> According to Cisco docs, it seems like it is working as it should as 
> the examples in the docs match what I see and descriptions in the 
> Cisco CDR PDF describe how these get generated, etc. But there is a 
> section of the PDF that has the following for both of these fields, 
> "If the leg of a call persists across several sub-calls, and 
> consequently several CDRs (as during a call transfer), this value 
> remains constant." which I don't understand what it means if these 
> fields are different in the CDRs. I've opened a TAC Case and they 
> confirmed everything is working as it should but the vendor is going 
> back to this statement and states the fields should match up across 
> all call legs so they can match up all the call legs for the report 
> involved in the transferred call. 
> 
> The PDF is here, 
> 
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/6_0_1/car/carcdrdef.pdf 
> 
> Just wondering if anyone else has ran into this before or not. 
> 
> Thanks. 
> _______________________________________________ 
> cisco-voip mailing list 
> cisco-voip at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-voip 
> 
> 
> _______________________________________________ 
> cisco-voip mailing list 
> cisco-voip at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-voip 
> 
> 
_______________________________________________ 
cisco-voip mailing list 
cisco-voip at puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-voip 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090224/64dda706/attachment.html>