FW: Use of RTCP statistics for estimating QoS of VoIP

Alan Clark alan at telchemy.com
Fri Nov 8 15:16:42 EST 2002


For some reason recent messages seem not to be sent by the reflector (?)
hence I am forwarding this directly

Alan


-----Original Message-----
From: Alan Clark [mailto:alan at telchemy.com]
Sent: Friday, November 08, 2002 12:29 PM
To: 'frank.derks at philips.com'
Cc: 'ITU-SG16 at echo.jf.INTEL.COM'
Subject: RE: Use of RTCP statistics for estimating QoS of VoIP



Frank

I did suggest (via Mike Buckley) that the following be added to H.460.9
however don't know if it was actually included.

" It should be noted that RTCP reports were not originally intended to
provide accurate QoS metrics but for informative exchanges between endpoints
to support possible dynamic configuration.  According to RFC1889 (a)
received packet count may include duplicate packets and hence it is possible
to report negative packet loss (b) reported mean packet-to-packet delay
variation (jitter) is averaged over the last 16 received packets and hence
provides information only on the 160-480mS period immediately preceding
transmission of the RTCP report."

I do agree with you that potential implementors may well feel uncomfortable
that the Recommendation in its initial form contains information that has
little or no value.  I am even more concerned that less well informed
implementors may accept what is in the Recommendation as being "sufficient"
and hence attempt to manage VoIP services with metrics that can be quite
misleading.

Regards

Alan


-----Original Message-----
From: frank.derks at philips.com [mailto:frank.derks at philips.com]
Sent: Friday, November 08, 2002 2:46 AM
To: alan at TELCHEMY.COM
Cc: ITU-SG16 at echo.jf.INTEL.COM
Subject: Re: Use of RTCP statistics for estimating QoS of VoIP


Alan,

I certainly agree that, if the main body of the Recommendation covers
metrics
that are of little practical use of the recipient of these metrics, the
Recommendation can be misleading. Only with the proper background
information
will the reader be able to distinguish the real value in the particular
metrics.

I feel somewhat uncomfortable when the main body of a Recommendation
provides
me with something that is of little value, but which can be extended to
include
more useful information.

A possible way "out of this", is to include some text that clearly
explains the
situation and that reflects the concerns that were raised and agreed upon.

Regards,

Frank






More information about the sg16-avd mailing list