messungen im lan

[123meins 10]

Hi

 

ich bins schon wieder ^^.

 

und zwar suche ich ein oder mehrere kostenlose (oder shareware) tools, mit dem ich in einem schon vorhandenen lan, dinge wie delay, jitter, packet loss für rtp pakete (im hinblick auf voip) einfach messen kann.

einfach in dem hinblick, das ich vielleicht ne grafische oberfläche habe und wo ich nicht noch irgendwelche skripte selbst erstellen muss, damit ich ne grafische auswertung kriege.

(vllt. kann ich hier mal prtg als richtungsweisend nennen, da ich wirklich nicht der konsolenspezi bin)

falls es sowas natürlich nicht gibt, auch nicht schlimm, hauptsache tipps ^^.

 

wie gesagt, stink normales lan, noch kein voip komponenten (telefone, anlage, etc) integriert. soll einfach nur mal dargestellt werden, wie die qualy denn wäre, wenn von heut auf morgen plötzlich voip integriert werden würde, und ob sich der normale traffic eines arbeitstages sehr negativ auswirken würde.

 

hab auf den clients nur xp zu verfügung, also kein linux, unix oder bsd.

 

hab zwar schon mal die liste mit tools hier gefunden gehabt, nur beinhalteten die nicht wirklich das was ich suche.

 

danke schon mal.

[acidfinger 10]

was hälst du von Wiresharck?

 

Gruss

 

Acid

[daking 10]

Hola,

 

..:: vs ::.. [Volker Semken].

 

Ciao

[weg5st0 10]

Und wer davon kann Aussagen über Delay, Jitter und ähnliche Variablen treffenb, die man übersichtlich sieht (in einem RTP Stream im Wireshark wohl kaum)....

 

Wende dich an den TK-Anlagen Lieferanten. Der hat sicher Tools für sowas.

 

Im Normalfall werden hier Agenten aufgestellt, die über einen gewissen Zeitraum die Verbindungsqualität prüfen und eine Verlässliche Aussage über die Sprachqualität bieten.

 

Was willst du denn aus einer Aussage wie "Ich habe 5 % Packet Loss bei RTP Streaming" für einen Schluss hinsichtlich der zu erwartenden Sprachqualität machen.

[daking 10]

Hallo,

 

Und wer davon kann Aussagen über Delay, Jitter und ähnliche Variablen treffenb, die man übersichtlich sieht (in einem RTP Stream im Wireshark wohl kaum)....

 

==> Falsch

==> Außer Jitter ist mit Wireshark alles (Delay, Pkt Loss) sehr gut zu analysieren.

 

Was willst du denn aus einer Aussage wie "Ich habe 5 % Packet Loss bei RTP Streaming" für einen Schluss hinsichtlich der zu erwartenden Sprachqualität machen

 

==> Ist eigenltich sehr einfach. Nach ITU P.800 / P.862 oder ITU G.107 Rec sollte der Paketverlust kleiner als 1% sein. Die Sprachqualität wird somit keine Toll-Quality erreichen.

Nebeneffeckte wir abgehackte, oder leise Spracheverbindungen (bei Bad Frame Interpolation) sind zu erwarten.

 

Falls du eine optimale Messung haben willst, benutze NetiQ Chariot!

 

Ciao

[daking 10]

Hola,

 

@123meins:

 

für solche Messungen (Audit VoIP) solltest du dann doch die Profis antreten lassen (;-).

 

Ciao

[weg5st0 10]

Ist eigenltich sehr einfach. Nach ITU P.800 / P.862 oder ITU G.107 Rec sollte der Paketverlust kleiner als 1% sein. Die Sprachqualität wird somit keine Toll-Quality erreichen.

Nebeneffeckte wir abgehackte, oder leise Spracheverbindungen (bei Bad Frame Interpolation) sind zu erwarten.

 

Aha! und was für eine Sprtachqualität ist denn bei 0,9% Packetloss zu erwarten? ISDN-Qualität, Analog, HIFI?

