Wer legt den MOS-Wert fest?

[firstclaas]

Hallo,

ich schreibe gerade an einer Arbeit über QoS bei VoIP. Ich führe Messungen der Qualitäts-Parameter in einem Netzwerk durch und werte MOS, R-Faktor, Jitter, Delay, PQSM, usw. aus. Um vergleichen zu können, brauche ich natürlich Referenzwerte. Im Rahmen meiner Recherchen bin ich alleine für den G.711 Codec auf mind. vier verschiedene MOS-Werte gestoßen.
Meine Frage ist nun, wer gibt den MOS-Wert für einen Codec vor? Die ITU-T? Die IETF? oder ist das beliebig? Ich brauche einen Wert auf den ich mich in der Arbeit beziehen kann! In den Standards der ITU-T kann ich keine Vorgaben finden.
je nachdem welches Buch oder welche Internetseite ich wähle schwankt der MOS-Wert für G.711 zwischen 4.1 und 4.5. Das Gleiche gilt auch für andere Codecs und Codierverfahren.
Bei den Werten für den Delay ist es auch so, in einem Buch hat der G.711(PCM) 0.125ms Delay und im nächsten 2ms Delay usw.
Bin für jede Hilfe dankbar!

Gruß

Claas

 

[VOIP-Freak]

Mos

Hallo firstclass,

ich versuche es mal.

Zunächst bezieht sich die Bewertung m. E. nur um einen Vergleich innerhalb der Testreihe. Es gibt da auch einige Vorgaben, wie der Test durchgeführt werden soll. Also sozuso wie lange das Original, dann eine kurze Pause und dann der Probant abgespielt werden soll. Zudem baucht man möglichst viele Tester/Bewerter, um ein aussagekräftiges Ergebnis zu bekommen. Hat man sagen wie mal, eine sehr sehr große Anzahl von geschulten oder ungeschulten "Schiedsrichtern" so können doch noch die örtlichen Gegebenheiten, der Vorführraum, das Material, die technische Ausstattung, das Ergebnis beeinflußen. Der G.711 ist ein Sprachcodec mit 0,125msec Sampleabstand (8kHz). Die Dynamik ist 8 bit logarithmisch, also es gibt eine A-law und eine mu-law Quantizierungskurve. Da könnten auch schon eine Abweichung auftreten. Also ich würde diese Abweichungen zunächst nicht überbewerten. Es werden manchmal auch verschiedene Sprachen benutzt und man nimmt eine femminine oder maskuline Stimme. Die Abweichung beträgt so um die 10%. Es handelt sich auch nicht um ein Meßgerät. Ich habe nur eine Untersuchung, da bringt es der GSM(Handy-> nicht UMTS)) EnhancedFullRateCodec mit 12,2 kbps so auf 4,31. Es werden dort auch verschiedene Experimente aufgeführt. European, Japanese, also die fanden in auch in verschiedenen Ländern statt, sodaß m. E. dieser Wert auch, wie gesagt, nur eng begrenzt innerhalb eines Testes, betrachtet werden kann.

Schönen Feiertag

 

[rollo]

Der MOS Wert wird mittlerweile auch Messtechnisch erfasst also nicht wie bisher mit Probanden.
Eine Google Recherche dazu dürfte einige an Infos bringen. Wikipedia wäre auch noch ein Tipp.

jo

 

[VOIP-Freak]

Der meßtechnische MOS

Hallo rollo,

danke für den Hinweis. Nur als Anmerkung, es stellt sich auch die Frage, wie solche Meßinstrumente dann kalibriert werden, eine Eichung, also von staatlicher Seite aus, wird es da sowieso nicht geben? Ich jedenfalls, kenne da keine Festlegung, Verfahren. Sofern man nur einen Hersteller hat, ist man da erst einmal aus dem Schneider. Die Anderen müssen sich dann danach richten?

Ebenso einen schönen Feiertag

 

[spongebob]

Schau mal hier:
http://davidwall.com/MOSCalc.htm`

