<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Not knowing your call logging but normally in the call logger you have to set up departments, sub departments etc. Within these you have to add the extensions however again normally any extensions which the call logger picks up via the CDR DB may be flagged as unallocated. Can you not just delete/ exclude the voice mail ports from the " departments" so they do not show up and move them to a new department called vm <BR><BR>> From: cisco-voip-request@puck.nether.net<BR>> Subject: cisco-voip Digest, Vol 58, Issue 155<BR>> To: cisco-voip@puck.nether.net<BR>> Date: Thu, 27 Dec 2007 14:20:55 -0500<BR>> <BR>> Send cisco-voip mailing list submissions to<BR>> cisco-voip@puck.nether.net<BR>> <BR>> To subscribe or unsubscribe via the World Wide Web, visit<BR>> https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> or, via email, send a message with subject or body 'help' to<BR>> cisco-voip-request@puck.nether.net<BR>> <BR>> You can reach the person managing the list at<BR>> cisco-voip-owner@puck.nether.net<BR>> <BR>> When replying, please edit your Subject line so it is more specific<BR>> than "Re: Contents of cisco-voip digest..."<BR>> <BR>> <BR>> Today's Topics:<BR>> <BR>> 1. Excluding extensions from CDR reporting (Hames, Joel)<BR>> 2. Re: Excluding extensions from CDR reporting (Wes Sisk)<BR>> 3. Re: Excluding extensions from CDR reporting (Hames, Joel)<BR>> 4. Re: Excluding extensions from CDR reporting (Scott Voll)<BR>> 5. TEHO information tracking (Frazee, Timothy)<BR>> <BR>> <BR>> ----------------------------------------------------------------------<BR>> <BR>> Message: 1<BR>> Date: Thu, 27 Dec 2007 10:23:14 -0800<BR>> From: "Hames, Joel" <jhames@tamdistrict.org><BR>> Subject: [cisco-voip] Excluding extensions from CDR reporting<BR>> To: "Cisco VoIP" <cisco-voip@puck.nether.net><BR>> Message-ID:<BR>> <C20E7A2C14F03F4E92C350A986E0839803DB51B9@tammail.tuhsd.edu><BR>> Content-Type: text/plain; charset="us-ascii"<BR>> <BR>> We have a new CCM5.1 installation, so I may ask a few basic questions as<BR>> we work through our first deployment. At the moment, we have<BR>> implemented RSI's Call Accounting system and have noticed that our<BR>> voicemail extension skews all of our reports significantly. RSI claims<BR>> that this is a Cisco configuration issue and that calls to that<BR>> extension should not be passed to the call accounting system. Our<BR>> installer claims that there is no way to filter out reporting to certain<BR>> extensions.<BR>> <BR>> Does anyone have experience with this? While we can certainly ignore the<BR>> reports of calls inbound and outbound to that extension, I'd like to<BR>> clean this up as much as possible. The graphs of call lengths and call<BR>> costs would be much more meaningful without extraneous information like<BR>> this.<BR>> <BR>> Thank you,<BR>> <BR>> Joel Hames<BR>> Senior Director, Information Technology<BR>> Tamalpais Union High School District<BR>> jhames@tamdistrict.org<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 2<BR>> Date: Thu, 27 Dec 2007 13:32:04 -0500<BR>> From: Wes Sisk <wsisk@cisco.com><BR>> Subject: Re: [cisco-voip] Excluding extensions from CDR reporting<BR>> To: "Hames, Joel" <jhames@tamdistrict.org><BR>> Cc: Cisco VoIP <cisco-voip@puck.nether.net><BR>> Message-ID: <4773EFA4.8020700@cisco.com><BR>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>> <BR>> The verbiage provided is vague but i'm going to assume that CDR's for <BR>> MWI calls are the crux of the issue. Those have been an issue before <BR>> and are certainly numerous enough to skew reporting.<BR>> <BR>> The way CM is implemented Voicemail and the associated MWI transactions <BR>> are calls. You can set CM service parameter "CDR log calls with zero <BR>> duration" to false so that CM does not record CDR for MWI. However, you <BR>> risk losing CDR for other critical calls such as misdials/hangups to 911 <BR>> where the caller hangs up before 911 service answers. Most 911 <BR>> districts consider these prank calls with a quota and begin charging.<BR>> <BR>> Otherwise, no, there is no way to filter these calls from CDR. The <BR>> system dumps out CDR's of all calls. Parsing, filtering, and <BR>> correlating are the job of the "Call Accounting and Reporting" package.<BR>> <BR>> Just as Cisco generates the CDR flat files, RSI has to parse and import <BR>> every CDR flat file. They have equal opportunity to filter these <BR>> requests. As a bonus, RSI can do it without contending for <BR>> CPU/Memory/DiskIO that would otherwise be used for processing your <BR>> actual calls. It's a rather classic example of production vs. reporting.<BR>> <BR>> /Wes<BR>> <BR>> Hames, Joel wrote:<BR>> > We have a new CCM5.1 installation, so I may ask a few basic questions as<BR>> > we work through our first deployment. At the moment, we have<BR>> > implemented RSI's Call Accounting system and have noticed that our<BR>> > voicemail extension skews all of our reports significantly. RSI claims<BR>> > that this is a Cisco configuration issue and that calls to that<BR>> > extension should not be passed to the call accounting system. Our<BR>> > installer claims that there is no way to filter out reporting to certain<BR>> > extensions.<BR>> ><BR>> > Does anyone have experience with this? While we can certainly ignore the<BR>> > reports of calls inbound and outbound to that extension, I'd like to<BR>> > clean this up as much as possible. The graphs of call lengths and call<BR>> > costs would be much more meaningful without extraneous information like<BR>> > this.<BR>> ><BR>> > Thank you,<BR>> ><BR>> > Joel Hames<BR>> > Senior Director, Information Technology<BR>> > Tamalpais Union High School District<BR>> > jhames@tamdistrict.org<BR>> ><BR>> > _______________________________________________<BR>> > cisco-voip mailing list<BR>> > cisco-voip@puck.nether.net<BR>> > https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> > <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 3<BR>> Date: Thu, 27 Dec 2007 10:41:28 -0800<BR>> From: "Hames, Joel" <jhames@tamdistrict.org><BR>> Subject: Re: [cisco-voip] Excluding extensions from CDR reporting<BR>> To: "Wes Sisk" <wsisk@cisco.com><BR>> Cc: Cisco VoIP <cisco-voip@puck.nether.net><BR>> Message-ID:<BR>> <C20E7A2C14F03F4E92C350A986E0839803DB51BB@tammail.tuhsd.edu><BR>> Content-Type: text/plain; charset="us-ascii"<BR>> <BR>> Thanks for the clarification and I apologize for the vagueness of the<BR>> example. We are seeing both calls to our voicemail extension (2000) and<BR>> to the MWI extensions (2090 and 2091). We recently disabled reporting<BR>> for zero duration calls, but your point is well taken regarding 911<BR>> hangups. I'll check with our implementer to see if our Emergency<BR>> Responder installation will help offset this loss of detail. As for the<BR>> voicemail extension itself (2000) that is logging all calls transferred<BR>> to VM, I'll work with RSI again to see what they can do to help filter<BR>> out this information for reporting.<BR>> <BR>> Joel Hames<BR>> Senior Director, Information Technology<BR>> Tamalpais Union High School District<BR>> jhames@tamdistrict.org<BR>> <BR>> -----Original Message-----<BR>> From: Wes Sisk [mailto:wsisk@cisco.com] <BR>> Sent: Thursday, December 27, 2007 10:32 AM<BR>> To: Hames, Joel<BR>> Cc: Cisco VoIP<BR>> Subject: Re: [cisco-voip] Excluding extensions from CDR reporting<BR>> <BR>> The verbiage provided is vague but i'm going to assume that CDR's for <BR>> MWI calls are the crux of the issue. Those have been an issue before <BR>> and are certainly numerous enough to skew reporting.<BR>> <BR>> The way CM is implemented Voicemail and the associated MWI transactions <BR>> are calls. You can set CM service parameter "CDR log calls with zero <BR>> duration" to false so that CM does not record CDR for MWI. However, you<BR>> <BR>> risk losing CDR for other critical calls such as misdials/hangups to 911<BR>> <BR>> where the caller hangs up before 911 service answers. Most 911 <BR>> districts consider these prank calls with a quota and begin charging.<BR>> <BR>> Otherwise, no, there is no way to filter these calls from CDR. The <BR>> system dumps out CDR's of all calls. Parsing, filtering, and <BR>> correlating are the job of the "Call Accounting and Reporting" package.<BR>> <BR>> Just as Cisco generates the CDR flat files, RSI has to parse and import <BR>> every CDR flat file. They have equal opportunity to filter these <BR>> requests. As a bonus, RSI can do it without contending for <BR>> CPU/Memory/DiskIO that would otherwise be used for processing your <BR>> actual calls. It's a rather classic example of production vs.<BR>> reporting.<BR>> <BR>> /Wes<BR>> <BR>> Hames, Joel wrote:<BR>> > We have a new CCM5.1 installation, so I may ask a few basic questions<BR>> as<BR>> > we work through our first deployment. At the moment, we have<BR>> > implemented RSI's Call Accounting system and have noticed that our<BR>> > voicemail extension skews all of our reports significantly. RSI<BR>> claims<BR>> > that this is a Cisco configuration issue and that calls to that<BR>> > extension should not be passed to the call accounting system. Our<BR>> > installer claims that there is no way to filter out reporting to<BR>> certain<BR>> > extensions.<BR>> ><BR>> > Does anyone have experience with this? While we can certainly ignore<BR>> the<BR>> > reports of calls inbound and outbound to that extension, I'd like to<BR>> > clean this up as much as possible. The graphs of call lengths and<BR>> call<BR>> > costs would be much more meaningful without extraneous information<BR>> like<BR>> > this.<BR>> ><BR>> > Thank you,<BR>> ><BR>> > Joel Hames<BR>> > Senior Director, Information Technology<BR>> > Tamalpais Union High School District<BR>> > jhames@tamdistrict.org<BR>> ><BR>> > _______________________________________________<BR>> > cisco-voip mailing list<BR>> > cisco-voip@puck.nether.net<BR>> > https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> > <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 4<BR>> Date: Thu, 27 Dec 2007 10:57:05 -0800<BR>> From: "Scott Voll" <svoll.voip@gmail.com><BR>> Subject: Re: [cisco-voip] Excluding extensions from CDR reporting<BR>> To: "Hames, Joel" <jhames@tamdistrict.org><BR>> Cc: Cisco VoIP <cisco-voip@puck.nether.net><BR>> Message-ID:<BR>> <f84a38d30712271057i5cda7499j8d7b2571d63d354c@mail.gmail.com><BR>> Content-Type: text/plain; charset="iso-8859-1"<BR>> <BR>> if your using CER then 911 should not be an issue as it takes all the 911<BR>> calls and you don't really have a 911 or 9.911 route pattern.<BR>> <BR>> on the other note. Are you sure you don't want the VM data. people from<BR>> outside still get VM if no one is there and there for I would see this as<BR>> needed info.<BR>> <BR>> What are you doing with the reporting software that you don't what VM?<BR>> <BR>> Scott<BR>> <BR>> On Dec 27, 2007 10:41 AM, Hames, Joel <jhames@tamdistrict.org> wrote:<BR>> <BR>> > Thanks for the clarification and I apologize for the vagueness of the<BR>> > example. We are seeing both calls to our voicemail extension (2000) and<BR>> > to the MWI extensions (2090 and 2091). We recently disabled reporting<BR>> > for zero duration calls, but your point is well taken regarding 911<BR>> > hangups. I'll check with our implementer to see if our Emergency<BR>> > Responder installation will help offset this loss of detail. As for the<BR>> > voicemail extension itself (2000) that is logging all calls transferred<BR>> > to VM, I'll work with RSI again to see what they can do to help filter<BR>> > out this information for reporting.<BR>> ><BR>> > Joel Hames<BR>> > Senior Director, Information Technology<BR>> > Tamalpais Union High School District<BR>> > jhames@tamdistrict.org<BR>> ><BR>> > -----Original Message-----<BR>> > From: Wes Sisk [mailto:wsisk@cisco.com]<BR>> > Sent: Thursday, December 27, 2007 10:32 AM<BR>> > To: Hames, Joel<BR>> > Cc: Cisco VoIP<BR>> > Subject: Re: [cisco-voip] Excluding extensions from CDR reporting<BR>> ><BR>> > The verbiage provided is vague but i'm going to assume that CDR's for<BR>> > MWI calls are the crux of the issue. Those have been an issue before<BR>> > and are certainly numerous enough to skew reporting.<BR>> ><BR>> > The way CM is implemented Voicemail and the associated MWI transactions<BR>> > are calls. You can set CM service parameter "CDR log calls with zero<BR>> > duration" to false so that CM does not record CDR for MWI. However, you<BR>> ><BR>> > risk losing CDR for other critical calls such as misdials/hangups to 911<BR>> ><BR>> > where the caller hangs up before 911 service answers. Most 911<BR>> > districts consider these prank calls with a quota and begin charging.<BR>> ><BR>> > Otherwise, no, there is no way to filter these calls from CDR. The<BR>> > system dumps out CDR's of all calls. Parsing, filtering, and<BR>> > correlating are the job of the "Call Accounting and Reporting" package.<BR>> ><BR>> > Just as Cisco generates the CDR flat files, RSI has to parse and import<BR>> > every CDR flat file. They have equal opportunity to filter these<BR>> > requests. As a bonus, RSI can do it without contending for<BR>> > CPU/Memory/DiskIO that would otherwise be used for processing your<BR>> > actual calls. It's a rather classic example of production vs.<BR>> > reporting.<BR>> ><BR>> > /Wes<BR>> ><BR>> > Hames, Joel wrote:<BR>> > > We have a new CCM5.1 installation, so I may ask a few basic questions<BR>> > as<BR>> > > we work through our first deployment. At the moment, we have<BR>> > > implemented RSI's Call Accounting system and have noticed that our<BR>> > > voicemail extension skews all of our reports significantly. RSI<BR>> > claims<BR>> > > that this is a Cisco configuration issue and that calls to that<BR>> > > extension should not be passed to the call accounting system. Our<BR>> > > installer claims that there is no way to filter out reporting to<BR>> > certain<BR>> > > extensions.<BR>> > ><BR>> > > Does anyone have experience with this? While we can certainly ignore<BR>> > the<BR>> > > reports of calls inbound and outbound to that extension, I'd like to<BR>> > > clean this up as much as possible. The graphs of call lengths and<BR>> > call<BR>> > > costs would be much more meaningful without extraneous information<BR>> > like<BR>> > > this.<BR>> > ><BR>> > > Thank you,<BR>> > ><BR>> > > Joel Hames<BR>> > > Senior Director, Information Technology<BR>> > > Tamalpais Union High School District<BR>> > > jhames@tamdistrict.org<BR>> > ><BR>> > > _______________________________________________<BR>> > > cisco-voip mailing list<BR>> > > cisco-voip@puck.nether.net<BR>> > > https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> > ><BR>> > _______________________________________________<BR>> > cisco-voip mailing list<BR>> > cisco-voip@puck.nether.net<BR>> > https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> ><BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20071227/c1a45939/attachment-0001.html <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 5<BR>> Date: Thu, 27 Dec 2007 13:20:47 -0600<BR>> From: "Frazee, Timothy" <Timothy_Frazee@adp.com><BR>> Subject: [cisco-voip] TEHO information tracking<BR>> To: <cisco-voip@puck.nether.net><BR>> Message-ID:<BR>> <723FA17C6AA4C4428CDF572DCAEE08D405B00197@EXCHANGEDS01.ds.ad.adp.com><BR>> Content-Type: text/plain; charset="us-ascii"<BR>> <BR>> Group,<BR>> <BR>> <BR>> <BR>> Does anyone have a spreadsheet or something similar they use to track<BR>> TEHO implementation? I'm looking for some ideas otherwise I'll just<BR>> start my own and tweak it from there. Something for 70+ sites.<BR>> <BR>> <BR>> <BR>> Thanks.<BR>> <BR>> <BR>> <BR>> Timothy Frazee <BR>> <BR>> Network Solutions<BR>> <BR>> Automatic Data Processing, Inc.<BR>> <BR>> <BR>> <BR>> This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.<BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20071227/92a22e85/attachment.html <BR>> <BR>> ------------------------------<BR>> <BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> cisco-voip@puck.nether.net<BR>> https://puck.nether.net/mailman/listinfo/cisco-voip<BR>> <BR>> End of cisco-voip Digest, Vol 58, Issue 155<BR>> *******************************************<BR><br /><hr />She said what? About who? <a href='http://www.msnsearchstar.com' target='_new'>Shameful celebrity quotes on Search Star!</a></body>
</html>