mein Gesprächspartner hört mich abgehackt

[Baracuda]

anscheinend ja schon, tom. es sind ja erfahrungswerte und die gehen nunmal in eine richtung.

 

[rotzbengel]

anscheinend ja schon, tom. es sind ja erfahrungswerte und die gehen nunmal in eine richtung.

sehe ich genau so.
Sonst würde ich hier ja nicht ein neues Thema auf machen. :wink:
Gruß
rotzbengel

 

[Gast]

Ja,aber diese Probleme treten bei anderen Providern doch auch auf!
Schaut mal hier das Forum ein wenig durch und Ihr werdet feststellen,daß es bis jetzt bei fast allen Anbietern diese Probleme gab.
Ich kann nur raten,einfach zu telefonieren und dann erst Emule zu aktivieren.
Gruß von Tom

 

[IntelliFon]

Habe mal emule bei meinem DSL 3000/384 laufen lassen hier das Ergebis:

sipsnip mit ATA und BT102 Verbindung stockt
sipgate mit ATA und BT102 Verbindung stockt
nikotel mit ATA und BT102 Verbindung stockt
dus.net mit ATA und BT102 Verbindung stockt
T-Online mit Softphone Verbindung stockt
Stana-Phone mit Softphone Verbindung stockt

Alle Tests mit einem Upload von 10KB also 80 von meinen 386 !
Das Problem liegt an den vielen offenen Verbindungen von emule.
Mit einer sauberen IP (nach Zuteilung einer neuen IP ohne emule) sind locker 4 VoIP-Gespräche möglich.

 

[IntelliFon]

war doppelt soory

 

[Baracuda]

also wenn sich jemand von mir über ftp mit 10kb was saugt, ohne emule, dann stockt auch meine verbindung. liegt bei mir somit nicht an emule und da ich mit sipgate keine probleme habe, liegt es an dus.net

 

[Gast]

Du siehst doch in den Ausführungen,daß hier bei mehreren Providern dieses Phänomen aufgetreten ist,also genau das passiert ist,was ich vorher schon erwähnt habe,egal ob bei sipgate,dus.net,t-online oder sonst wo!
Das sind eben Erfahrungen,die man nun mal mit File-sharing-Programmen im Zusammenhang mit VOIP gemacht hat.
Ich glaube,daß Du kaum andere Antworten bekommen wirst.
Bei dem einen klappt es,beim anderen nicht.
Gruß von Tom

 

[dus.net]

Hallo zusammen,

um die Angelegenheit einfach mal aus unserer Sicht zu klären ist folgendes ganz klar richtig:

- dus.net hat keine Leistungsprobleme und keine andere Signalisierung wie SIP oder IAX2
- unsere Codecs sind (in der Reihenfolge) alaw,ulaw,g726,ilbc,gsm

Eine Erklärung für Störungen in einem Gespräch fallen bei den hier genannten Szenarien doch einfach aus.

Telefonieren mit weiteren Datentransfers = Störung
Telefonieren ohne = Tadellos

Das bedeutet doch nur eins: Die verwendete Hardware kann mit diesem Problem nicht umgehen bzw. hat keine andere Möglichkeit den Datenstrom zu verringern (Codecs).

Trafficshaping ist im übrigen nicht gleich Trafficshaping. Es gibt keine Lösung die ein homogenes QOS ersetzen kann. Echtes QoS setzt allerdings eine Intelligente Hardware, Rechenleistung und ein Netz voraus welches QoS durchgängig (homogen) nutzt und verarbeitet. Das ist aber nur bei den wenigsten Breitbandanschlüssen in Deutschland der Fall.

Das "Shaping" oder "Bandbreitenmanagement" jedoch ist nichts weiter als ein "Zerhacken" des Datenstromes, was bei allen Diensten ausser VoIP auch keinerlei Auswirkungen hat.

Die gängigen Methoden sind:

1. Alle Pakete die nicht "bevorzugt" sind warten und werden dann in einem relativen Fenster übertragen. Nach der Übertragung ist wieder "Pause".

Folge: Kurze (zeit oder puffer)gesteuerte 100%ige Auslastung der Bandbreite, was aber über ein Mittelwert dann rechnerisch eine Veringerung der Bandbreite darstellt.

2. Pakete die nicht bevorzugt sind werden einfach "dropped" und nicht nach aussen übertragen. Diese Pakete werden dann Protokollseitig nochmals angefordert. Diese Möglicheit gibt es auch für eingehenden Traffic. Ist aber nur bei wenigen Produkten (z.B. Inalp Smartnodes) im Einsatz da die Rechenleistung meistens nicht ausreicht.

Folge: ungesteuerte Auslastung der Bandbreite auf nahezu 100% und starke Hardwarebelastung durch den künstlichen Paketverlust. Datenstrom wird aber sanfter als bei 1. gesteuert und es sollte wenige Störungen geben.

Alle beiden Möglichkeiten verursachen gelegentliche Störungen, wenn der Telefoniedatenstrom nicht verringert werden kann und die Bandbreite zu gering ist. Diese Techniken wurden auch nicht dafür "gedacht" echtzeitdatenströme zu bevorzugen, sondern Dienste gleichzustellen.

Also ist hier eine Nachbesserung der Hardware erforderlich damit die Bandbreite für den RTP-Stream weiter verringert werden kann (Codecs erweitern).

Der Codec G726 ist ein freier sehr flexibler Codec den eigentlich jede VoIP Hardware unterstüzen sollte. Ist das nicht der Fall ist die "Schuld" nicht bei einem Telefonieanbieter zu suchen.

Wir hoffen das hat ein wenig zur Klärung beigetragen.

Vielen Dank.

 

[Baracuda]

Das ist doch mal ein Beitrag. Vielen dank für die Hintergrundinformationen

 

[Gast]

Ja,interessanter Beitrag,zumal man jetzt weiß,daß eben sehr wenige eigentlich QoS nutzen können,weil es kaum unterstützt wird!
Das haben wir ja schon immer vermutet,daß es auch bei der Hardware noch kränkelt,also doch noch alles in den Kinderschuhen.
Hoffentlich denkt die VOIP-Branche über soetwas mal nach.
Gruß von Tom

 

[ike]

Hi!

Naja, das "echte" QoS muß ja nicht nur im VoIP-Bereich, sondern auch bei den Internet-Providern und überall auf allen Routern eingerichtet werden.

Meines Wissens nach wird das erst richtig mit IPV6 gehen.

Tschau!

Michael

 

[IntelliFon]

Das ist doch mal ein Beitrag. Vielen dank für die Hintergrundinformationen

Ja finde ich auch, ich möchte jetzt mal nicht auf den Link "anderer Provider mit 0190-Support" verweisen.

Bei so einem Beitrag fühle ich mich beim dus.net-Support in sehr guten Händen.