Ich habe vor kurzem mal an sowas mitgebaut: Ein WebServer, der "Messpläne" vorhält. Verschiedene Barebone-basierte Linux-Clients, die sich per Webservice am Server ihren Plan abholen und dann SIP/VoIP Verbindungen zu einem Linux-MessServer aufbauen. Während der Verbindung messen beide Seiten RTT, Jitter und Packet Loss über G.711. Die Ergebnisse wurden vom Client am Ende upgeloadet. Ist nie so richtig ein Produkt geworden, sondern von einem studentischen Praktikanten sozusagen unter meiner Anleitung umgesetzt worden, mehr so als Proof of Concept. Ziel der Übung war es, zu prüfen, ob man autarke Units für Telkos bauen kann, die diese für eine begrenzte Zeit an "Problemkunden" aushändigen zu können, um festzustellen, ob SIP oder weiteergehend RTP Verbindungen jeder Art über die aktuell vorliegende Leitung überhaupt funktionieren.

Meiner Meinung nach reicht die Messung der 3 o.g. Parameter vollkommen aus für die Beurteilung der Leitungsqualität und für die Ableitung des MOS anhand der o.g. Kalkulation. Hinzu kommen über die o.g. Parameter nicht messbare Codec-Einflüsse. Und sie fallen in einem guten SIP Stack sozusagen nebenbei ab (s.a. RTCP)

Grüsse

 

[VOIP-Freak]

Hallo zusammen,

danke für die intensive Diskussion. Die G.113 Appendix I, das E-Modell, sagt mir was. Der eingangs erwähnte Codec G.711 verfügt, sofern er dem Annex I entspricht, angeblich über ein Error Concealment. Das soll packet loss in einem gewissen Maße ausgleichen. Allerdings in welchem Umfang kann ich nicht sagen. Ich kann also nicht feststellen, ob dies bei dem angegebenen URL berücksichtigt ist.

Vielleicht hat jemand eine Idee, wo man den Annex I der G.711 findet, so um die 3 Prozent so er m. Erinners bringen.

Gute Nacht:grab:

 

[spongebob]

Der eingangs erwähnte Codec G.711 verfügt, sofern er dem Annex I entspricht, angeblich über ein Error Concealment. Das soll packet loss in einem gewissen Maße ausgleichen.

Aber nicht G.711. Da ist Loss = Loss. G.711 ist (wie oben schon erwähnt) eine schlichte Abbildung linearer PCM Samples an einer nichtlinearen Kennlinie zur Unterdrückung des Quantisierungsrauschens. Es gibt keine Prediction, d.h. aus der Vorgeschichte ist nicht der mögliche Nachfolger zu ermitteln, der - im Falle des Verlustes - emuliert werden könnte. Weg ist weg. In diesem Sinne ist G.711 ähnlich loss-resistent, wie lineares PCM (also z.B. das normale Windows WAV Format) - nämlich gar nicht

Grüsse

 

[VOIP-Freak]

G.711 Annex I

Hallo spongebob,

vielen Dank für Deinen Hinweis. Genau sagen, wie die Verfahrensweise funktioniert, kann ich Dir nicht. Jedenfalls scheint es die Empfehlung der ITU-I zu geben.

Schau einfach mal unter http://www.aktiv-verzeichnis.de/anlagen/579/tip-dtpdf nach.

Dort steht u. A. :
TIP mit G.711 (uLaw, aLaw) Vocoder:
- G.711 Annex I (PLC: Packet Loss Concealment)
- G.711 Annex II (VAD/CNG Format: Voice Activity
Detection / Comfort Noise Generation)
- G.168 Echo Cancellation (16 msec Near End)

Also wie man dies genau macht, ob man vielleicht zwischen dem Vorgänger und den Nachfolger mittelt, und so vielleicht etwas, ein Sample oder Paket rekonstruiert oder die Paketgröße anpaßt, kann ich zumindest im Moment nicht sagen.:noidea: Das (Mach)Werk habe ich nicht vorliegen. Inwieweit das Signalisierungsrelevant ist (RFC4566) kann ich auch nicht sagen.:noidea: Das Eine hängt m. E. mit dem Anderen zusammen.

