VoIP Codecs

[borstie]

Hallo,
mich interessiert, was all die Codecs, die bei VoIP eingesetzt werden, leisten. Genauer: Wie hoch kann die Verlustrate der IP pakete, mit den darin enthaltenen Sprachdaten, auf dem Weg von einem Endgerät zum anderen sein, damit das gespräch gerade noch als akzeptabel angesehn werden kann. gibt es bei den verschiedenen codecs unterschiede? gibt es da anhaltspunkte? oder tools zum testen? vllt steht ja irgendwo was dazu. aber ich kann leider nix finden
ich hoffe mir kann jmd helfen.

 

[Novize]

Wie hoch kann die Verlustrate der IP pakete, mit den darin enthaltenen Sprachdaten, auf dem Weg von einem Endgerät zum anderen sein, damit das gespräch gerade noch als akzeptabel angesehn werden kann.

Was ist bei Dir gerade noch "akzeptable Sprachqualität"? Ist es knisterndes dumpfes Langewellenradio, ist es eine Autofreisprecheinrichtung im Tunnel bei 200km/h oder erst Audio-DVD im Dolby-Digital-7.1-Mix?
Dann ergibt sich auch noch die Frage, wie lange darf dieser Zustand andauern, ab wann es nicht mehr akzeptabel ist? Wohin die Verbindung geht (und damit, wieviel Geld man damit sparen kann), wäre für mich auch ein K.O.-Kriterium.

Du merkst, diese Frage kann man nicht so einfach beantworten...

 

[alex-911]

hallo

sprachqualität wird in MOS angegeben, aber vorsicht, per definition ist der wert rein subjektiv. guckst du hier:

http://de.wikipedia.org/wiki/Mean_Opinion_Score

ich benutze zum messen analoge messgeräte, die zb PSQM oder PESQ algorithmen verwenden.

in zwei sätzen kann man das thema schlecht beschreiben, aber google wird dir weiterhelfen.

ansätze zur sparachqualität in paketorientierten netzen findest du auch von der ITU spezifiziert, stichworte hier: E-model und R-factor.

viel spass beim schmökern

gruss
/alex

 

[borstie]

Was ist bei Dir gerade noch "akzeptable Sprachqualität"? Ist es knisterndes dumpfes Langewellenradio, ist es eine Autofreisprecheinrichtung im Tunnel bei 200km/h oder erst Audio-DVD im Dolby-Digital-7.1-Mix?
Dann ergibt sich auch noch die Frage, wie lange darf dieser Zustand andauern, ab wann es nicht mehr akzeptabel ist? Wohin die Verbindung geht (und damit, wieviel Geld man damit sparen kann), wäre für mich auch ein K.O.-Kriterium.

Du merkst, diese Frage kann man nicht so einfach beantworten...

also akzeptabel ist fuer mich nicht schlechter als handyqualitaet. und das auf dauer. m;glichst kein knistern etc.wie wohin die verbindung geht. festnetz oder voip fon? das is glaub ich fuer eine allg quali egal. weil ja in beiden faellen der codecs das umsetyen muss. ob nu im endgeraet oder in einem gateway. der codecs muss ja der selbe sein.
geld sparen kommt dann erst in yweiter linie

 

[borstie]

hallo

sprachqualität wird in MOS angegeben, aber vorsicht, per definition ist der wert rein subjektiv. guckst du hier:

http://de.wikipedia.org/wiki/Mean_Opinion_Score

ich benutze zum messen analoge messgeräte, die zb PSQM oder PESQ algorithmen verwenden.

in zwei sätzen kann man das thema schlecht beschreiben, aber google wird dir weiterhelfen.

ansätze zur sparachqualität in paketorientierten netzen findest du auch von der ITU spezifiziert, stichworte hier: E-model und R-factor.

servus
also mir gehts ehr weniger um die allgemeine sprachqualität der codecs, bzw wie sie eingestuft sind. sondern ehr darum, was passiert, wenn bei der übertragung datenpakete verloren gehn. hört man dann einfach in einem wort ne lücke. oder kann der codec auf empfängerseite das in gewissem rahmen ausgleichen? oder fällt es bei kleineren paketen erst gar nicht auf :noidea:

 

