Qualität ist erheblich schlechter geworden

[haeberlein]

wie merkt man das? Ich habe nämlich auch keine Echos und habe einen Internetanschluss bei Kabel Deutschland

unter Windows cmd ausführen und dann tracert voip.dus.net
unter Linux Konsole und dann traceroue voip.dus.net

Das Traceroute gibt dann Auskunft wie die Packete im Internet laufen bzw geroutet werden.

Bei mir sieht es so aus,ohne Echos:

rene-haeberleins-power-mac-g5:~ haeberlein$ traceroute voip.dus.net
traceroute to voip.dus.net (213.9.46.46), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 1.630 ms 0.832 ms 0.807 ms
2 fritz.fonata.box (192.168.178.1) 1.539 ms 1.535 ms 1.505 ms
3 83-169-191-182-isp.superkabel.de (83.169.191.182) 8.001 ms 7.985 ms 8.084 ms
4 83-169-191-44-isp.superkabel.de (83.169.191.44) 8.316 ms 18.032 ms 10.192 ms
5 83-169-191-29-isp.superkabel.de (83.169.191.29) 12.508 ms 9.299 ms 9.919 ms
6 62.67.36.249 (62.67.36.249) 11.106 ms 11.125 ms 8.844 ms
7 ae-0-20.mp2.berlin1.level3.net (195.122.132.202) 10.346 ms 11.041 ms 12.204 ms
8 ae-1-0.bbr1.frankfurt1.level3.net (212.187.128.30) 24.305 ms as-1-0.bbr2.frankfurt.level3.net (212.187.128.97) 27.700 ms ae-1-0.bbr1.frankfurt1.level3.net (212.187.128.30) 27.808 ms
9 unknown.level3.net (195.122.136.124) 24.148 ms 26.358 ms unknown.level3.net (195.122.136.108) 25.781 ms
10 telia-level3-ge.frankfurt1.level3.net (4.68.111.102) 24.085 ms telia-level3-ge.frankfurt1.level3.net (4.68.111.178) 24.405 ms telia-level3-ge.frankfurt1.level3.net (4.68.111.102) 24.258 ms
11 ffm-bb1-pos7-3-3.telia.net (213.248.65.33) 26.786 ms 23.415 ms 30.022 ms
12 kol-b1-pos1-0.telia.net (213.248.65.106) 28.251 ms 27.852 ms 29.653 ms
13 kol-b1-pos4-0.telia.net (213.248.77.98) 28.402 ms 35.300 ms 32.630 ms
14 ncore-111509-ddf-b1.c.telia.net (213.248.68.142) 29.527 ms 29.496 ms 36.709 ms
15 gw-dus-net.dus.de.ncore.net (212.46.114.22) 28.166 ms 38.912 ms 28.934 ms
16 proxy.dus.net (213.9.46.46) 30.532 ms 40.794 ms 29.053 ms

 

[markbeu]

16 hops...6 mehr als bei mir und geringfuegig hoehere Pings und trotzdem kein Echo...
Das muss nicht unbedingt an der Route ligen; tippe da mehr auf verwendete Hardware und angeschlossene Telefone?

 

[dusnetuser]

16 hops...6 mehr als bei mir und geringfuegig hoehere Pings und trotzdem kein Echo...
Das muss nicht unbedingt an der Route ligen; tippe da mehr auf verwendete Hardware und angeschlossene Telefone?

Ja dachte ich auch... aber ein Wechsel des Providers bringt z.B. bei mir Abhilfe... Es kann und muß natürlich noch mehr dahinter stecken... Ich warte jetzt einfach mal den Mittwoch ab. Vielleicht klappts ja diesmal

 

[ahasver]

was soll denn die route mit dem echo zu tun haben?

Je länger die Route, umso länger die Laufzeit, desto nerviger und zeitverzögerter ein vorhandenes Echo. Und Je länger die Laufzeit/verzögerung, desto schwieriger dürfte die Echo-Erkennung und -unterdrückung durch Provider und SiP-Telefon sein.

 

[ahasver]

[...]
5 83-169-191-29-isp.superkabel.de (83.169.191.29) 12.508 ms 9.299 ms 9.919 ms
[...]
7 ae-0-20.mp2.berlin1.level3.net (195.122.132.202) 10.346 ms 11.041 ms 12.204 ms
[...]
14 ncore-111509-ddf-b1.c.telia.net (213.248.68.142) 29.527 ms 29.496 ms 36.709 ms
15 gw-dus-net.dus.de.ncore.net (212.46.114.22) 28.166 ms 38.912 ms 28.934 ms

Interessant: Kabel Deutschland routet über level3 und level3 hat wohl wie angekündigt tatsächlich die Stecker zu Cogent gezogen. Klar, daß dafür ein weiterer Uplink bei DusNet einspringt (und nicht nicht wie seinerzeit hier Cogent Only Routing passiert).

 

[haeberlein]

Verstehe nur Bahnhof. :bahnhof:

 

[andreas]

was soll denn die route mit dem echo zu tun haben?

Je länger die Route, umso länger die Laufzeit, desto nerviger und zeitverzögerter ein vorhandenes Echo. Und Je länger die Laufzeit/verzögerung, desto schwieriger dürfte die Echo-Erkennung und -unterdrückung durch Provider und SiP-Telefon sein.

Ja, je länger die Route, völlig richtig, aber nicht über wen die Route geht

 

[niemand0815]

naja, die länge der route ist eigentlich völlig egal.
wichtig ist nur die verzögerung die erzeugt wird.
die route ist nur wichtig um herauszubekommen welcher link die verzögerung verursacht.
dafür wäre aber eigentlich ein pathping sinnvoller.

es könnte aber noch etwas anderes sein:
bei den pings und tracert's verwenden wir icmp als protokoll. viele provider priorisieren aber genau dieses, damit die sla's mit businesskunden besser aussehen ;-)
(und viel last machen die normal auch nicht, ggf werden die noch bandbreitenbegrenzt).
kommt jetzt z.B. voip daher dann sieht das auf einmal ganz anders aus.

interessant wäre eine statistik der fbox oder des providers bei voip. also jitter und delay von beiden seiten aus, gemessen innerhalb der voip datenstroms. wichtig wäre dabei der bidirektionale delay (also hin und zurück).

mich wundert nur warum diese statistiken noch kein provider anzeigt, da es auf providerseite eigentlich ein leichtes sein müsste zumindest einen teil der werte zu ermitteln (z.B. bidir delay aus dem abstand paket->accnowledge, jitter aus der varianz desselben, loss ebenso über die acks).

 

[dusnetuser]

[glow=red][shadow=red]Seit Dienstag absolut keinerlei Echo´s mehr!! Das hat Dus.net endlich super hinbekommen!! Vielen Dank. Nun wird gevoiced