[cisco-voip] CDR Record for transferred call question

[Wes Sisk]

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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090224/b559f6ac/attachment.html>