[alex-911]

hi

wird auf der empfängerseite PLC (packet loss concealment) unterstützt, kann in gewissen rahmen "die lücke ausgefüllt" werden. basierend auf dem sprachmuster der vorherigen pakete wird "sprache" eingefügt. das klappt aber nur bei relativ geringem packet loss.

soweit wieder zur theorie. genau analysiert hab ich das auch noch nicht. leider...

gruss
/alex

 

[borstie]

[Fullquote entfernt ... supasonic]

oh danke. sowas in der art meinte ich bei wiki steht dazu leider aber nicht viel. wird dann plc vom codec selber oder einem nachgeschaltetem modul übernommen/durchgeführt? gibt es dazu genauere bzw tiefer greifende infos im netz? also nicht das ich nicht suche. aber es könnt ja sein, dass es dafür schon eine spezielle seite gibt

 

[tscoreninja]

Schaust Du hier http://www.itu.int/rec/T-REC-G.711-199909-I!AppI/en

 

[borstie]

Schaust Du hier http://www.itu.int/rec/T-REC-G.711-199909-I!AppI/en

danke. un jetzt das ganze mal, wo es nich tunbedingt geld kostet oder man sich anmelden muss

 

[gandalf94305]

Das ist nicht nur eine Eigenschaft des Codecs, sondern in Kombination mit dem Netzwerk zu sehen.

Manche Codecs mit hoher Kompression sind empfindlich gegen Paketverluste und liefern dann hörbare Aussetzer. Wie unser Handy zeigt, kann man auch über eine dünne Leitung telefonieren, ohne daß man gleich ganz unverständlich wird. Und wie G.711 mit parallelem Bittorrent-Client zeigt, kann man mit einem verlustfreien Codec arbeiten, ohne daß man ein Wort noch am anderen Ende versteht.

Daher ist eher die Frage zu stellen, wie empfindlich Codecs gegenüber Jitter, Loss und anderen Netzwerkstörungen sind. Hier gilt generell und trivialerweise: je kleiner der gestörte bzw. ausfallende Zeitabschnitt ist, desto weniger hört man. Codecs mit hoher Abtastrate und hoher Kompression sind daher anfälliger. Codecs mit geringer Kompression und weniger Millisekunden je Paket sind weniger anfällig. Wenige kurze Aussetzer sind ggf. besser als ein langer.

Das ist alles beliebig schwierig und solange Du keine Kriterien für die Güte definieren kannst, kann man auch keine wirkliche Bewertung abgeben :mrgreen:

--gandalf.

 

[borstie]

Das ist nicht nur eine Eigenschaft des Codecs, sondern in Kombination mit dem Netzwerk zu sehen.

Manche Codecs mit hoher Kompression sind empfindlich gegen Paketverluste und liefern dann hörbare Aussetzer. Wie unser Handy zeigt, kann man auch über eine dünne Leitung telefonieren, ohne daß man gleich ganz unverständlich wird. Und wie G.711 mit parallelem Bittorrent-Client zeigt, kann man mit einem verlustfreien Codec arbeiten, ohne daß man ein Wort noch am anderen Ende versteht.

Daher ist eher die Frage zu stellen, wie empfindlich Codecs gegenüber Jitter, Loss und anderen Netzwerkstörungen sind. Hier gilt generell und trivialerweise: je kleiner der gestörte bzw. ausfallende Zeitabschnitt ist, desto weniger hört man. Codecs mit hoher Abtastrate und hoher Kompression sind daher anfälliger. Codecs mit geringer Kompression und weniger Millisekunden je Paket sind weniger anfällig. Wenige kurze Aussetzer sind ggf. besser als ein langer.

Das ist alles beliebig schwierig und solange Du keine Kriterien für die Güte definieren kannst, kann man auch keine wirkliche Bewertung abgeben :mrgreen:

--gandalf.

