[cisco-voip] Perfmon Commands?

[Lelio Fulgenzi]

Cisco CallManager > RegisteredHardwarePhones


  ----- Original Message ----- 
  From: Miller, Steve 
  To: cisco-voip at puck.nether.net 
  Sent: Thursday, March 08, 2007 8:31 PM
  Subject: [cisco-voip] Perfmon Commands?


  Does anyone know what Perfmon command will tell you how many registered
  phones are in your system?  Thank you!


  Steve Miller
  Telecom Engineer
  Dickstein Shapiro LLP
  1825 Eye Street NW | Washington, DC 20006
  Tel (202) 420-3370 Fax (202)-330-5607
  millers at dicksteinshapiro.com 


  -----Original Message-----
  From: cisco-voip-bounces at puck.nether.net
  [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of J. Oquendo
  Sent: Thursday, March 08, 2007 4:57 PM
  To: Patrick Diener; cisco-voip at puck.nether.net
  Subject: Re: [cisco-voip] Jitter Question

  Patrick Diener wrote:
  > bottom line:  jitter level should not be greater than 30 - 35ms...
  > unfortunately on a quick search on cisco.com I could not find any docu

  > to back that value...
  >   
  I don't know where you got the 30-35ms range from so I quote again from
  the DQoS book:

  As per:

  Cisco DQOS Exam Certification Guide
  Wendell Odom and Michael J. Cavanaugh
  Copyright (c) 2004 Cisco Systems, Inc.


  ONE WAY DELAY BUDGET GUIDELINES
  *1-Way Delay (in ms) Description*
  0-150 ITU G.114's recommended acceptable range 0-200 Cisco's recommended
  acceptable range 150-400 ITU G.114's recommended range for degraded
  service
  400+ ITU G.114's range of unacceptable delay in all cases

  Some flows tolerate loss better than others do. For instance, the human
  ear can detect loss of only 10 ms of voice, but the listener can
  generally understand speech with such small loss. Cisco digital signal
  processors (DSPs) can predict the contents of lost voice packets, up to
  30 ms when using the G.729 codec.

  Lost voice packets result in the receiver having a period of silence
  corresponding the length of voice payload inside the lost packet(s).
  With two consecutive
  G.729 packets
  lost, 40 ms of voice is lost; the G.729 codec cannot predict and
  generate replacement signals when more than 30 ms of consecutive voice
  is lost. A single lost
  G.729 packet
  would only cause a 20-ms break in the voice, which could be regenerated.

  So, a single
  lost packet is not perceived as loss in a G.729 call.

  No luck searching through the book on 35 ms or 35ms so I tried 40 ms &
  40ms:

  Page 862
  Instantaneous buffer overrun occurs when a switch port TX queue fills
  for an instant causing packet loss, which can adversely affect real-time
  applications. 
  In a VoIP
  conversation, for example, 40 ms of congestion causes an audible clip in
  the conversation.

  Page 82
  In Figure 1-23, the playout begins at the statically set playout delay
  interval-40 ms in this case-regardless of the arrival time of other
  packets. A 40-ms de-jitter playout delay allows jitter to occur-because
  we all know that jitter happens-so that the played-out voice can
  continue at a constant rate.


  --
  ====================================================
  J. Oquendo
  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
  sil . infiltrated @ net http://www.infiltrated.net 

  The happiness of society is the end of government.
  John Adams


  --------------------------------------------------------
  This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. This communication may contain material protected by attorney-client, work product, or other privileges. If you are not the intended recipient or person responsible for delivering this confidential communication to the intended recipient, you have received this communication in error, and any review, use, dissemination, forwarding, printing, copying, or other distribution of this e-mail message and any attached files is strictly prohibited. Dickstein Shapiro reserves the right to monitor any communication that is created, received, or sent on its network.  If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. 

  To reply to our email administrator directly, send an email to postmaster at dicksteinshapiro.com

  Dickstein Shapiro LLP
  http://www.DicksteinShapiro.com
  ==============================================================================


  _______________________________________________
  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/20070308/7c9406db/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 41727 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-voip/attachments/20070308/7c9406db/attachment-0001.png