[Asterisk-Users] MOS Scores and LCR

[Steve Underwood]

trixter aka Bret McDanel wrote:

>On Sat, 2006-06-17 at 10:16 +0200, Florian Overkamp wrote:
>  
>
>>There are ways to guesstimate MOS scores on a call by continuously 
>>getting some decent statistics from the jitterbuffer. We've had an 
>>intern do some work on this using IAXclient.
>>
>>http://www.speakup.nl/en/opensource/jitterbuffer/
>>    
>>
>
>yes and I suggested that however, MOS is an opinion, so its totally
>subjective and not based on anything 'real'.  That was kinda my point
>earlier.  Personally I think that its better to isolate the network/cpu
>issues and correct them to get what a given implementation of a codec is
>supposed to be rated at (ideally the two would be intertwined).  
>  
>
Calling MOS totally subjective is rather strange. Telephony only has to 
meet subjective goals. In reality, MOS is pretty objective, as it is a 
carefully controlled experiment across enough subjective individuals to 
filter out a reasonably objective answer.

>By looking at the jitterbuffer (assuming you have one, if not you may
>have to get some code that will inspect packets on the network which can
>be done but isnt as easy, its still not that difficult), latency,
>dropped packets, etc and generating stats based off that you can
>probably make a better guestimation of call quality without actually
>listening and then scoring the calls.  
>  
>
Continuous monitoring is, indeed, superior to true MOS testing in the 
dynamic case. Real MOS testing takes months, and the answers might be 
considered a bit late to be useful for any real time purpose.

>The work that you have done so far is a great step towards a product
>that many people might find useful.  In a nutshell the concept I am
>thinking about is a tool that you drop onto your network and it will
>monitor the data (presumably not just iax but sip, h.323, whatever) and
>generate live stats of the call and possibly even have an alarm system
>that would send off a page or something if conditions get too far from
>'normal'.
>  
>
They exist, but current ones cost a fortune. Used with understanding 
they do a fine job. Sadly people who don't understand them tend to read 
far to much into the answers they give. Sometimes they are seriously out 
of line with perceived quality, but they usually do well.

>The approach to wait for customer complaints before reacting to voice
>degradation is likely not going to work for many.  A tool like I
>described, which it seems you are well on your way towards even if that
>wasnt your intention, could add a more proactive approach to it and
>increase reliability and quality for many.
>  
>
As well as established expensive tools, new ones are appearing which are 
more integrated into the VoIP stacks. Have you seen the PIQUA stuff from 
TI? The blurb is so marketing department style its impossible to work 
much that is useful from it. However, this is a scheme to integrate QoS 
(real QoS, and not the oddly named TCP/IP protocol) right into the VoIP 
stack.

>I do not mean to trivialize network management and do understand that
>sometimes problems are outside your control (ie packets on the
>uncontrolled internet may experience problems because of a tertiary
>provider between you and the remote end) and as such this is just one
>peice of the puzzle as I see it.
>  
>
For those reasons may think VoIP will always suck. They might well be right.

Steve