meinst du mit kriterien für die güte die allg qualität des codecs? also die mos? prinzipiell sollte der eigentliche codec nicht unter gsm sein.
um jitter etc entgegen zuwirken, ist doch ein puffer im endgerät wünschenswert. dieser ist doch aber unabhängig vom codec.
dieses PLC interpoliert wohl, wird doch aber sicher nicht vom codec selber umgesetzt, oder? also direkten einfluss auf die sprachquali haben doch dann die codecs nur insoweit auf jitter oder loss, als das die sprachschnipsel möglichst klein bzw kurz gehalten sein sollten (hohe abtastrate: je mehr pro sekunde abgetastet wird, umso kürzer sind ja die abschnitte) und die anzahl schnipsel pro ip-paket und die kompression möglichst gering sein sollten. der rest wird dann quasi nicht mehr vom codec gemacht. also z.b. das interpolieren. seh ich das so richtig?
kann man sowas irgendwie testen? also das man gezielt einige pakete verwirft, um zu sehen was passiert? gibts da irgendwas

 

[gandalf94305]

Zunächst mal: bitte keine unnötigen Fullquotes. Du kannst Das Quote komplett löschen, da mein Beitrag ja direkt drüber steht.

meinst du mit kriterien für die güte die allg qualität des codecs? also die mos?

MOS ist nur eine Metrik. Man kann sich auch andere vorstellen.

prinzipiell sollte der eigentliche codec nicht unter gsm sein.

Das ist subjektiv. Ich kann auch Sprache mit 2400 Baud übertragen ;-) Das klingt dann wie im tiefen Keller, aber man kann etwas verstehen.

um jitter etc entgegen zuwirken, ist doch ein puffer im endgerät wünschenswert. dieser ist doch aber unabhängig vom codec.

Ja, aber die Quantelung ist Sache des Codecs und ggf. auch die Frage, wie viele Quanten in ein Paket auf dem Netzwerk gepackt werden. Damit hängt vom Codec ab, wie groß der Puffer sinnvoll sein sollte, denn den Puffer misst man normalerweise in Sprechzeit, nicht Datenvolumen.

[...] seh ich das so richtig?

Das ist korrekt. Aber die Tatsache, daß man möglichst kleine Portionen und möglichst ohne Kompression übertragen sollte, ist ja irgendwie trivial. Wie finden wir nun für die Realität einen guten Kompromiss? Kleine Pakete führen zu großem Overhead, d.h. erfordern mehr Bandbreite. Große Pakete führen bei Loss zu mehr Problemen. Jitter wirkt sich dann ebenso heftiger aus. Hohe Kompression packt mehr "Sprechzeit" in ein Paket, ist also gegen Loss noch empfindlicher, da mehr Sprache ausfällt. Andererseits ist es so möglich, in den kleinen Paketen mehr Nutzdaten unterzubringen, also wäre es besser... Ah, also brauchen wir mittlere Datenpaketgrößen, mittlere Kompression und eine mittelhohe Abtastrate :mrgreen:

Wir haben hier ein mehrdimensionales Optimierungsproblem... Codec und Netzwerk sind relevant. Und die Technik alleine gibt keine Antwort. Bewerten mußt Du es selbst.

--gandalf.

 

[borstie]

Zunächst mal: bitte keine unnötigen Fullquotes. Du kannst Das Quote komplett löschen, da mein Beitrag ja direkt drüber steht.

sorry. mach sowas nich allzu oft

MOS ist nur eine Metrik. Man kann sich auch andere vorstellen.

das war auch nur als anhaltspunkt gedacht, da das ja die meisten kennen.

Ja, aber die Quantelung ist Sache des Codecs und ggf. auch die Frage,

was ist quantelung? ist das die einteilung in die zeitabschnitte?

Wie finden wir nun für die Realität einen guten Kompromiss?

doch ausprobieren
frage ist nur, wie. also wie kann man in einem überschaubarem netz gewisse fehlerquellen simulieren um dann rückschlüsse ziehen zu können

 

[telocho]

