[SIPForum-discussion] RTCP Call Quality Monitoring

Gast, Jim jim.gast at tdstelecom.com
Fri Jun 6 16:43:43 UTC 2014


Hi, Jorge –

Other people in this forum have more experience with voice quality monitoring than I have.  Packet losses are NOT evil.  Packet losses tell both the sender and the receiver how much quality they can get.  Do not try to minimize packet losses.  Instead, try to meet a target MOS score.  But do not try to compare MOS scores between different codecs.

I will state my feelings and I am very curious to hear other people’s experiences:

-          MOS scores are OK for G.711, but statistical MOS scores seem to understate the quality of Wide-Band codecs.

o   Devices use statistical MOS scores and assume that packet losses, bad jitter, and high latency will have a particular quantitative impact on what a human would perceive as quality.  This is somewhat appropriate in G.711, but the statistical “MOS” scores for Wide-Band codecs like G.722 and G.722.2 (AMR-WB) make them appear worse than what my ear hears.  In my opinion, any of the Wide-Band codecs is much clearer than any of the Narrow-Band (e.g. G.711 or G.729) codecs.

-          Sophisticated techniques for compression and for hiding packet loss

o   With Wide-Band codecs it is much easier to hear emotion and to tell who (if there are multiple speakers) is talking.  Again, the MOS scores given by any of the statistical techniques understate what my ear hears.

o   Modern codecs do a much better job of hiding packet losses than the old codecs.

o   Modern codecs use a bigger maximum jitter buffer and are more flexible about growing and shrinking the jitter buffer.  This smooths over any bursty problems that lower the statistical MOS score inappropriately.

-          Try to avoid old codecs whose main goal was low-bitrate

o   Do not use G.729 if you have any hope of recognizing tones used by devices like ATM machines, elevator phones, FAXes, etc.

-          Statistical MOS scores are inappropriately high when there is transcoding (e.g. G.711->TDM->G.711) along the path from talker to listener.

o   The statistical MOS score is only measuring the last hop.  The last hop may have absolutely perfect statistics, but the quality was lost long before that hop.

G.711 was ratified in 1972.  Audio codecs have come a long way since then.

Take statistics.  Use statistics.  But don’t fool yourself into believing them blindly.

Just my 2 cents worth,

/ Jim


From: Jorge Montesino [mailto:jmmo1981 at gmail.com]
Sent: Thursday, June 05, 2014 3:50 PM
To: Gast, Jim
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] RTCP Call Quality Monitoring

Dear Jim,

Thanks for the information, i will check with the platform provider. In your opinion how accurate is RTCP monitoring with the real quality of the  calls and have you heard about http://www.voipmonitor.org/ ?

Thanks a lot

2014-06-04 9:17 GMT-06:00 Gast, Jim <jim.gast at tdstelecom.com<mailto:jim.gast at tdstelecom.com>>:
Hi, Jorge –

Re:

Make sure your media server supports RTCP/XR (RFC-3611 at http://tools.ietf.org/html/rfc3611).  Those are the Extended Reporting packets that contain information like the number of packets, the number of lost packets and (see http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-qoe-17) the MOS score.  Look at the Statistics Summary Report Block for jitter information, too.  Use Wireshark to see what is available from your media server.  See also RFC-6792, http://tools.ietf.org/html/rfc6792.

Cheers,

/ Jim

From: discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org> [mailto:discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>] On Behalf Of Jorge Montesino
Sent: Tuesday, June 03, 2014 4:28 PM
To: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: [SIPForum-discussion] RTCP Call Quality Monitoring

Dear All,

I would like to know if you can recommend me an opensource platform or any other good for the price that i could use to gather RTCP packets information in order to monitor voip call quality. We do not proxy the calls (no RTP will be gather by the platform) in order to optimized bandwidth usage. We plan to do this installing the recommended platform in a standalone server and then configure a restricted SSH user into the media servers and capture the information by TCPDUMP permanent filter.

Please let me know if you have any recommendation.

Thanks a lot

Jorge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140606/0f42bbe4/attachment-0002.html>


More information about the discussion mailing list