Ein MOS-Wert für G.711 gibt es auch noch:
MOS
G.711 PCM-uLaw: 64,0 4,2
G.711 PCM-aLaw: 64,0 4,2
G.726 ADPCM: 16,0 3,2
G.726 ADPCM: 24,0 3,2
G.726 ADPCM: 32,0 3,7
G.726 ADPCM: 40,0 4,0
G.729 A,B CS-ACELP: 8,0 4,0
G.729 E CS-ACELP: 11,8 4,1
Vermutlich ohne Delay, Jitter, Packet Loss und so`n Zeugs. Wie der sonst zustande gekommen ist?:noidea:

Have a great day

 

[firstclaas]

Hallo,

danke für die vielen Antworten!

Ich habe meine VoIP Bibel nochmals zu Rate gezogen(die von Anatol Badach) . Dort sind MOS-Werte von bis angegeben, also nicht nur ein Wert pro Codierverfahren, sonder halt von bis Werte.
Ich gehe daher echt mal davon aus, dass ein Codec je nach Umstand einer Messung einen etwas anderen MOS-Wert hat.
Im ITU-T Standard P.862 (PESQ) ist ein Verfahren definiert, mit welchem MOS-Werte bei VoIP automatisiert ermittelt werden können. Ich glaube, ich möchte gar nicht wissen WIE GENAU das geht, hauptsache es geht!
Ich weiss nur, daß in diese Berechnung mehrer Faktoren einfließen, und so einen Hörtest simuliert wird.

Ich werde mich im laufe meiner Messreihen dann auf die ca. Werte beziehen und mich darauf berufen, dass PCM einen MOS-Wert zwischen 4,3 und 4,5 haben kann, bei den anderen Verfahren gilt ja das Gleiche.

Gruß
Claas

 

[spongebob]

Gefunden: http://netzikon.net/lexikon/p/packet-loss-concealment.html

Packet Loss Concealment wird bei der digitalen Sprachübertragung eingesetzt. PLC ist in der Lage, kurzzeitige Aussetzer im Datenstrom zu überbrücken. Je nach genutztem Verfahren wird einfach der letzte übertragene Ton gehalten, Stille eingespielt oder es wird versucht den Ton zu berechnen.

"Halten des letzten Tons oder Stille einspielen" - das wird's sein Sicher ist es auch möglich, aus dem bisherigen Spektrum bei der Dekompandierung der G.711 Samples den höchstwahrscheinlichen Weiterverlauf der Hüllkurve und damit die ggf. fehlenden Samples zu ermitteln. Aber das macht doch in der Praxis kein Mensch... Zumindest nicht für G.711, wäre mir neu. Bei anderen Codecs durchaus.

Ich werde mich im laufe meiner Messreihen dann auf die ca. Werte beziehen und mich darauf berufen, dass PCM einen MOS-Wert zwischen 4,3 und 4,5 haben kann, bei den anderen Verfahren gilt ja das Gleiche.

Da liegst Du richtig. Alles über 4 ist vollkommen OK.

Grüsse

 

[VOIP-Freak]

PLC im Detail

Hallo spongebob,

vielen Dank für Deinen Einwand.

Gnerell gilt, Du hast auch nicht anderes behauptet:
"The objective of PLC is to generate a synthetic speech signal to cover missing data (erasures) in a received bit stream."

Allerdings, jetzt kommt es:
"The G.711-encoded audio data is sampled at 8 kHz. In this appendix it is assumed to be partitioned into 10 ms frames (80 samples). By adjusting a few parameters, other packet sizes or sampling rates can be accommodated."
Wer also will, kann das Ganze anpassen.

Also normalerweise kenne ich nur 20 bis 30 ms PacketSize for VoIP. Ansonsten wird der Overhead vermutlich zu groß.

"The output is delayed by 3.75 ms (30 samples) before it sent to the audio port."

Die Methode verursacht ein Additional Delay, was vermutlich größer ist, wenn ein längerer Packet Loss berücksichtigt werden soll.

Zudem dreht man zur Überbrückung von Fehlern an dem Pitch, kopiert Frames und hat auch einen entsprechenden Buffer dafür vorgesehen:
"While repeating a singl (vermutlich Frames). If the next frame is also erased, the erasure will be at least 20 ms long and further action is required. The pitch period works well for short erasures (e.g. 10 ms),.."

Kennt man den PacketSize, kann man sich ja gleich danach richten!!!

"and at 20 ms a third pitch period is added. For erasures longer than 20 ms no additional modifications to the pitch buffer are made."

Man dreht offensichtlich (auch) an der WiedergabeGeschwindigkeit (Pitch), ohne die Tonhöhe, den Klang der Sprache zu tangieren.

Das Ganze ist nicht relevant für die Signalisierung im Session Description Protocol. Es tangiert nur den Decoder.

Viel wichtiger ist allerdings, hat die fritz.box (Fon) einen solchen Decoder?

Guten Abend
VoIP-Freak:grab: