<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Under normal circumstances, 1234 should be charged as the
referring party. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] <b>On Behalf Of </b>Lelio Fulgenzi<br>
<b>Sent:</b> Tuesday, February 24, 2009 9:18 AM<br>
<b>To:</b> Erick B.<br>
<b>Cc:</b> cisco-voip mailinglist<br>
<b>Subject:</b> Re: [cisco-voip] CDR Record for transferred call question<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:black'>transferred calls CDRs are a pain. and a possible toll fraud
vehicle if not monitored/audited.<br>
<br>
take for example, extension 1234 calls an LD number then transfers to extension
4567.<br>
<br>
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?<br>
<br>
i know this doesn't help, but i would hope that CallManager CDRs would keep the
same callLegIdentfiers when necessary.<br>
<br>
---<br>
Lelio Fulgenzi, B.A.<br>
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
"Bad grammar makes me [sic]" - Tshirt<br>
<br>
<br>
----- Original Message -----<br>
From: "Erick B." <erickbee@gmail.com><br>
To: "cisco-voip mailinglist" <cisco-voip@puck.nether.net><br>
Sent: Tuesday, February 24, 2009 10:47:25 AM GMT -05:00 US/Canada Eastern<br>
Subject: [cisco-voip] CDR Record for transferred call question<br>
<br>
Hi,<br>
<br>
I am working with ISI Infortel, and having issue with reporting on<br>
transferred calls. They are saying that in the CDR flat files<br>
generated that the following fields should match up across all the<br>
call legs involved in a transfer.<br>
<br>
origLegCallIdentifier and the destLegIdentifier fields should match<br>
across the call legs.<br>
<br>
In the CDR file, there are 3 legs part of the transferred call and the<br>
origLegCallIdentifer field matches on the 1st and 3rd leg but is<br>
different on the 2nd leg which is the phone that transferred the call<br>
to the final phone. This is on Call Manager version 5.1.1 and I've<br>
also compared against same sample call flow on version 6.1.2.1000-13<br>
and 7.0(2) and the CDR flat file records look the same. I've also<br>
tested with transfer softkey for the whole call flow and using hold<br>
and new call then transfer and the CDRs look the same so the method<br>
used doesn't effect the CDRs it appears.<br>
<br>
According to Cisco docs, it seems like it is working as it should as<br>
the examples in the docs match what I see and descriptions in the<br>
Cisco CDR PDF describe how these get generated, etc. But there is a<br>
section of the PDF that has the following for both of these fields,<br>
"If the leg of a call persists across several sub-calls, and<br>
consequently several CDRs (as during a call transfer), this value<br>
remains constant." which I don't understand what it means if
these<br>
fields are different in the CDRs. I've opened a TAC Case and they<br>
confirmed everything is working as it should but the vendor is going<br>
back to this statement and states the fields should match up across<br>
all call legs so they can match up all the call legs for the report<br>
involved in the transferred call.<br>
<br>
The PDF is here,<br>
<br>
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/6_0_1/car/carcdrdef.pdf<br>
<br>
Just wondering if anyone else has ran into this before or not.<br>
<br>
Thanks.<br>
_______________________________________________<br>
cisco-voip mailing list<br>
cisco-voip@puck.nether.net<br>
https://puck.nether.net/mailman/listinfo/cisco-voip<o:p></o:p></span></p>
</div>
</div>
</body>
</html>