[cisco-voip] Re: cisco-voip Digest, Vol 27, Issue 68

Lelio Fulgenzi lelio at uoguelph.ca
Mon May 23 12:56:06 EDT 2005


The immediate divert (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.

-----                                                                -----
Lelio Fulgenzi, B.A.                                  lelio at uoguelph.ca.eh
Network Analyst (CCS)
University of Guelph                             FAX:(519) 767-1060 JNHN
Guelph, Ontario N1G 2W1                          TEL:(519) 824-4120 x56354
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mob lawyer: your people insulted my brother.
dr. house: what? romano in the parmesan cheese shaker again?
  ----- Original Message ----- 
  From: James Grace BB 
  To: cisco-voip at puck.nether.net 
  Sent: Monday, May 23, 2005 12:50 PM
  Subject: [cisco-voip] Re: cisco-voip Digest, Vol 27, Issue 68


  How do you tranfer to vm on cm4.1 and unity 4.0.4 .  Can we set up some type soft key 
  -----Original Message-----
  From: cisco-voip-request at puck.nether.net
  Date: Mon, 23 May 2005 11:41:39 
  To:cisco-voip at puck.nether.net
  Subject: cisco-voip Digest, Vol 27, Issue 68

  Send cisco-voip mailing list submissions to
  cisco-voip at puck.nether.net

  To subscribe or unsubscribe via the World Wide Web, visit
  https://puck.nether.net/mailman/listinfo/cisco-voip
  or, via email, send a message with subject or body 'help' to
  cisco-voip-request at puck.nether.net

  You can reach the person managing the list at
  cisco-voip-owner at puck.nether.net

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of cisco-voip digest..."


  Today's Topics:

     1. RE: kErrorCDRFilesBackingUp - CDR flat files are backingup.
        (Erick Bergquist)
     2. Re: how to block analog phone from dialing LD  (Erick Bergquist)
     3. Re: kErrorCDRFilesBackingUp - CDR flat files are backingup.
        (Wes Sisk)
     4. Re: 3rd Party Voice Mail Cluster using Hunt Groups and CTI
        Route Points - Attendant Console (Wes Sisk)
     5. Re: kErrorCDRFilesBackingUp - CDR flat files are backingup.
        (Erick Bergquist)
     6. VoIP qualification and monitoring (Eric Helm)


  ----------------------------------------------------------------------

  Message: 1
  Date: Sun, 22 May 2005 10:51:32 -0700 (PDT)
  From: Erick Bergquist <erickbe at yahoo.com>
  Subject: RE: [cisco-voip] kErrorCDRFilesBackingUp - CDR flat files are
  backingup.
  To: Wes Sisk <wsisk at cisco.com>, cisco-voip at puck.nether.net
  Message-ID: <20050522175132.67930.qmail at web41111.mail.yahoo.com>
  Content-Type: text/plain; charset=us-ascii

  Ok, Looks like adjusting time of database layer
  monitor job to run from 5am to 7am got rid of the
  error. I moved the time back and the error came back
  just to make sure it wasn't something else.

  So, my question is, how come the default times for
  these jobs conflict with other SQL jobs being done by
  other applications?

  Database layer monitor default setting is 12am to 2am
  CDR load default time is 12am to 5am

  Seems like issues may happen like this customer had if
  you are loading and purging at same time by two
  different processes. 

  I did not change the time of the CIPT SQL Optimization
  yet. Does this job touch the CDR database or just CCM
  database?

  Thanks,
  Erick

  --- Wes Sisk <wsisk at cisco.com> wrote:
  > Check the cdr insert log around that time. Looks
  > like SQL may be dropping
  > offline or too busy to process the cdr insert
  > request.  could be the service
  > stopping i guess.  make sure the PID does not change
  > day to day for
  > cdrinsert.  any change would reflect a crash or
  > service restart for some
  > reason.  check the SQL server logs around that time
  > and see if it reported
  > any events.
  > 
  > this may be due to the IPT optimization job running,
  > or the CDR purge
  > process running.  the 1st is a job in sql - when is
  > it scheduled to run?
  > The 2nd is done by database layer monitor and timing
  > is set by the dblm
  > service parameters.  what time is it set to run?
  > 
  > on that same line the ART cdr purge could cause the
  > same issue.  is ART/CAR
  > configured to purge the CDR database and if so, what
  > time?
  > 
  > /Wes
  > 
  > -----Original Message-----
  > From: cisco-voip-bounces at puck.nether.net
  > [mailto:cisco-voip-bounces at puck.nether.net]On Behalf
  > Of Erick Bergquist
  > Sent: Thursday, May 19, 2005 10:16 PM
  > To: cisco-voip at puck.nether.net
  > Subject: [cisco-voip] kErrorCDRFilesBackingUp - CDR
  > flat files are
  > backingup.
  > 
  > 
  > Hi,
  > 
  > Has anyone had the below in Application event log
  > and
  > know a fix for issue? I found a bug id that matches
  > on
  > this (CSCeg37424) but the workaround is not working.
  > 
  > The InsertCDR detailed trace is turned on and the
  > error happens at 12:24am and the entry in trace file
  > is at 12:34am saying 10 minute timeout occurred.
  > Nothing in trace between 12:24 and 12:34.
  > 
  > Issue was found in CCM 4.0(1)ES 17.1 and marked as
  > unreproducable.  This is on Call Manager
  > 4.0(2a)Sr1a.
  > 
  > Workaround from bug id is to kill the insertcdr
  > process using c:\utils\kill command then restart the
  > CDR insert service.
  > 
  > These errors are occuring at 12:24am and 1:24am
  > nightly like clockwork. Not during day and CDR is
  > working fine. BARS runs earlier before midnight.
  > There
  > are no CDR flat files in the CDR folder either. They
  > show up briefly then get inserted and deleted. We
  > have
  > a few files in the bad folder but not from this time
  > period. Maybe 1-2 bad cdr flat files a day.
  > 
  > 
  > Event Type: Error
  > Event Source: Cisco Database Layer Monitor
  > Event Category: None
  > Event ID: 3
  > Date: 5/18/2005
  > Time: 1:24:32 AM
  > User: N/A
  > Computer: CCM1
  > Description:
  > Error: kErrorCDRFilesBackingUp - CDR flat files are
  > backing up.
  >   App ID: Cisco Database Layer Monitor
  >   Cluster ID: CCM1-Cluster
  >   Node ID: 172.16.2.20
  > Explanation: CDR flat files are not being removed. 
  > On
  > the primary CDR
  > server, verify that the InsertCDR service is running
  > and properly
  > configured. On a server not the primary, verify that
  > the location for
  > collecting CDR files is accessible via the network.
  > Recommended Action: Set trace for InsertCDR service
  > to
  > detailed and
  > look
  > for errors in the trace.  Check enterprise CDR
  > parameters for
  > accuracy..
  > 
  > 
  > 
  > 
  > __________________________________
  > Yahoo! Mail Mobile
  > Take Yahoo! Mail with you! Check email on your
  > mobile phone.
  > http://mobile.yahoo.com/learn/mail
  > _______________________________________________
  > cisco-voip mailing list
  > cisco-voip at puck.nether.net
  > https://puck.nether.net/mailman/listinfo/cisco-voip
  > 
  > 



  Yahoo! Mail
  Stay connected, organized, and protected. Take the tour:
  http://tour.mail.yahoo.com/mailtour.html



  ------------------------------

  Message: 2
  Date: Sun, 22 May 2005 11:40:23 -0700 (PDT)
  From: Erick Bergquist <erickbe at yahoo.com>
  Subject: Re: [cisco-voip] how to block analog phone from dialing LD 
  To: Lelio Fulgenzi <lelio at uoguelph.ca>, cisco-voip at puck.nether.net
  Message-ID: <20050522184023.2771.qmail at web41125.mail.yahoo.com>
  Content-Type: text/plain; charset=us-ascii

  Also,

  May want to consider using FAC/CMCs and/or Time of Day
  Partitions which are both new features in 4.1 which
  could make things easier.

  But I'm with lelio, just don't give lobby phones a CSS
  with access to LD route patterns if it is not to be
  allowed at all. 

  --- Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

  > It all depends on how you are granting long distance
  > access in the first place. But in a nutshell, access
  > to long distance is through a route pattern(s) which
  > points to a PSTN gateway. Simply remove access to
  > this route pattern and the phone will not be able to
  > dial long distance. Access to any DN/pattern is
  > typically granted by putting the partition which
  > contains the target DN/pattern in the calling search
  > space of the device/line for which you want to grant
  > access. By removing this partition, you remove
  > access.
  > 
  > Depending on your dialplan, however, you may be
  > removing more than just long distance access by
  > removing the partition. The partition may contain
  > local and 911 access for example.
  > 
  > You can also use a route pattern which blocks access
  > if that is easier. The most exact match wins - with
  > the line's partitions taking precedence if a tie
  > happens.
  > 
  > If you can post how things are done in your
  > dialplan, we might be able to help a little more.
  > 
  > Lelio
  > 
  > -----                                               
  >                 -----
  > Lelio Fulgenzi, B.A.                                
  >  lelio at uoguelph.ca.eh
  > Network Analyst (CCS)
  > University of Guelph                            
  > FAX:(519) 767-1060 JNHN
  > Guelph, Ontario N1G 2W1                         
  > TEL:(519) 824-4120 x56354
  >
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  > mob lawyer: your people insulted my brother.
  > dr. house: what? romano in the parmesan cheese
  > shaker again?
  >   ----- Original Message ----- 
  >   From: AA 
  >   To: cisco-voip at puck.nether.net 
  >   Sent: Saturday, May 21, 2005 7:23 PM
  >   Subject: [cisco-voip] how to block analog phone
  > from dialing LD 
  > 
  > 
  >   we have CM 4.1.2  and have some analog phones in
  > the break room need  to be block from dialing LD. 
  > How do we do this.  We are using mgcp.  Please help
  > 
  > 
  >   James Grace 
  >   System Engineer /Professional Srvc.
  >   MCSE MCSA MCDBA CCNA CCNP CQS
  > 
  > 
  > 
  > 
  >
  ------------------------------------------------------------------------------
  > 
  > 
  >   _______________________________________________
  >   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
  > 




  __________________________________ 
  Yahoo! Mail Mobile 
  Take Yahoo! Mail with you! Check email on your mobile phone. 
  http://mobile.yahoo.com/learn/mail 


  ------------------------------

  Message: 3
  Date: Sun, 22 May 2005 18:18:29 -0400
  From: Wes Sisk <wsisk at cisco.com>
  Subject: Re: [cisco-voip] kErrorCDRFilesBackingUp - CDR flat files are
  backingup.
  To: erickbe at yahoo.com
  Cc: cisco-voip at puck.nether.net
  Message-ID: <42910535.1000909 at cisco.com>
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  Open a TAC case for this CU and we can open a bug for more formal 
  investiation and broad sweeping fix.

  check the steps of the job.  last i checked it optimized the ccm and cdr 
  databases.  that includes rebuilding indexes which would affect the 
  accessibility of those db's for operations.

  /Wes

  Erick Bergquist wrote:

  >Ok, Looks like adjusting time of database layer
  >monitor job to run from 5am to 7am got rid of the
  >error. I moved the time back and the error came back
  >just to make sure it wasn't something else.
  >
  >So, my question is, how come the default times for
  >these jobs conflict with other SQL jobs being done by
  >other applications?
  >
  >Database layer monitor default setting is 12am to 2am
  >CDR load default time is 12am to 5am
  >
  >Seems like issues may happen like this customer had if
  >you are loading and purging at same time by two
  >different processes. 
  >
  >I did not change the time of the CIPT SQL Optimization
  >yet. Does this job touch the CDR database or just CCM
  >database?
  >
  >Thanks,
  >Erick
  >
  >--- Wes Sisk <wsisk at cisco.com> wrote:
  >  
  >
  >>Check the cdr insert log around that time. Looks
  >>like SQL may be dropping
  >>offline or too busy to process the cdr insert
  >>request.  could be the service
  >>stopping i guess.  make sure the PID does not change
  >>day to day for
  >>cdrinsert.  any change would reflect a crash or
  >>service restart for some
  >>reason.  check the SQL server logs around that time
  >>and see if it reported
  >>any events.
  >>
  >>this may be due to the IPT optimization job running,
  >>or the CDR purge
  >>process running.  the 1st is a job in sql - when is
  >>it scheduled to run?
  >>The 2nd is done by database layer monitor and timing
  >>is set by the dblm
  >>service parameters.  what time is it set to run?
  >>
  >>on that same line the ART cdr purge could cause the
  >>same issue.  is ART/CAR
  >>configured to purge the CDR database and if so, what
  >>time?
  >>
  >>/Wes
  >>
  >>-----Original Message-----
  >>From: cisco-voip-bounces at puck.nether.net
  >>[mailto:cisco-voip-bounces at puck.nether.net]On Behalf
  >>Of Erick Bergquist
  >>Sent: Thursday, May 19, 2005 10:16 PM
  >>To: cisco-voip at puck.nether.net
  >>Subject: [cisco-voip] kErrorCDRFilesBackingUp - CDR
  >>flat files are
  >>backingup.
  >>
  >>
  >>Hi,
  >>
  >>Has anyone had the below in Application event log
  >>and
  >>know a fix for issue? I found a bug id that matches
  >>on
  >>this (CSCeg37424) but the workaround is not working.
  >>
  >>The InsertCDR detailed trace is turned on and the
  >>error happens at 12:24am and the entry in trace file
  >>is at 12:34am saying 10 minute timeout occurred.
  >>Nothing in trace between 12:24 and 12:34.
  >>
  >>Issue was found in CCM 4.0(1)ES 17.1 and marked as
  >>unreproducable.  This is on Call Manager
  >>4.0(2a)Sr1a.
  >>
  >>Workaround from bug id is to kill the insertcdr
  >>process using c:\utils\kill command then restart the
  >>CDR insert service.
  >>
  >>These errors are occuring at 12:24am and 1:24am
  >>nightly like clockwork. Not during day and CDR is
  >>working fine. BARS runs earlier before midnight.
  >>There
  >>are no CDR flat files in the CDR folder either. They
  >>show up briefly then get inserted and deleted. We
  >>have
  >>a few files in the bad folder but not from this time
  >>period. Maybe 1-2 bad cdr flat files a day.
  >>
  >>
  >>Event Type: Error
  >>Event Source: Cisco Database Layer Monitor
  >>Event Category: None
  >>Event ID: 3
  >>Date: 5/18/2005
  >>Time: 1:24:32 AM
  >>User: N/A
  >>Computer: CCM1
  >>Description:
  >>Error: kErrorCDRFilesBackingUp - CDR flat files are
  >>backing up.
  >>  App ID: Cisco Database Layer Monitor
  >>  Cluster ID: CCM1-Cluster
  >>  Node ID: 172.16.2.20
  >>Explanation: CDR flat files are not being removed. 
  >>On
  >>the primary CDR
  >>server, verify that the InsertCDR service is running
  >>and properly
  >>configured. On a server not the primary, verify that
  >>the location for
  >>collecting CDR files is accessible via the network.
  >>Recommended Action: Set trace for InsertCDR service
  >>to
  >>detailed and
  >>look
  >>for errors in the trace.  Check enterprise CDR
  >>parameters for
  >>accuracy..
  >>
  >>
  >>
  >>
  >>__________________________________
  >>Yahoo! Mail Mobile
  >>Take Yahoo! Mail with you! Check email on your
  >>mobile phone.
  >>http://mobile.yahoo.com/learn/mail
  >>_______________________________________________
  >>cisco-voip mailing list
  >>cisco-voip at puck.nether.net
  >>https://puck.nether.net/mailman/listinfo/cisco-voip
  >>
  >>
  >>    
  >>
  >
  >
  > 
  >Yahoo! Mail
  >Stay connected, organized, and protected. Take the tour:
  >http://tour.mail.yahoo.com/mailtour.html
  >  
  >


  ------------------------------

  Message: 4
  Date: Sun, 22 May 2005 21:14:48 -0400
  From: Wes Sisk <wsisk at cisco.com>
  Subject: Re: [cisco-voip] 3rd Party Voice Mail Cluster using Hunt
  Groups and CTI Route Points - Attendant Console
  To: Paul Yago <pyago at adomo.com>
  Cc: cisco-voip at puck.nether.net
  Message-ID: <42912E88.6090409 at cisco.com>
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  So you need to load balance / round robin over CTI Route Points.  If 
  you're already in the CTI business, how about a small application script 
  to round robin between them?  This is very easy with Cisco CRS.

  Though i'm not certain why Attendant Console Hunt Groups would not work 
  for this.  It is valid (and works) to make an AC Pilot Point (which is 
  really just a CTI Route Point) A member of another AC Hunt Group.  
  You're certain the AC Huntgroup was functaional otherwise?  It has be 
  associated to the AC user, TCD has to be running, etc.

  /Wes

  Paul Yago wrote:

  >Wes, actually the VMs are interfacing directly to a CTI Route Point. A
  >CTI Port is not being used by the VM.
  >
  >-----Original Message-----
  >From: Wes Sisk [mailto:wsisk at cisco.com] 
  >Sent: Wednesday, May 18, 2005 1:08 PM
  >To: Paul Yago
  >Cc: cisco-voip at puck.nether.net
  >Subject: Re: [cisco-voip] 3rd Party Voice Mail Cluster using Hunt Groups
  >and CTI Route Points - Attendant Console
  >
  >Paul,
  >
  >do your vm systems pickup calls directly from cti ports? or do they 
  >depend on redirects from CTI Route Point down to CTI port?
  >
  >/Wes
  >
  >Paul Yago wrote:
  >
  >  
  >
  >>Wes,
  >>
  >>With AC, I believe I will encounter the same limitation when including
  >>CTI Route Point extensions in the Hunt Group. I've tried this once
  >>before but please correct me if I'm wrong. I'm trying this again.
  >>
  >>Thanks
  >>- Paul
  >>
  >>-----Original Message-----
  >>From: Wes Sisk [mailto:wsisk at cisco.com] 
  >>Sent: Wednesday, May 18, 2005 12:46 PM
  >>To: Paul Yago
  >>Cc: cisco-voip at puck.nether.net
  >>Subject: Re: [cisco-voip] 3rd Party Voice Mail Cluster using Hunt
  >>    
  >>
  >Groups
  >  
  >
  >>and CTI Route Points
  >>
  >>I don't have a cti app handy to test with, but you may be able to use 
  >>Attendant Console Pilot Point to frontend your cti ports.
  >>
  >>/Wes
  >>
  >>Paul Yago wrote:
  >>
  >> 
  >>
  >>    
  >>
  >>>Hello,
  >>>
  >>>We're trying to create a 3rd Party Voice Mail Cluster using Line 
  >>>Groups and CTI Route Points.
  >>>
  >>>I'm sure there are other people encountering this issue as well, and I
  >>>   
  >>>
  >>>      
  >>>
  >> 
  >>
  >>    
  >>
  >>>hope there is a work-around. Cisco claims that one doesn't yet exist 
  >>>and that a solution will exist in the future. Personally, I haven't 
  >>>found one yet.
  >>>
  >>>We wish to cluster up to 4 - 3^rd party Voice Mail Servers (VMs) to 
  >>>our 4.1 Call Manager in order to provide both redundancy and dynamic 
  >>>load balancing. The initial attempt at this was to create a Line 
  >>>Group, containing CTI Route Point extensions, along with a Hunt List 
  >>>and a Hunt Pilot. The Hunt pilot would be called and one of the 
  >>>members of the LG would be accessed based a distribution algorithm. 
  >>>This didn't work because the members of an LG can only be phone 
  >>>extensions, rather than CTI extensions.
  >>>
  >>>The next attempt was to use a phone extension and configure it to 
  >>>provided forwarding to the CTI extension. Again this failed because 
  >>>all forwarding is disabled for an extension that resides in an LG. 
  >>>Perhaps there is a way to enable forwarding of extensions when they 
  >>>reside in an LG; however I have not yet found it.
  >>>
  >>>Is anyone familiar with this situation and with a solution that can be
  >>>   
  >>>
  >>>      
  >>>
  >> 
  >>
  >>    
  >>
  >>>applied within the Call Manager itself?
  >>>
  >>>Regards,
  >>>
  >>>Paul
  >>>
  >>>----------------------------------------------------------------------
  >>>      
  >>>
  >-
  >  
  >
  >>>   
  >>>
  >>>      
  >>>
  >>-
  >> 
  >>
  >>    
  >>
  >>>_______________________________________________
  >>>cisco-voip mailing list
  >>>cisco-voip at puck.nether.net
  >>>https://puck.nether.net/mailman/listinfo/cisco-voip
  >>>
  >>>
  >>>   
  >>>
  >>>      
  >>>


  ------------------------------

  Message: 5
  Date: Mon, 23 May 2005 07:39:52 -0700 (PDT)
  From: Erick Bergquist <erickbe at yahoo.com>
  Subject: Re: [cisco-voip] kErrorCDRFilesBackingUp - CDR flat files are
  backingup.
  To: Wes Sisk <wsisk at cisco.com>
  Cc: cisco-voip at puck.nether.net
  Message-ID: <20050523143952.52335.qmail at web41129.mail.yahoo.com>
  Content-Type: text/plain; charset=us-ascii

  Wes,

  I'm going to go ahead and open a TAC Case on this. Now
  the error is happening at 5:23am instead of 12:24am so
  must be some thing with the database layer monitor
  maint causing this error.

  --- Wes Sisk <wsisk at cisco.com> wrote:

  > Open a TAC case for this CU and we can open a bug
  > for more formal 
  > investiation and broad sweeping fix.
  > 
  > check the steps of the job.  last i checked it
  > optimized the ccm and cdr 
  > databases.  that includes rebuilding indexes which
  > would affect the 
  > accessibility of those db's for operations.
  > 
  > /Wes
  > 
  > Erick Bergquist wrote:
  > 
  > >Ok, Looks like adjusting time of database layer
  > >monitor job to run from 5am to 7am got rid of the
  > >error. I moved the time back and the error came
  > back
  > >just to make sure it wasn't something else.
  > >
  > >So, my question is, how come the default times for
  > >these jobs conflict with other SQL jobs being done
  > by
  > >other applications?
  > >
  > >Database layer monitor default setting is 12am to
  > 2am
  > >CDR load default time is 12am to 5am
  > >
  > >Seems like issues may happen like this customer had
  > if
  > >you are loading and purging at same time by two
  > >different processes. 
  > >
  > >I did not change the time of the CIPT SQL
  > Optimization
  > >yet. Does this job touch the CDR database or just
  > CCM
  > >database?
  > >
  > >Thanks,
  > >Erick
  > >
  > >--- Wes Sisk <wsisk at cisco.com> wrote:
  > >  
  > >
  > >>Check the cdr insert log around that time. Looks
  > >>like SQL may be dropping
  > >>offline or too busy to process the cdr insert
  > >>request.  could be the service
  > >>stopping i guess.  make sure the PID does not
  > change
  > >>day to day for
  > >>cdrinsert.  any change would reflect a crash or
  > >>service restart for some
  > >>reason.  check the SQL server logs around that
  > time
  > >>and see if it reported
  > >>any events.
  > >>
  > >>this may be due to the IPT optimization job
  > running,
  > >>or the CDR purge
  > >>process running.  the 1st is a job in sql - when
  > is
  > >>it scheduled to run?
  > >>The 2nd is done by database layer monitor and
  > timing
  > >>is set by the dblm
  > >>service parameters.  what time is it set to run?
  > >>
  > >>on that same line the ART cdr purge could cause
  > the
  > >>same issue.  is ART/CAR
  > >>configured to purge the CDR database and if so,
  > what
  > >>time?
  > >>
  > >>/Wes
  > >>
  > >>-----Original Message-----
  > >>From: cisco-voip-bounces at puck.nether.net
  > >>[mailto:cisco-voip-bounces at puck.nether.net]On
  > Behalf
  > >>Of Erick Bergquist
  > >>Sent: Thursday, May 19, 2005 10:16 PM
  > >>To: cisco-voip at puck.nether.net
  > >>Subject: [cisco-voip] kErrorCDRFilesBackingUp -
  > CDR
  > >>flat files are
  > >>backingup.
  > >>
  > >>
  > >>Hi,
  > >>
  > >>Has anyone had the below in Application event log
  > >>and
  > >>know a fix for issue? I found a bug id that
  > matches
  > >>on
  > >>this (CSCeg37424) but the workaround is not
  > working.
  > >>
  > >>The InsertCDR detailed trace is turned on and the
  > >>error happens at 12:24am and the entry in trace
  > file
  > >>is at 12:34am saying 10 minute timeout occurred.
  > >>Nothing in trace between 12:24 and 12:34.
  > >>
  > >>Issue was found in CCM 4.0(1)ES 17.1 and marked as
  > >>unreproducable.  This is on Call Manager
  > >>4.0(2a)Sr1a.
  > >>
  > >>Workaround from bug id is to kill the insertcdr
  > >>process using c:\utils\kill command then restart
  > the
  > >>CDR insert service.
  > >>
  > >>These errors are occuring at 12:24am and 1:24am
  > >>nightly like clockwork. Not during day and CDR is
  > >>working fine. BARS runs earlier before midnight.
  > >>There
  > >>are no CDR flat files in the CDR folder either.
  > They
  > >>show up briefly then get inserted and deleted. We
  > >>have
  > >>a few files in the bad folder but not from this
  > time
  > >>period. Maybe 1-2 bad cdr flat files a day.
  > >>
  > >>
  > >>Event Type: Error
  > >>Event Source: Cisco Database Layer Monitor
  > >>Event Category: None
  > >>Event ID: 3
  > >>Date: 5/18/2005
  > >>Time: 1:24:32 AM
  > >>User: N/A
  > >>Computer: CCM1
  > >>Description:
  > >>Error: kErrorCDRFilesBackingUp - CDR flat files
  > are
  > >>backing up.
  > >>  App ID: Cisco Database Layer Monitor
  > >>  Cluster ID: CCM1-Cluster
  > >>  Node ID: 172.16.2.20
  > >>Explanation: CDR flat files are not being removed.
  > 
  > >>On
  > >>the primary CDR
  > >>server, verify that the InsertCDR service is
  > running
  > >>and properly
  > >>configured. On a server not the primary, verify
  > that
  > >>the location for
  > >>collecting CDR files is accessible via the
  > network.
  > >>Recommended Action: Set trace for InsertCDR
  > service
  > >>to
  > >>detailed and
  > >>look
  > >>for errors in the trace.  Check enterprise CDR
  > >>parameters for
  > >>accuracy..
  > >>
  > >>
  > >>
  > >>
  > >>__________________________________
  > >>Yahoo! Mail Mobile
  > >>Take Yahoo! Mail with you! Check email on your
  > >>mobile phone.
  > >>http://mobile.yahoo.com/learn/mail
  > >>_______________________________________________
  > >>cisco-voip mailing list
  > >>cisco-voip at puck.nether.net
  >
  >>https://puck.nether.net/mailman/listinfo/cisco-voip
  > >>
  > >>
  > >>    
  > >>
  > >
  > >
  > > 
  > >Yahoo! Mail
  > >Stay connected, organized, and protected. Take the
  > tour:
  > >http://tour.mail.yahoo.com/mailtour.html
  > >  
  > >
  > 




  __________________________________ 
  Yahoo! Mail Mobile 
  Take Yahoo! Mail with you! Check email on your mobile phone. 
  http://mobile.yahoo.com/learn/mail 


  ------------------------------

  Message: 6
  Date: Mon, 23 May 2005 10:41:40 -0500
  From: Eric Helm <helmwork at ruraltel.net>
  Subject: [cisco-voip] VoIP qualification and monitoring
  To: voiss-users at osmon.net, cisco-voip at puck.nether.net
  Message-ID: <4291F9B4.9070100 at ruraltel.net>
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  I've been looking at some products for 'pre-qualifying' customer 
  networks for QOS/VoIP and for analyzing and monitoring our VoIP 
  infrastructure.
  Protocols used are SIP, MGCP and SCCP.
  Codecs used are g.711 and g.729a.

  Some of the vendors for VoIP monitoring and analysis that have come up 
  include Acterna, Artiza, Clear Sight, Empirix, Finisar, Fluke, Network 
  Associates, Radcom, Voila and Wildpackets.

  Some of these vendors and Ixia have come up for QOS and VoIP qualification.

  Anyone have any recommendations/experience with any of the above 
  product(s) or other suggestions for my requirements?

  /Eric


  ------------------------------

  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip


  End of cisco-voip Digest, Vol 27, Issue 68
  ******************************************
  ---



  James D. Grace 
  MCSE MCDBA CCNA CCNP CQS
  Sr. System Engineer 
  _______________________________________________
  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/20050523/8b4f6fa4/attachment-0001.html


More information about the cisco-voip mailing list