[cisco-voip] Re: cisco-voip Digest, Vol 27, Issue 68
James Grace BB
jgrace at digitelusa.net
Mon May 23 12:50:24 EDT 2005
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
More information about the cisco-voip
mailing list