<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1498" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>The <STRONG>immediate divert </STRONG>(iDivert I
believe) softkey should do this for you. It sends calls diretly to the voicemail
pilot corresponding to the lines voicemail profile. The same target when the
user presses the messages button with a line selected. I'm pretty sure if there
is no voicemail profile set (and there is no default voicemail profile) the
iDivert key will not work.</FONT></DIV>
<DIV> </DIV>
<DIV>-----
-----<BR>Lelio Fulgenzi,
B.A.
<A href="mailto:lelio@uoguelph.ca.eh">lelio@uoguelph.ca.eh</A><BR>Network
Analyst (CCS)<BR>University of
Guelph
FAX:(519) 767-1060 JNHN<BR>Guelph, Ontario N1G
2W1
TEL:(519) 824-4120
x56354<BR>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>mob
lawyer: your people insulted my brother.<BR>dr. house: what? romano in the
parmesan cheese shaker again?</DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=jgrace@digitelusa.net href="mailto:jgrace@digitelusa.net">James Grace
BB</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=cisco-voip@puck.nether.net
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, May 23, 2005 12:50 PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> [cisco-voip] Re: cisco-voip
Digest, Vol 27, Issue 68</DIV>
<DIV><BR></DIV>How do you tranfer to vm on cm4.1 and unity 4.0.4 . Can
we set up some type soft key <BR>-----Original Message-----<BR>From: <A
href="mailto:cisco-voip-request@puck.nether.net">cisco-voip-request@puck.nether.net</A><BR>Date:
Mon, 23 May 2005 11:41:39 <BR>To:cisco-voip@puck.nether.net<BR>Subject:
cisco-voip Digest, Vol 27, Issue 68<BR><BR>Send cisco-voip mailing list
submissions to<BR><A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><BR>To
subscribe or unsubscribe via the World Wide Web, visit<BR><A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>or,
via email, send a message with subject or body 'help' to<BR><A
href="mailto:cisco-voip-request@puck.nether.net">cisco-voip-request@puck.nether.net</A><BR><BR>You
can reach the person managing the list at<BR><A
href="mailto:cisco-voip-owner@puck.nether.net">cisco-voip-owner@puck.nether.net</A><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. RE: kErrorCDRFilesBackingUp - CDR flat files
are backingup.<BR> (Erick
Bergquist)<BR> 2. Re: how to block analog phone from dialing
LD (Erick Bergquist)<BR> 3. Re: kErrorCDRFilesBackingUp -
CDR flat files are backingup.<BR> (Wes
Sisk)<BR> 4. Re: 3rd Party Voice Mail Cluster using Hunt Groups
and CTI<BR> Route Points - Attendant Console
(Wes Sisk)<BR> 5. Re: kErrorCDRFilesBackingUp - CDR flat files are
backingup.<BR> (Erick Bergquist)<BR>
6. VoIP qualification and monitoring (Eric
Helm)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message:
1<BR>Date: Sun, 22 May 2005 10:51:32 -0700 (PDT)<BR>From: Erick Bergquist
<<A href="mailto:erickbe@yahoo.com">erickbe@yahoo.com</A>><BR>Subject:
RE: [cisco-voip] kErrorCDRFilesBackingUp - CDR flat files
are<BR>backingup.<BR>To: Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>>, <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:20050522175132.67930.qmail@web41111.mail.yahoo.com">20050522175132.67930.qmail@web41111.mail.yahoo.com</A>><BR>Content-Type:
text/plain; charset=us-ascii<BR><BR>Ok, Looks like adjusting time of database
layer<BR>monitor job to run from 5am to 7am got rid of the<BR>error. I moved
the time back and the error came back<BR>just to make sure it wasn't something
else.<BR><BR>So, my question is, how come the default times for<BR>these jobs
conflict with other SQL jobs being done by<BR>other
applications?<BR><BR>Database layer monitor default setting is 12am to
2am<BR>CDR load default time is 12am to 5am<BR><BR>Seems like issues may
happen like this customer had if<BR>you are loading and purging at same time
by two<BR>different processes. <BR><BR>I did not change the time of the CIPT
SQL Optimization<BR>yet. Does this job touch the CDR database or just
CCM<BR>database?<BR><BR>Thanks,<BR>Erick<BR><BR>--- Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>> wrote:<BR>> Check the
cdr insert log around that time. Looks<BR>> like SQL may be
dropping<BR>> offline or too busy to process the cdr insert<BR>>
request. could be the service<BR>> stopping i guess. make sure
the PID does not change<BR>> day to day for<BR>> cdrinsert. any
change would reflect a crash or<BR>> service restart for some<BR>>
reason. check the SQL server logs around that time<BR>> and see if it
reported<BR>> any events.<BR>> <BR>> this may be due to the IPT
optimization job running,<BR>> or the CDR purge<BR>> process
running. the 1st is a job in sql - when is<BR>> it scheduled to
run?<BR>> The 2nd is done by database layer monitor and timing<BR>> is
set by the dblm<BR>> service parameters. what time is it set to
run?<BR>> <BR>> on that same line the ART cdr purge could cause
the<BR>> same issue. is ART/CAR<BR>> configured to purge the CDR
database and if so, what<BR>> time?<BR>> <BR>> /Wes<BR>> <BR>>
-----Original Message-----<BR>> From: <A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>>
[mailto:cisco-voip-bounces@puck.nether.net]On Behalf<BR>> Of Erick
Bergquist<BR>> Sent: Thursday, May 19, 2005 10:16 PM<BR>> To: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
Subject: [cisco-voip] kErrorCDRFilesBackingUp - CDR<BR>> flat files
are<BR>> backingup.<BR>> <BR>> <BR>> Hi,<BR>> <BR>> Has
anyone had the below in Application event log<BR>> and<BR>> know a fix
for issue? I found a bug id that matches<BR>> on<BR>> this (CSCeg37424)
but the workaround is not working.<BR>> <BR>> The InsertCDR detailed
trace is turned on and the<BR>> error happens at 12:24am and the entry in
trace file<BR>> is at 12:34am saying 10 minute timeout occurred.<BR>>
Nothing in trace between 12:24 and 12:34.<BR>> <BR>> Issue was found in
CCM 4.0(1)ES 17.1 and marked as<BR>> unreproducable. This is on Call
Manager<BR>> 4.0(2a)Sr1a.<BR>> <BR>> Workaround from bug id is to
kill the insertcdr<BR>> process using c:\utils\kill command then restart
the<BR>> CDR insert service.<BR>> <BR>> These errors are occuring at
12:24am and 1:24am<BR>> nightly like clockwork. Not during day and CDR
is<BR>> working fine. BARS runs earlier before midnight.<BR>>
There<BR>> are no CDR flat files in the CDR folder either. They<BR>>
show up briefly then get inserted and deleted. We<BR>> have<BR>> a few
files in the bad folder but not from this time<BR>> period. Maybe 1-2 bad
cdr flat files a day.<BR>> <BR>> <BR>> Event Type: Error<BR>>
Event Source: Cisco Database Layer Monitor<BR>> Event Category:
None<BR>> Event ID: 3<BR>> Date: 5/18/2005<BR>> Time: 1:24:32
AM<BR>> User: N/A<BR>> Computer: CCM1<BR>> Description:<BR>>
Error: kErrorCDRFilesBackingUp - CDR flat files are<BR>> backing
up.<BR>> App ID: Cisco Database Layer
Monitor<BR>> Cluster ID: CCM1-Cluster<BR>> Node
ID: 172.16.2.20<BR>> Explanation: CDR flat files are not being removed.
<BR>> On<BR>> the primary CDR<BR>> server, verify that the InsertCDR
service is running<BR>> and properly<BR>> configured. On a server not
the primary, verify that<BR>> the location for<BR>> collecting CDR files
is accessible via the network.<BR>> Recommended Action: Set trace for
InsertCDR service<BR>> to<BR>> detailed and<BR>> look<BR>> for
errors in the trace. Check enterprise CDR<BR>> parameters for<BR>>
accuracy..<BR>> <BR>> <BR>> <BR>> <BR>>
__________________________________<BR>> Yahoo! Mail Mobile<BR>> Take
Yahoo! Mail with you! Check email on your<BR>> mobile phone.<BR>> <A
href="http://mobile.yahoo.com/learn/mail">http://mobile.yahoo.com/learn/mail</A><BR>>
_______________________________________________<BR>> cisco-voip mailing
list<BR>> <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
<A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>
<BR>> <BR><BR><BR><BR>Yahoo! Mail<BR>Stay connected, organized, and
protected. Take the tour:<BR><A
href="http://tour.mail.yahoo.com/mailtour.html">http://tour.mail.yahoo.com/mailtour.html</A><BR><BR><BR><BR>------------------------------<BR><BR>Message:
2<BR>Date: Sun, 22 May 2005 11:40:23 -0700 (PDT)<BR>From: Erick Bergquist
<<A href="mailto:erickbe@yahoo.com">erickbe@yahoo.com</A>><BR>Subject:
Re: [cisco-voip] how to block analog phone from dialing LD <BR>To: Lelio
Fulgenzi <<A href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</A>>, <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:20050522184023.2771.qmail@web41125.mail.yahoo.com">20050522184023.2771.qmail@web41125.mail.yahoo.com</A>><BR>Content-Type:
text/plain; charset=us-ascii<BR><BR>Also,<BR><BR>May want to consider using
FAC/CMCs and/or Time of Day<BR>Partitions which are both new features in 4.1
which<BR>could make things easier.<BR><BR>But I'm with lelio, just don't give
lobby phones a CSS<BR>with access to LD route patterns if it is not to
be<BR>allowed at all. <BR><BR>--- Lelio Fulgenzi <<A
href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</A>> wrote:<BR><BR>>
It all depends on how you are granting long distance<BR>> access in the
first place. But in a nutshell, access<BR>> to long distance is through a
route pattern(s) which<BR>> points to a PSTN gateway. Simply remove access
to<BR>> this route pattern and the phone will not be able to<BR>> dial
long distance. Access to any DN/pattern is<BR>> typically granted by
putting the partition which<BR>> contains the target DN/pattern in the
calling search<BR>> space of the device/line for which you want to
grant<BR>> access. By removing this partition, you remove<BR>>
access.<BR>> <BR>> Depending on your dialplan, however, you may
be<BR>> removing more than just long distance access by<BR>> removing
the partition. The partition may contain<BR>> local and 911 access for
example.<BR>> <BR>> You can also use a route pattern which blocks
access<BR>> if that is easier. The most exact match wins - with<BR>> the
line's partitions taking precedence if a tie<BR>> happens.<BR>> <BR>>
If you can post how things are done in your<BR>> dialplan, we might be able
to help a little more.<BR>> <BR>> Lelio<BR>> <BR>>
-----
<BR>>
-----<BR>> Lelio Fulgenzi,
B.A.
<BR>> <A
href="mailto:lelio@uoguelph.ca.eh">lelio@uoguelph.ca.eh</A><BR>> Network
Analyst (CCS)<BR>> University of
Guelph
<BR>> FAX:(519) 767-1060 JNHN<BR>> Guelph, Ontario N1G
2W1
<BR>> TEL:(519) 824-4120
x56354<BR>><BR>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>>
mob lawyer: your people insulted my brother.<BR>> dr. house: what? romano
in the parmesan cheese<BR>> shaker again?<BR>> -----
Original Message ----- <BR>> From: AA <BR>> To:
<A href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>
<BR>> Sent: Saturday, May 21, 2005 7:23 PM<BR>>
Subject: [cisco-voip] how to block analog phone<BR>> from dialing LD
<BR>> <BR>> <BR>> we have CM 4.1.2 and have some
analog phones in<BR>> the break room need to be block from dialing
LD. <BR>> How do we do this. We are using mgcp. Please
help<BR>> <BR>> <BR>> James Grace <BR>>
System Engineer /Professional Srvc.<BR>> MCSE MCSA MCDBA CCNA
CCNP CQS<BR>> <BR>> <BR>> <BR>>
<BR>><BR>------------------------------------------------------------------------------<BR>>
<BR>> <BR>>
_______________________________________________<BR>> cisco-voip
mailing list<BR>> <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
<BR>> <A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>
> _______________________________________________<BR>> cisco-voip
mailing list<BR>> <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
<A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>
<BR><BR><BR><BR><BR>__________________________________ <BR>Yahoo! Mail Mobile
<BR>Take Yahoo! Mail with you! Check email on your mobile phone. <BR><A
href="http://mobile.yahoo.com/learn/mail">http://mobile.yahoo.com/learn/mail</A>
<BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Sun, 22
May 2005 18:18:29 -0400<BR>From: Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>><BR>Subject: Re:
[cisco-voip] kErrorCDRFilesBackingUp - CDR flat files are<BR>backingup.<BR>To:
<A href="mailto:erickbe@yahoo.com">erickbe@yahoo.com</A><BR>Cc: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:42910535.1000909@cisco.com">42910535.1000909@cisco.com</A>><BR>Content-Type:
text/plain; charset=ISO-8859-1; format=flowed<BR><BR>Open a TAC case for this
CU and we can open a bug for more formal <BR>investiation and broad sweeping
fix.<BR><BR>check the steps of the job. last i checked it optimized the
ccm and cdr <BR>databases. that includes rebuilding indexes which would
affect the <BR>accessibility of those db's for
operations.<BR><BR>/Wes<BR><BR>Erick Bergquist wrote:<BR><BR>>Ok, Looks
like adjusting time of database layer<BR>>monitor job to run from 5am to
7am got rid of the<BR>>error. I moved the time back and the error came
back<BR>>just to make sure it wasn't something else.<BR>><BR>>So, my
question is, how come the default times for<BR>>these jobs conflict with
other SQL jobs being done by<BR>>other
applications?<BR>><BR>>Database layer monitor default setting is 12am to
2am<BR>>CDR load default time is 12am to 5am<BR>><BR>>Seems like
issues may happen like this customer had if<BR>>you are loading and purging
at same time by two<BR>>different processes. <BR>><BR>>I did not
change the time of the CIPT SQL Optimization<BR>>yet. Does this job touch
the CDR database or just
CCM<BR>>database?<BR>><BR>>Thanks,<BR>>Erick<BR>><BR>>---
Wes Sisk <<A href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>>
wrote:<BR>> <BR>><BR>>>Check the cdr insert log around that
time. Looks<BR>>>like SQL may be dropping<BR>>>offline or too busy
to process the cdr insert<BR>>>request. could be the
service<BR>>>stopping i guess. make sure the PID does not
change<BR>>>day to day for<BR>>>cdrinsert. any change would
reflect a crash or<BR>>>service restart for
some<BR>>>reason. check the SQL server logs around that
time<BR>>>and see if it reported<BR>>>any
events.<BR>>><BR>>>this may be due to the IPT optimization job
running,<BR>>>or the CDR purge<BR>>>process running. the 1st
is a job in sql - when is<BR>>>it scheduled to run?<BR>>>The 2nd
is done by database layer monitor and timing<BR>>>is set by the
dblm<BR>>>service parameters. what time is it set to
run?<BR>>><BR>>>on that same line the ART cdr purge could cause
the<BR>>>same issue. is ART/CAR<BR>>>configured to purge the
CDR database and if so,
what<BR>>>time?<BR>>><BR>>>/Wes<BR>>><BR>>>-----Original
Message-----<BR>>>From: <A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>>>[mailto:cisco-voip-bounces@puck.nether.net]On
Behalf<BR>>>Of Erick Bergquist<BR>>>Sent: Thursday, May 19, 2005
10:16 PM<BR>>>To: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>Subject:
[cisco-voip] kErrorCDRFilesBackingUp - CDR<BR>>>flat files
are<BR>>>backingup.<BR>>><BR>>><BR>>>Hi,<BR>>><BR>>>Has
anyone had the below in Application event log<BR>>>and<BR>>>know a
fix for issue? I found a bug id that matches<BR>>>on<BR>>>this
(CSCeg37424) but the workaround is not working.<BR>>><BR>>>The
InsertCDR detailed trace is turned on and the<BR>>>error happens at
12:24am and the entry in trace file<BR>>>is at 12:34am saying 10 minute
timeout occurred.<BR>>>Nothing in trace between 12:24 and
12:34.<BR>>><BR>>>Issue was found in CCM 4.0(1)ES 17.1 and marked
as<BR>>>unreproducable. This is on Call
Manager<BR>>>4.0(2a)Sr1a.<BR>>><BR>>>Workaround from bug id
is to kill the insertcdr<BR>>>process using c:\utils\kill command then
restart the<BR>>>CDR insert service.<BR>>><BR>>>These errors
are occuring at 12:24am and 1:24am<BR>>>nightly like clockwork. Not
during day and CDR is<BR>>>working fine. BARS runs earlier before
midnight.<BR>>>There<BR>>>are no CDR flat files in the CDR folder
either. They<BR>>>show up briefly then get inserted and deleted.
We<BR>>>have<BR>>>a few files in the bad folder but not from this
time<BR>>>period. Maybe 1-2 bad cdr flat files a
day.<BR>>><BR>>><BR>>>Event Type: Error<BR>>>Event
Source: Cisco Database Layer Monitor<BR>>>Event Category:
None<BR>>>Event ID: 3<BR>>>Date: 5/18/2005<BR>>>Time:
1:24:32 AM<BR>>>User: N/A<BR>>>Computer:
CCM1<BR>>>Description:<BR>>>Error: kErrorCDRFilesBackingUp - CDR
flat files are<BR>>>backing up.<BR>>> App ID: Cisco Database
Layer Monitor<BR>>> Cluster ID: CCM1-Cluster<BR>>>
Node ID: 172.16.2.20<BR>>>Explanation: CDR flat files are not being
removed. <BR>>>On<BR>>>the primary CDR<BR>>>server, verify
that the InsertCDR service is running<BR>>>and
properly<BR>>>configured. On a server not the primary, verify
that<BR>>>the location for<BR>>>collecting CDR files is accessible
via the network.<BR>>>Recommended Action: Set trace for InsertCDR
service<BR>>>to<BR>>>detailed and<BR>>>look<BR>>>for
errors in the trace. Check enterprise CDR<BR>>>parameters
for<BR>>>accuracy..<BR>>><BR>>><BR>>><BR>>><BR>>>__________________________________<BR>>>Yahoo!
Mail Mobile<BR>>>Take Yahoo! Mail with you! Check email on
your<BR>>>mobile
phone.<BR>>>http://mobile.yahoo.com/learn/mail<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>><BR>> <BR>>Yahoo! Mail<BR>>Stay
connected, organized, and protected. Take the
tour:<BR>>http://tour.mail.yahoo.com/mailtour.html<BR>>
<BR>><BR><BR><BR>------------------------------<BR><BR>Message: 4<BR>Date:
Sun, 22 May 2005 21:14:48 -0400<BR>From: Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>><BR>Subject: Re:
[cisco-voip] 3rd Party Voice Mail Cluster using Hunt<BR>Groups and CTI Route
Points - Attendant Console<BR>To: Paul Yago <<A
href="mailto:pyago@adomo.com">pyago@adomo.com</A>><BR>Cc: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:42912E88.6090409@cisco.com">42912E88.6090409@cisco.com</A>><BR>Content-Type:
text/plain; charset=ISO-8859-1; format=flowed<BR><BR>So you need to load
balance / round robin over CTI Route Points. If <BR>you're already in
the CTI business, how about a small application script <BR>to round robin
between them? This is very easy with Cisco CRS.<BR><BR>Though i'm not
certain why Attendant Console Hunt Groups would not work <BR>for this.
It is valid (and works) to make an AC Pilot Point (which is <BR>really just a
CTI Route Point) A member of another AC Hunt Group. <BR>You're certain
the AC Huntgroup was functaional otherwise? It has be <BR>associated to
the AC user, TCD has to be running, etc.<BR><BR>/Wes<BR><BR>Paul Yago
wrote:<BR><BR>>Wes, actually the VMs are interfacing directly to a CTI
Route Point. A<BR>>CTI Port is not being used by the
VM.<BR>><BR>>-----Original Message-----<BR>>From: Wes Sisk
[mailto:wsisk@cisco.com] <BR>>Sent: Wednesday, May 18, 2005 1:08
PM<BR>>To: Paul Yago<BR>>Cc: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>Subject:
Re: [cisco-voip] 3rd Party Voice Mail Cluster using Hunt Groups<BR>>and CTI
Route Points - Attendant Console<BR>><BR>>Paul,<BR>><BR>>do your
vm systems pickup calls directly from cti ports? or do they <BR>>depend on
redirects from CTI Route Point down to CTI
port?<BR>><BR>>/Wes<BR>><BR>>Paul Yago
wrote:<BR>><BR>>
<BR>><BR>>>Wes,<BR>>><BR>>>With AC, I believe I will
encounter the same limitation when including<BR>>>CTI Route Point
extensions in the Hunt Group. I've tried this once<BR>>>before but
please correct me if I'm wrong. I'm trying this
again.<BR>>><BR>>>Thanks<BR>>>-
Paul<BR>>><BR>>>-----Original Message-----<BR>>>From: Wes
Sisk [mailto:wsisk@cisco.com] <BR>>>Sent: Wednesday, May 18, 2005 12:46
PM<BR>>>To: Paul Yago<BR>>>Cc: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>Subject:
Re: [cisco-voip] 3rd Party Voice Mail Cluster using
Hunt<BR>>> <BR>>><BR>>Groups<BR>>
<BR>><BR>>>and CTI Route Points<BR>>><BR>>>I don't have a
cti app handy to test with, but you may be able to use <BR>>>Attendant
Console Pilot Point to frontend your cti
ports.<BR>>><BR>>>/Wes<BR>>><BR>>>Paul Yago
wrote:<BR>>><BR>>> <BR>>><BR>>>
<BR>>><BR>>>>Hello,<BR>>>><BR>>>>We're trying
to create a 3rd Party Voice Mail Cluster using Line <BR>>>>Groups and
CTI Route Points.<BR>>>><BR>>>>I'm sure there are other
people encountering this issue as well, and I<BR>>>>
<BR>>>><BR>>>>
<BR>>>><BR>>> <BR>>><BR>>>
<BR>>><BR>>>>hope there is a work-around. Cisco claims that one
doesn't yet exist <BR>>>>and that a solution will exist in the
future. Personally, I haven't <BR>>>>found one
yet.<BR>>>><BR>>>>We wish to cluster up to 4 - 3^rd party
Voice Mail Servers (VMs) to <BR>>>>our 4.1 Call Manager in order to
provide both redundancy and dynamic <BR>>>>load balancing. The
initial attempt at this was to create a Line <BR>>>>Group, containing
CTI Route Point extensions, along with a Hunt List <BR>>>>and a Hunt
Pilot. The Hunt pilot would be called and one of the <BR>>>>members
of the LG would be accessed based a distribution algorithm.
<BR>>>>This didn't work because the members of an LG can only be
phone <BR>>>>extensions, rather than CTI
extensions.<BR>>>><BR>>>>The next attempt was to use a phone
extension and configure it to <BR>>>>provided forwarding to the CTI
extension. Again this failed because <BR>>>>all forwarding is
disabled for an extension that resides in an LG. <BR>>>>Perhaps there
is a way to enable forwarding of extensions when they <BR>>>>reside
in an LG; however I have not yet found it.<BR>>>><BR>>>>Is
anyone familiar with this situation and with a solution that can
be<BR>>>>
<BR>>>><BR>>>>
<BR>>>><BR>>> <BR>>><BR>>>
<BR>>><BR>>>>applied within the Call Manager
itself?<BR>>>><BR>>>>Regards,<BR>>>><BR>>>>Paul<BR>>>><BR>>>>----------------------------------------------------------------------<BR>>>>
<BR>>>><BR>>-<BR>> <BR>><BR>>>>
<BR>>>><BR>>>>
<BR>>>><BR>>>-<BR>>>
<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>>>><BR>>>>
<BR>>>><BR>>>>
<BR>>>><BR><BR><BR>------------------------------<BR><BR>Message:
5<BR>Date: Mon, 23 May 2005 07:39:52 -0700 (PDT)<BR>From: Erick Bergquist
<<A href="mailto:erickbe@yahoo.com">erickbe@yahoo.com</A>><BR>Subject:
Re: [cisco-voip] kErrorCDRFilesBackingUp - CDR flat files
are<BR>backingup.<BR>To: Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>><BR>Cc: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:20050523143952.52335.qmail@web41129.mail.yahoo.com">20050523143952.52335.qmail@web41129.mail.yahoo.com</A>><BR>Content-Type:
text/plain; charset=us-ascii<BR><BR>Wes,<BR><BR>I'm going to go ahead and open
a TAC Case on this. Now<BR>the error is happening at 5:23am instead of 12:24am
so<BR>must be some thing with the database layer monitor<BR>maint causing this
error.<BR><BR>--- Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>> wrote:<BR><BR>> Open
a TAC case for this CU and we can open a bug<BR>> for more formal <BR>>
investiation and broad sweeping fix.<BR>> <BR>> check the steps of the
job. last i checked it<BR>> optimized the ccm and cdr <BR>>
databases. that includes rebuilding indexes which<BR>> would affect
the <BR>> accessibility of those db's for operations.<BR>> <BR>>
/Wes<BR>> <BR>> Erick Bergquist wrote:<BR>> <BR>> >Ok, Looks
like adjusting time of database layer<BR>> >monitor job to run from 5am
to 7am got rid of the<BR>> >error. I moved the time back and the error
came<BR>> back<BR>> >just to make sure it wasn't something
else.<BR>> ><BR>> >So, my question is, how come the default times
for<BR>> >these jobs conflict with other SQL jobs being done<BR>>
by<BR>> >other applications?<BR>> ><BR>> >Database layer
monitor default setting is 12am to<BR>> 2am<BR>> >CDR load default
time is 12am to 5am<BR>> ><BR>> >Seems like issues may happen like
this customer had<BR>> if<BR>> >you are loading and purging at same
time by two<BR>> >different processes. <BR>> ><BR>> >I did
not change the time of the CIPT SQL<BR>> Optimization<BR>> >yet. Does
this job touch the CDR database or just<BR>> CCM<BR>>
>database?<BR>> ><BR>> >Thanks,<BR>> >Erick<BR>>
><BR>> >--- Wes Sisk <<A
href="mailto:wsisk@cisco.com">wsisk@cisco.com</A>> wrote:<BR>>
> <BR>> ><BR>> >>Check the cdr insert log around that
time. Looks<BR>> >>like SQL may be dropping<BR>> >>offline
or too busy to process the cdr insert<BR>> >>request. could be
the service<BR>> >>stopping i guess. make sure the PID does
not<BR>> change<BR>> >>day to day for<BR>>
>>cdrinsert. any change would reflect a crash or<BR>>
>>service restart for some<BR>> >>reason. check the SQL
server logs around that<BR>> time<BR>> >>and see if it
reported<BR>> >>any events.<BR>> >><BR>> >>this may
be due to the IPT optimization job<BR>> running,<BR>> >>or the CDR
purge<BR>> >>process running. the 1st is a job in sql -
when<BR>> is<BR>> >>it scheduled to run?<BR>> >>The 2nd
is done by database layer monitor and<BR>> timing<BR>> >>is set by
the dblm<BR>> >>service parameters. what time is it set to
run?<BR>> >><BR>> >>on that same line the ART cdr purge
could cause<BR>> the<BR>> >>same issue. is ART/CAR<BR>>
>>configured to purge the CDR database and if so,<BR>> what<BR>>
>>time?<BR>> >><BR>> >>/Wes<BR>> >><BR>>
>>-----Original Message-----<BR>> >>From: <A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>>
>>[mailto:cisco-voip-bounces@puck.nether.net]On<BR>> Behalf<BR>>
>>Of Erick Bergquist<BR>> >>Sent: Thursday, May 19, 2005 10:16
PM<BR>> >>To: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
>>Subject: [cisco-voip] kErrorCDRFilesBackingUp -<BR>> CDR<BR>>
>>flat files are<BR>> >>backingup.<BR>> >><BR>>
>><BR>> >>Hi,<BR>> >><BR>> >>Has anyone had
the below in Application event log<BR>> >>and<BR>> >>know a
fix for issue? I found a bug id that<BR>> matches<BR>>
>>on<BR>> >>this (CSCeg37424) but the workaround is not<BR>>
working.<BR>> >><BR>> >>The InsertCDR detailed trace is
turned on and the<BR>> >>error happens at 12:24am and the entry in
trace<BR>> file<BR>> >>is at 12:34am saying 10 minute timeout
occurred.<BR>> >>Nothing in trace between 12:24 and 12:34.<BR>>
>><BR>> >>Issue was found in CCM 4.0(1)ES 17.1 and marked
as<BR>> >>unreproducable. This is on Call Manager<BR>>
>>4.0(2a)Sr1a.<BR>> >><BR>> >>Workaround from bug id
is to kill the insertcdr<BR>> >>process using c:\utils\kill command
then restart<BR>> the<BR>> >>CDR insert service.<BR>>
>><BR>> >>These errors are occuring at 12:24am and
1:24am<BR>> >>nightly like clockwork. Not during day and CDR
is<BR>> >>working fine. BARS runs earlier before midnight.<BR>>
>>There<BR>> >>are no CDR flat files in the CDR folder
either.<BR>> They<BR>> >>show up briefly then get inserted and
deleted. We<BR>> >>have<BR>> >>a few files in the bad folder
but not from this<BR>> time<BR>> >>period. Maybe 1-2 bad cdr flat
files a day.<BR>> >><BR>> >><BR>> >>Event Type:
Error<BR>> >>Event Source: Cisco Database Layer Monitor<BR>>
>>Event Category: None<BR>> >>Event ID: 3<BR>> >>Date:
5/18/2005<BR>> >>Time: 1:24:32 AM<BR>> >>User: N/A<BR>>
>>Computer: CCM1<BR>> >>Description:<BR>> >>Error:
kErrorCDRFilesBackingUp - CDR flat files<BR>> are<BR>> >>backing
up.<BR>> >> App ID: Cisco Database Layer Monitor<BR>>
>> Cluster ID: CCM1-Cluster<BR>> >> Node ID:
172.16.2.20<BR>> >>Explanation: CDR flat files are not being
removed.<BR>> <BR>> >>On<BR>> >>the primary CDR<BR>>
>>server, verify that the InsertCDR service is<BR>> running<BR>>
>>and properly<BR>> >>configured. On a server not the primary,
verify<BR>> that<BR>> >>the location for<BR>>
>>collecting CDR files is accessible via the<BR>> network.<BR>>
>>Recommended Action: Set trace for InsertCDR<BR>> service<BR>>
>>to<BR>> >>detailed and<BR>> >>look<BR>>
>>for errors in the trace. Check enterprise CDR<BR>>
>>parameters for<BR>> >>accuracy..<BR>> >><BR>>
>><BR>> >><BR>> >><BR>>
>>__________________________________<BR>> >>Yahoo! Mail
Mobile<BR>> >>Take Yahoo! Mail with you! Check email on your<BR>>
>>mobile phone.<BR>>
>>http://mobile.yahoo.com/learn/mail<BR>>
>>_______________________________________________<BR>>
>>cisco-voip mailing list<BR>>
>>cisco-voip@puck.nether.net<BR>><BR>>>https://puck.nether.net/mailman/listinfo/cisco-voip<BR>>
>><BR>> >><BR>> >> <BR>>
>><BR>> ><BR>> ><BR>> > <BR>> >Yahoo!
Mail<BR>> >Stay connected, organized, and protected. Take the<BR>>
tour:<BR>> >http://tour.mail.yahoo.com/mailtour.html<BR>> >
<BR>> ><BR>> <BR><BR><BR><BR><BR>__________________________________
<BR>Yahoo! Mail Mobile <BR>Take Yahoo! Mail with you! Check email on your
mobile phone. <BR><A
href="http://mobile.yahoo.com/learn/mail">http://mobile.yahoo.com/learn/mail</A>
<BR><BR><BR>------------------------------<BR><BR>Message: 6<BR>Date: Mon, 23
May 2005 10:41:40 -0500<BR>From: Eric Helm <<A
href="mailto:helmwork@ruraltel.net">helmwork@ruraltel.net</A>><BR>Subject:
[cisco-voip] VoIP qualification and monitoring<BR>To: <A
href="mailto:voiss-users@osmon.net">voiss-users@osmon.net</A>, <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Message-ID:
<<A
href="mailto:4291F9B4.9070100@ruraltel.net">4291F9B4.9070100@ruraltel.net</A>><BR>Content-Type:
text/plain; charset=ISO-8859-1; format=flowed<BR><BR>I've been looking at some
products for 'pre-qualifying' customer <BR>networks for QOS/VoIP and for
analyzing and monitoring our VoIP <BR>infrastructure.<BR>Protocols used are
SIP, MGCP and SCCP.<BR>Codecs used are g.711 and g.729a.<BR><BR>Some of the
vendors for VoIP monitoring and analysis that have come up <BR>include
Acterna, Artiza, Clear Sight, Empirix, Finisar, Fluke, Network <BR>Associates,
Radcom, Voila and Wildpackets.<BR><BR>Some of these vendors and Ixia have come
up for QOS and VoIP qualification.<BR><BR>Anyone have any
recommendations/experience with any of the above <BR>product(s) or other
suggestions for my
requirements?<BR><BR>/Eric<BR><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>cisco-voip
mailing list<BR><A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>End
of cisco-voip Digest, Vol 27, Issue
68<BR>******************************************<BR>---<BR><BR><BR><BR>James
D. Grace <BR>MCSE MCDBA CCNA CCNP CQS<BR>Sr. System Engineer
<BR>_______________________________________________<BR>cisco-voip mailing
list<BR><A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR></BLOCKQUOTE></BODY></HTML>