For those of you who do not know G.107 - the full title of the ITU recommendation is The E-model, a computational model for use in transmission planning.

The interesting thing about this recommendation is that is really a way of computing the Mean Opinion Score for a telephone conversation.

A short introduction to MOS:

MOS is a way of expressing the perceived quality of a telephone conversation. The scale goes from 1 to 5, where 1 is a really bad quality and 5 is excellent. Originally MOS was found (I'd rather not say "computed" by hand) by having a panel of users listening to sound stream and compare the stream to a base line (i.e. MOS = 5). The users would then give the stream a score, and then the mean value all the scores would be computed.

There are companies out there that will charge money to automatically compute the MOS for your service. In fact - the automated MOS business is serious money. I will not name any businesses in this blog entry, but yearly fee of USD 1 000,- is not unheard of. Don't get me wrong - these tools are well polished and very slick. At my previous job I was in charge of deploying such tools so that our prospective clients could see if their network was up for VoIP services. It did save us a lot of headache with regards to customer complaints.

In our current company, Azuralis, we do hosted solutions on behalf of service providers. Often these providers just use a SIP trunk to our infrastructure. In certain cases we also deliver the connectivity to the telephone networks. Given our status as a start up I was not quite ready to shell out USD 1 000,- for such tools. I'd rather implement it my self - and in the process perhaps create a hosted solution for other to use. Such hosted solutions exist for the North American market, but they are only half-usable for our European customers.

During the last few days I took a closer look at the G.107 recommendation, did some background research, and concluded that implementing G.107 for surveillance use was doable. G.107 goes into great details with regards to all the parameters needed to do "proper" MOS on end-point equipment. Very good if you need to check out end-point equipment - but not very usable for network surveillance.

Given the key components of network health is latency, jitter and packet loss and that these values are ready to put into the formulas for G.107 it became more a engineering task than a programming task to create the first proof of concept.

Right now I have a command line tool that will report the MOS between myself and a given server. Next step is to automate checking any number of servers, put the data into a database and provide some nice graphs with the aid of RRD. We will the be able to provide all our customers data on how their connection to our infrastructure is performing. A logical step is then to open the solution to anyone who need to check out their MOS between to network points.

Doing a simple computation of a MOS between two network points is really not rocket science. However, if I had USD 1 000,- to spare I would probably not implement this myself even if it is quite fun work.