Qualität ist erheblich schlechter geworden

Das Echo kann auch am verwendeten Telefon liegen. In Verbindung mit verschiedenen Codecs und Latenz-Zeiten kann das auch erheblichen Einfluss auf die Qualität haben. Generell hat man mit schnurlosen- DECT-Telefonen, welche eines dem Hörer sehr nahen Mikrofon besitzen (kurze Bauform) öfters Probleme mit Echos bei VoIP. Ausserdem wird bei DECT das Signal zwei mal digitalisiert (einmal im Telefon und dann nochmal in der Box), was auch nochmal zu Verzögerungen kommen kann. Ich habe glücklicher Weise keinerlei Echo-Probleme mit meinem C340.

Gruss, mucro
 
wenn es aber über andere provider ohne echo ist dann ist ein lokales problem des telefons doch sehr unwahrscheinlich.
 
Ich will ja auch nichts absolut ausschliessen. Aber es gibt sehr viele Faktoren, die Echos auslösen können. Es klagen ja nicht alle über Echos, daher wird das Problem in der Kombination von Endgeräten, ISP und VoIP-Anbieter zu suchen sein. Da bieten sich sehr grosse Kombinationsmöglichkeiten.
 
Dus.Net antwort leider nicht auf meine Mails, und ans Telefon geht dort auch keiner mehr :-( fast schon so wie zu nikotel-zeiten :-(

d.h. Bald wohl wieder die nächste Rufnummerportierung, und diesmal zu einem Anbieter, der nicht über Versatel routet.
 
Ich hatte das Echoproblem vor dem Congento-Level3-Krach eine zeitlang mit Nikotel.
Die Route war damals ziemlich lang (glaube, so 15 bis 20 Hops). Und das Echo dann extrem nervig bis zur unverständlichkeit. Seit sich die Routen geändert haben, klappt das wieder.
Mit DusNet hatte und habe ich die ganze Zeit keine Probleme bemerkt (außer daß meine erfolgreiche Portierung immer noch nicht im Webinterface angezeigt wird), obwohl seit der Trennung von Cogent die Route von CableSurf zu DusNet etwas länger geworden ist.
Hab aber in der fraglichen Zeit des hier geschilderten "besetzt"-Problems kaum telefoniert.
Ich denke, tatsächlich dürfte der Tiscali-Backbone ein Problem sein, speziell der stark ausgelastete Netzübergang in Frankfurt dürfte ein Nadelöhr sein...
Um Micro's Statement noch etwas zu präzisieren: Schlechte (lange oder überlastete) Routen wirken sich in jedem Fall nachteilig auf Echos aus. Schlechte Routen sind meiner Meinung nach das Hauptproblem. Einige Geräte und VoIP-Provider können die Echos softwaremäßig reduzieren, so daß es trotzdem klappt.
 
Falls du mein Statement weiter oben gelesen hast. Spreche ich hier von einer direkten weiterleitung von dus.net auf einen festnetzanschluss.
 
Neue Erkenntnis: Rufe ich einen an, der auch dus.net besitzt, so ist die Qualität perfekt... sollte die Gegenstelle allerdings einen Festnetzanschluß bestitzen, so tritt dieses besagte Echo auf.
 
Das Problem haben Bekannte von mir, die bei 1&1 sind. Wenn die Festnetz-Anschlüsse Anrufen, dann treten Echos aus. Telefonate von 1&1 zu meinem Dus.net Account verlaufen problemlos. Evtl. kann das Problem dann wohl auch an dem jeweiligen Einwähl-Knoten ins Festnetz liegen.
 
Das liegt daran, das interne GEspräche nicht über versatel laufen. Für mich ist eindeutig klar, dass die Probleme hier bei Versatel liegen.
 
ein gutes beispiel ist hier der vergleich cisco zu anderen.
da cisco am anfang voip ohne qos propagiert hat wurde dort viel in den entwicklungsaufwand bei schlechter ip-verbindungsqualität gesteckt.
somit sind diese phone meist bei einem "schlechten" netz (jitter, loss, delay) besser als andere.
ebenso dürfte dies auch mit voip anbietern (bzw deren hardware) sein. eventuell spielt dann in manchen fällen auch die implementierung des codecs auf der anlage selbst (fritzbox z.B.) mit.
was man auch nicht weiss:
wie viele recodierungen werden vorgenommen?
es gibt bestimmt anbieter welche den voip-call erstmal zu einem anderen provider und dann erst ins festnetz einspeisen. dabei würde dann eventuell zwischen den beiden voip-providern ein anderer codec eingesetzt als der des ursprünglichen gespräches (beispiel 711 zu 1. provider, 729 zu 2. provider, dann erst per festnetz raus).
durch dieses recoding kommt es normal massiv zu qualitätseinbussen.
 
Ich habe gerade ein traceroute gemacht, mit dus.net und anderen Providern. voip.dus.net ergab folgendes enttäuschendes Ergebnis:
Code:
traceroute to voip.dus.net (213.9.46.46), 64 hops max, 40 byte packets
 1  xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)  3.078 ms  7.987 ms  1.989 ms
 2  10.118.0.1 (10.118.0.1)  20.094 ms  11.909 ms  9.469 ms
 3  172.30.21.41 (172.30.21.41)  9.503 ms  13.408 ms  9.428 ms
 4  * * 172.30.21.10 (172.30.21.10)  21.713 ms
 5  172.30.21.1 (172.30.21.1)  31.005 ms  15.800 ms  23.506 ms
 6  172.30.9.10 (172.30.9.10)  13.811 ms  15.459 ms  14.895 ms
 7  ffm-b1-geth2-0.telia.net (213.248.79.205)  18.465 ms  32.363 ms  17.684 ms
 8  ffm-bb1-pos1-1-0.telia.net (213.248.68.9)  18.582 ms  17.366 ms  17.422 ms
 9  kol-b1-pos1-0.telia.net (213.248.65.106)  20.996 ms  30.228 ms  55.216 ms
10  kol-b1-pos4-0.telia.net (213.248.77.98)  22.835 ms  21.801 ms  51.172 ms
11  ncore-111509-ddf-b1.c.telia.net (213.248.68.142)  111.494 ms  112.123 ms  113.650 ms
12  gw-dus-net.dus.de.ncore.net (212.46.114.22)  111.337 ms  109.197 ms  114.823 ms
13  proxy.dus.net (213.9.46.46)  112.901 ms  112.497 ms  111.058 ms

Alle anderen Provider lagen überall unter 35ms. Können die langen Antwortzeiten ab 11 der Grund für die enormen Echos sein, die ich z.Zt. bei dus.net habe? Und wenn ja: liegt das schon im Verantwortuungsbereich von dus.net? Lohnt sich also eine Mail an den dus.net-Support?

Kennt sich da jemand aus?

Heiko
 
Die Server scheinen wohl jetzt auch alle wieder in Düsseldorf zu stehn.
 
Um das Problem noch einmal aufzugreifen:

Bei mir gibt es ein Echo nach wie vor. Genau das gleiche Problem habe ich auch bei Sipgate, jedoch nicht bei gmx, simply-connect und aol.

Das Echo tritt auch nur auf, wenn ich ein Festnetzgespräch führe mit Sipgate oder Dusnet. Solle ein IP zu IP oder zu einem Handy das Gespräch stattfinden, so sind keinerlei Echo vorhanden.


Meine Konstellation ist: FritzBoxFon die rote alte mit neuester Firmware, Codec 726-32 oder PCMA, festes Telefon, DSL 1000 mit Fastpath, Provider Kamp-DSL.

Es ist halt nur sehr seltsam, dass es mit anderen Voip-Providern keinerlei Probleme gibt und selbst mit meinen Problem Providern ist es nur bei Festnetzgesprächen.

Interessant für mich wäre es auch, bei denen die keinerlei Echo haben, die Konstellation.

Ich möchte das Problem nun endlich beheben, da meine Nummer bei dus.net portiert ist und mich die echos langsam tierisch nerven.
 
Haaaalloooo Ächoooooo

Bei mir echot es ohne Ende. Da auch meine Nummern zu dus.net portiert sind bin auch ich an einer Lösung stark interessiert. dus.net anscheinend nicht so.

Bei gmx treten auch bei mir keine Echos auf. Alles zum oder vom Festnetz. Ausgehende Gespräche führe ich also zur Zeit hauptsächlich über gmx und damit geht dus.net ein wenig Umsatz verloren. Wenn das bei vielen Kunden auftritt verlieren die Marktanteile. Das ist schade weil ich wirklich froh bin von der Telekom los zu sein.

Leider gehen alle eingehenden Gespräche über dus.net weil bei denen ja meine Nummern geschaltet sind.

Nun, was machen wir um das Problem zu lösen?

Heiko
 
@heiend: Was hast du für einen Internet Anschluss bzw nutzt du in deinem privaten Netz die IP Adressraum 10.x.x.x?
Mir kommt das hier sehr komisch vor, da dieses eigentlich eine IP Adresse aus dem privaten Bereich ist und eben nicht im Internet geroutet werden soll!
2 10.118.0.1 (10.118.0.1) 20.094 ms 11.909 ms 9.469 ms
Außerdem ist zwischen
Code:
10  kol-b1-pos4-0.telia.net (213.248.77.98)  22.835 ms  21.801 ms  51.172 ms
11  ncore-111509-ddf-b1.c.telia.net (213.248.68.142)  111.494 ms  112.123 ms  113.650 ms
ein Sprung von mehr als 60 ms! Ich denke mal das Echo kommt genau von diesem Punkt!
@dusnetuser:
Dus.net funktioniert bei mir ohne Probleme in der FbF. Allerdings habe ich auch einen T-DSL 2048 Anschluss mit etwas mehr Upstream als ein 1024 Anschluss.Ich glaube das liegt einfach nur am Upstream, denn sonst kann ich mir die Echos beim Gesprächspartner nich erklären. Hast du nebenbei noch was anderes laufen was Upstream benötigt?
 
Also ich bin nun etwas baff. Ich habe zum Spaß mir den byCall Tarif mit 100mb inclusive bei justdsl geholt. Damit ist die Qualität mit dus.net genauso perfekt wie mit gmx. Ich verstehe das nicht! Die Pings sind spitze und mit gmx klappts ja auch!
 
dusnetuser schrieb:
Also ich bin nun etwas baff. Ich habe zum Spaß mir den byCall Tarif mit 100mb inclusive bei justdsl geholt. Damit ist die Qualität mit dus.net genauso perfekt wie mit gmx. Ich verstehe das nicht! Die Pings sind spitze und mit gmx klappts ja auch!
Es liegt dann wohl (doch) am Routing! Hast du diese Fehler schon länger oder erst seit c.a. 2 Wochen? Ich hatte das Thema mal in der Störungsstelle angesprochen.

Edit: Mach mal bitte mit beiden providern ein traceroute (tracert) zu voip.dus.net und poste das mal bitte hier. Ich bin gespannt über welche Route die gehen.
 
beckmann schrieb:
dusnetuser schrieb:
Also ich bin nun etwas baff. Ich habe zum Spaß mir den byCall Tarif mit 100mb inclusive bei justdsl geholt. Damit ist die Qualität mit dus.net genauso perfekt wie mit gmx. Ich verstehe das nicht! Die Pings sind spitze und mit gmx klappts ja auch!
Es liegt dann wohl (doch) am Routing! Hast du diese Fehler schon länger oder erst seit c.a. 2 Wochen? Ich hatte das Thema mal in der Störungsstelle angesprochen.

Ja das Problem besteht schon sehr lange. Echo tritt beim lauter reden auf meine Seite auf. Was mich etwas irritiert, dass es nur bei Festnetzgesprächen ist. Das es mit justdsl so perfekt funktioniert hätte ich nicht gedacht.
Muss ich mich dann an Kamp-DSL wenden? Werde wohl nicht sehr viel Erfolg haben schätze ich?!
 
Mach mal bitte einen Traceroute zu voip.dus.net mit beiden providern. Ich glaube just dsl wählt einfach nur eine bessere Route aus. Wenn es wirklich daran liegt spreche mal mit dem Dus.net Support, denn dieses Problem hast ja nicht nur du. Ich habe seit c.a. 2 Wochen schon mal Probleme mit Dus.net VOIP, seit dem ich anders geroutet werde :(
 
Einmal mit justdsl:
Code:
Routenverfolgung zu voip.dus.net [213.9.46.46]  über maximal 30 Abschnitte:

  1     1 ms     1 ms    <1 ms  fritz.fon.box [192.168.178.1]
  2    17 ms    17 ms    18 ms  tx016105.in-addr.bellaxa.net [217.118.16.99]
  3    17 ms    18 ms    17 ms  tx016250.in-addr.bellaxa.net [217.118.16.250]
  4    18 ms    18 ms    19 ms  tx016096.in-addr.bellaxa.net [217.118.16.50]
  5    17 ms    17 ms    16 ms  po1-0.core01.fra03.atlas.cogentco.com [80.81.192.63]
  6    21 ms    20 ms    20 ms  p6-0.core01.dus01.atlas.cogentco.com [130.117.1.129]
  7    22 ms    21 ms    20 ms  ncore.demarc.cogentco.com [130.117.19.58]
  8    23 ms    23 ms    20 ms  gw-dus-net.dus.de.ncore.net [212.46.114.22]
  9    22 ms    21 ms    23 ms  proxy.dus.net [213.9.46.46]

und einmal mit kamp-dsl
Code:
Routenverfolgung zu voip.dus.net [213.9.46.46]  über maximal 30 Abschnitte:

  1     1 ms     1 ms     1 ms  fritz.fon.box [192.168.178.1]
  2    21 ms    21 ms    20 ms  dsl-gate.kamp.net [195.62.99.234]
  3    22 ms    21 ms    23 ms  ge-2-2.c0.ob.net.kamp.net [195.62.99.49]
  4    23 ms    22 ms    24 ms  gi1-2.duesseldorf1-x.d.net.kamp.net [212.110.97.242]
  5    22 ms    23 ms    23 ms  f3-3.br1.dus.de.ncore.net [194.146.118.7]
  6    24 ms    24 ms    23 ms  gw-dus-net.dus.de.ncore.net [212.46.114.22]
  7    24 ms    21 ms    24 ms  proxy.dus.net [213.9.46.46]

Zu erwähnen ist auch noch, dass ich mit Sipgate dann auch perfekte Quali habe. Und Sipgate benutzen doch sehr sehr viele?! Die Traceroutes sehen doch prima aus oder etwa nicht?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.