[cisco-voip] Perfmon Commands?

[Miller, Steve]

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
==============================================================================