MOS wird also benutzt jedenfalls in Projekte wo ich tätig binn (das holländische ptt voip netz)

Darauf kommt noch andere Sachen wie: Silence suppression (comfort noise)

Einige Codec's übertragen keine Stille. Aber dann wird durch die empfänger rauschen eingespeist. Leider sind die meisten ata's nicht in der Lage ein vernüftiger Angriff von Leise zu machen, das heisst soviel wie das die erste Syllabe von jeder Satz fehlt.

Silence suppression (SS) oder comfort noise (CN) mit voice activation detection (vad) ist meistens schaltbar in vielen Codec's, wenn bandbreite kein Problem schalte es aus (nütze es nicht). Dann ist die Sprache erstmals viel natürlicher.

jitter wird erhoben durch grössere Puffer, aber ohne das die delay wieder zu gross wird (muss kleiner als 150 msec).

 

[alex-911]

MOS ist nur eine Metrik. Man kann sich auch andere vorstellen.

vorstellen kann man sich viel. welche andere kenngrösse wird denn zur beurteilung der spachqualität herangezogen?

nach welcher methode man zu diesem wert kommt, steht auf einem anderen blatt...

dieses PLC interpoliert wohl, wird doch aber sicher nicht vom codec selber umgesetzt, oder?

korrekt. das macht der DSP bei der D/A wandlung.

was ist quantelung?

siehe unter quantisierung => Signalverarbeitung => A/D Wandlung

kann man sowas irgendwie testen? also das man gezielt einige pakete verwirft, um zu sehen was passiert? gibts da irgendwas

ja, das gibt es. um PL, jitter und delay zu generieren gibt es netzwerksimulatoren.
um sowas seriös zu testen darfst du aber nicht ausser acht lassen, dass sprachqualität end to end gemessen wird. d.h. vom mikro bis zur ohrmuschel. und dazwischen gibt es noch andere faktoren neben dem IP transport, die die qualität beeinflussen können.

gruss
/alex

 

[telocho]

Übrigens ist MOS zwar subjektief, wirdt aber standardisiert gemessen mit einen "objektiever" Messgerät (und wird dabei verglichen mit eine gleiche Messung an das Referenz - Festnetz mit Analoger Anschluss.

 

[borstie]

ja, das gibt es. um PL, jitter und delay zu generieren gibt es netzwerksimulatoren. um sowas seriös zu testen darfst du aber nicht ausser acht lassen, dass sprachqualität end to end gemessen wird. d.h. vom mikro bis zur ohrmuschel. und dazwischen gibt es noch andere faktoren neben dem IP transport, die die qualität beeinflussen können.

ja das ist leider richtig. aus diesem grund dachte ich, dass man sowas in einem kleinen, extra für den test errichtetem netzwerk durchführen kann mit möglichst wenigen komponenten. also ein server und die entsprechenden clients. da in so einem netz verzögerungen nahezu auszuschließen sind, sollte es für die übertragung keine netzprobleme geben. um einen codec dann zu testen, dachte ich dass man gezielt pakete verwirft, z.b., jedes zehnte oder 20ste. sowas in der art.
muss eigentlich so ein PLC extra implementiert werden? wenn es unabhängig vom codec ist, kann man es doch für alle einsetzen, oder?

 

[alex-911]

hi

wo und womit willst du denn messen?

PLC macht der DSP, da musst du nix iplementieren.

gruss
/alex

 

[borstie]

ja das is ja mehr oder weniger die frage. ich dachte eben, das man eine bestimmbare anzahl pakete sendet, die ein bestimmten text wiedergeben. wo man dann einen teil "unter den tisch" fallen lässt, ist quasi egal. nur muss auf empfängerseite dann die anzahl entsprechen, die gesendet wurde minus der unter den tisch gefallener. und der rest, der beim codec ankommt und wieder hörbar ist, müßte dann mit dem text vom anfang verglichen werden können. so in der art.
und das erstmal ohne berücksichtigung von jitter und latenz, sondern erstmal nur die reine vertretbare verlustrate