Das kannst du doch gar nicht beantworten, anhand einer Messung mit Wireshark. Schon gar nicht ist eine Prognose möglich (mittagszeit alles tolll - morgens um 10 voll b.... nachmittags mittelmässig).

 

Oder kommt da etwa noch der Komprimierungscodec ins Spiel? Macht die VoiP Anlage G709 oder G.723 ....? Und was bedeutet das dann für die o.g. Variablen?

 

für solche Messungen (Audit VoIP) solltest du dann doch die Profis antreten lassen (;-).

 

...Genau!

[daking 10]

Hola,

 

Aha! und was für eine Sprachqualität ist denn bei 0,9% Packetloss zu erwarten? ISDN-Qualität, Analog, HIFI?

Das kannst du doch gar nicht beantworten, anhand einer Messung mit Wireshark.

 

==> ist auch uninteressant, da es bestimmte Grenzwerte gibt um Sprachverbindungen zu bewerten. Interessant wäre hier der MOS der Verbindung der durch die fehlende Jittermessung (RFC 1899 nicht maximum Jitter) nicht berechnet werden kann. Jedoch ist es im Fehlerfall (das Problem ist eingegrenzt) möglich Probleme zu erkennen (PKT Loss, Delay). Auch kann der aufgezeichnete Stream abgespielt werden und mit dem Analystenohr ausgewertet werden. Nach ITU G.107 sollte der PKT Loss kleiner als 1 % sein. In LAN / WAN Umgebungen mit optimierten queueing muss der PKT Loss 0 % ==> wird mit Wireshark PKT Loss gemessen, ist etwas suboptial konfiguriert / designed.

Mit Wireshark + Cooledit können zum Beispiel perfekt Echo Messungen gemacht werden.

Ob das HIFI oder ANALOG ist kann die NetIQ, AVISO.. auch nicht beantworten.

 

Schon gar nicht ist eine Prognose möglich (mittagszeit alles tolll - morgens um 10 voll b.... nachmittags mittelmässig).

 

==> Mag richtig sein, da die Datenmenge sehr groß werden würde. Hier würden sich IP Qos tickets (Alcatel) oder CDR (Cisco) oder... anbieten. Grundsätzlich muss bei derartigen Fehlern ein schlechtes Design zu Grunde liegen. In der Konzeptphase müssen SPQ/LLQ fähige Komponenten ausgewählt werden und die benötigte Bandbreiten für VoIP kalkuliert/definiert werden.

 

Oder kommt da etwa noch der Komprimierungscodec ins Spiel? Macht die VoiP Anlage G729 oder G.723 ....? Und was bedeutet das dann für die o.g. Variablen?

 

==> Bei G.723 geht bei Paketverlust durch das 30 ms Framing mehr Sprachinformation verloren ==> schlechtere Sprachqualität (vielleicht kein Knacken da PLC) Bei G.729 / G.711 mit 20 ms Framing (sollte so eingestellt werden) weniger Informationsverlust.

 

Gundsätzlich kann man sagen, dass bei Komprimierung die MOS schneller sinkt als bei unkomprimierten Codecs, da die maximalen möglichen MOS niedriger ist:

 

G.711 => max MOS 4.4

G.729 => max MOS 4.07

G.723 => max MOS 3.69

 

Die Grenzen liegen bei:

 

Toll Quality (MOS > 4,3) – Very satisfied Users

- Prozentualer Paketverlust < 1 %

- Verzögerungszeit Ende zu Ende < 150 ms

- Jitter < 20 ms

 

Near Toll Quality (4,0 < MOS <4,2) - Satisfied Users

- Prozentualer Paketverlust < 3 %

- Verzögerungszeit Ende zu Ende < 400 ms

- Jitter < 50 ms

 

Best Effort (MOS < 4,0) – not recommended

- Prozentualer Paketverlust < 5 %

- Verzögerungszeit Ende zu Ende < 600 ms

- Jitter < 75 ms

 

...Genau! ==> hier richtig

 

Ciao