Mit welchen Providern klappt Traffic Shaping?

[cyberpeter]

Kann man eigentlich anhand anderer Tests (Ping, etc.) irgendwelche brauchbaren Erkenntnisse erzielen, wie gut oder wie schlecht die Verbindung ist?

Denn eigentlich hab ich auch keine Probleme beim Up- und Download. Und die Fehlerrate hat ja nach meinem Verständnis auch nicht viel zu sagen, da ja genau dafür das Interleaving mit Fehlerkorrektur da ist. Kritisch dürfte es doch erst dann werden, wenn tatsächlich Pakete verloren gingen, oder? Nur dann müsste das betroffene IP-Paket neu gesendet werden, wodurch sich dann eine Verzögerung entstünde. Und bei UDP würde es komplett unter den Tisch fallen.

Gag

Der Ping ist nicht so gut geeignet, das er nur eine Momentaufnahme darstellt. Es wäre besser ein Tools, was permanent die Zeit mißt. Dann könnte man auch feststellen, ob z.B. beim Surfen sich die Zeit, die das Datenpackt zum SIP-Server braucht signifikant erhöht.

Das mit der Fehlerkorrektur ist zwar richtig, es gehen keine Packete verloren, was bei VOIP auch nicht so tragisch wäre. Was schlimmer ist, das verlorene Packete neu "angefordert" werden müssen, was einiges an Zeit kostet und einen "Stau" verursacht.

 

[Gag_Halfrunt]

Das mit der Fehlerkorrektur ist zwar richtig, es gehen keine Packete verloren, was bei VOIP auch nicht so tragisch wäre. Was schlimmer ist, das verlorene Packete neu "angefordert" werden müssen, was einiges an Zeit kostet und einen "Stau" verursacht.

Ja, Moment... Ich muss zugeben, ich hab wenig Ahnung von dem Protokoll, was vom DSL-Modem zur Vermittlungsstelle gefahren wird. Aber die FEC hat doch in "meinem Fall" alle Fehler korrigiert. Also ist auch nichts verloren gegangen. Sonst würde ja was bei "Loss of Frame" oder gar "Loss of Signal" stehen, oder?

Das mit dem "neu anfordern" passiert doch auf TCP/IP-Ebene -- und die liegt doch erst eine Schicht darüber. Mal abgesehen davon, dass VoIP ja per UDP läuft und da nichts neu angefordert wird.
Einen "Stau" kann nach meinem Verständnis bei den übrigen TCP-Paketen ja auch nicht geben -- wo denn auch? Wenn was nicht korrekt übertragen wurde, dann wird es nochmal gesendet. Aber das blockiert doch nicht die anderen Pakete, oder?

Hmmm... Hätte ich mal bei der Netzwerkschulung besser hingehört

Gag

 

[cyberpeter]

Ja, Moment... Ich muss zugeben, ich hab wenig Ahnung von dem Protokoll, was vom DSL-Modem zur Vermittlungsstelle gefahren wird. Aber die FEC hat doch in "meinem Fall" alle Fehler korrigiert. Also ist auch nichts verloren gegangen. Sonst würde ja was bei "Loss of Frame" oder gar "Loss of Signal" stehen, oder?

Das mit dem "neu anfordern" passiert doch auf TCP/IP-Ebene -- und die liegt doch erst eine Schicht darüber. Mal abgesehen davon, dass VoIP ja per UDP läuft und da nichts neu angefordert wird.
Einen "Stau" kann nach meinem Verständnis bei den übrigen TCP-Paketen ja auch nicht geben -- wo denn auch? Wenn was nicht korrekt übertragen wurde, dann wird es nochmal gesendet. Aber das blockiert doch nicht die anderen Pakete, oder?
Hmmm... Hätte ich mal bei der Netzwerkschulung besser hingehört
Gag

Ich bin auch kein Experte. Das UDP keine Korrektur erfährt ist klar. Aber ich habe mir das von jemand, der es wissen sollte so erklären lassen. Das erneute Anfordern von Packeten führt zu einem "Stau" weil erst dann mit der Datenübertragung weitergemacht wird, wenn das defekte Paket wieder da ist. Dies führt dann sekundär dazu, das auch UDP ins Stocken gerät. Jetzt kommt die Qualität des Modems ins Spiel. Desto schlechter das Modem ist, desto höher der Anteil an defekten Packeten bei Belastung und desto größer auch der "Aussetzer" bei defekten Packeten.

Hoffe ich habe es jetzt ohne großen Murx rübergebracht.

 

[KiRKman]

Du hast ja Fast, wir haben aber Interleaved, d.h. bei uns gibt es keine durch die Übertragung defekte TCP oder UDP Pakete im IP Es liegt wahrscheinlich dennoch am Modem, aber nicht wegen defekter Pakete. Ich hatte da ja bereits andere Theorien kundgetan

 

[TWELVE]

TWELVE, ich habe natürlich auch die neueste Firmware drin. Seitdem geht bei Dir Sipgate störungsfrei? Kann ich leider ganz und gar nicht bestätigen.

@KIRKman:

Ich habe seit .37 eine signifikante Verbesserung des Shapers zumindest bezüglich VoIP.Ich hatte allerdings die letzten Tage den Eindruck, das
hier nur die Balance zugunsten VoIP verschoben wurde, da eine VPN
Verbindung über die Fritz Fon, die ich regelmäßig zur Firma aufbaue,
subjektiv "lahmer" geworden ist, wenn viel "sonstiger" Traffic über die
Fritz geht.Dies ist auch der Fall, wenn ich gerade nicht telefoniere.Könnte
also gut sein, das die TCP/ACK Pakete nun? eine höhere Prio bekommen haben, die VPN Pakete, die über UDP laufen, werden da wohl etwas benachteiligt.Bezüglich SipGate werde ich heute abend nochmal ein paar
Tests machen, bevor ich jetzt was falsches sage.Freenet jedenfalls läuft
ohne "Hackern" auf der Gegenseite, dies war in den vorherigen FWs nicht
der Fall bei Upload Nutzung.


Grüße

TWELVE

 

[cyberpeter]

Du hast ja Fast, wir haben aber Interleaved, d.h. bei uns gibt es keine durch die Übertragung defekte TCP oder UDP Pakete im IP Es liegt wahrscheinlich dennoch am Modem, aber nicht wegen defekter Pakete. Ich hatte da ja bereits andere Theorien kundgetan

Wie gesagt, ich bin kein Experte, aber das was Du da geschrieben hast, ist nicht ganz richtig. Egal ob Fast Path oder nicht, es gibt defekt Packete. Ohne FastPath ist aufgrund der Art, wie die Daten gesendet werden die Fehlerkorrektur leichter, der Ping dafür langsamer. Wenn jedoch wie bei Gag_Halfrunt viele defekte und somit auch zu korrigierende Pakete ankommen, dann kommt es zu einem größeren Verwaltungsoverhead ("Stau"). Der für seine Störungen verantwortlich sein kann.

http://www.avm.de/de/index.php3?Service/TechnikLexikon/F/Fast_Path.html
http://www.dsl-today.de/faq-dsl-fastpath-bestellung.php

Der Grund, wieso es zu einer solchen Häufung von Fehlern kommt oder auch sehr schlechte Werte bei Dämpfung und Signal, obwohl man in der Nähe der Vermittlungsstelle wohnt, kann ein fehlerhafter Port in der DSL-Vermittlungsstelle sein. Deshalb auch mein Tip.

Aber ich glaube, wir reden hier um die goldene Banane. Fakt ist, das das Modem der FritzBox nicht gerade das Beste ist und bei vielen schlechteren Leitungen für die Fehler mit verantwortlich ist.

 

[KiRKman]

@TWELVE: Ich habe seit dem Einspielen der .37 keine Änderungen in meiner AR7.cfg festgestellt. Allerdings habe ich von mehreren Leuten gehört, daß sich irgendwann mal die Rule "voip" in "fon-rtp" gewandelt hat. Bei der neuen Shaper-Rule wurden dann, anstatt die VoIP-Ports zu bevorzugen wie bisher, alle UDP-Pakete mit dem VoIP-Flag bevorzugt, ohne auf bestimmte Ports zu achten. Ich hab' diese neue Rule aus der default AR7.cfg in der Box kopiert und in meine aktuelle eingefügt, die alte Rule natürlich gelöscht. Einen Unterschied hat es aber leider nicht gebracht Das Shaping funktioniert wie bisher, aber das totale Zerhacken bleibt. Daher wäre ich sehr interessiert, ob bei Dir Sipgate jetzt vielleicht doch besser läuft bei Uploads. Wenn Du das mal beizeiten austesten könntest, wäre ich Dir sehr verbunden

 

[Gag_Halfrunt]

Wie gesagt, ich bin kein Experte, aber das was Du da geschrieben hast, ist nicht ganz richtig. Egal ob Fast Path oder nicht, es gibt defekt Packete. Ohne FastPath ist aufgrund der Art, wie die Daten gesendet werden die Fehlerkorrektur leichter, der Ping dafür langsamer. Wenn jedoch wie bei Gag_Halfrunt viele defekte und somit auch zu korrigierende Pakete ankommen, dann kommt es zu einem größeren Verwaltungsoverhead ("Stau"). Der für seine Störungen verantwortlich sein kann.

Nein. Es kommen keine defekten IP-Pakete an. Dafür sorgt schließlich die Fehlerkorrektur.

Beim Interleaving werden die Daten versetzt gesendet.

Statt nacheinander

AAAAAA BBBBBB CCCCCC DDDDDD EEEEEE FFFFFF

werden sie ineinander verschränkt übertragen:

ABCDEF ABCDEF ABCDEF ABCDEF ABCDEF ABCDEF

Tritt jetzt eine kurze Störung auf, dann sieht das z.B. so aus:

ABCDEF ABCDEF xxxxxx ABCDEF ABCDEF ABCDEF

Der Empfänger setzt diese verschränken Daten wieder zusammen und kommt zu folgendem Ergebnis:

AAxAAA BBxBBB CCxCCC DDxDDD EExEEE FFxFFF

Soll heißen, dass sich diese kurze Störung auf mehrere Dateneinheiten verteilt hat. Aber genau das ist der Trick bei der Sache: Kleine Beschädigungen kann die Fehlerkorrektur beseitigen, da jeder Einheit eine Püfsumme mitgeschickt wird, durch die rechnerisch Fehler bis zu einer bestimmten Größe zuverlässig erkannt und korrigiert werden können.

Auf TCP/IP-Ebene kommen als wieder 100% korrekte Pakete heraus. Erst wenn die o.g. Fehlerkorrektur versagt, muss über TCP/IP ein Paket neu gesendet werden. Auf der Netzwerkebene darunter gibt es sowas nicht.

Das Interleaving wird überall dort eingesetzt, wo Datenströme übertragen werden und es zur kurzzeitigen Störungen kommen kann. Auf Audio-CDs, beim digitalen Fernsehen, usw.

Gag

 

[TWELVE]

Die Fehlerkorrektur des DSL Interleaving ist überflüssig, auch wenn Big Pink
darauf jahrelang bestanden hat.Wahrscheinlich nur, um 25 Euro für jede Aktivierung abgreifen zu können.Bei Arcor z.B. gibt es erst gar kein Interleaving zur Auswahl, die haben nur FastPath.Folgt man den Interleaving-Argumenten, dann müßten alle Arcor User Probleme mit Übertragungsfehlern haben.Dem ist nicht so.Evtl. kann Interleaving eine sehr schlechte DSL Leitung noch halbwegs benutzbar halten, aber kann nicht Sinn und Zweck sein, ständige Datenfehler durch Interleaving zu korrigieren.Da sollte man dann doch mal was an der Leitung tun.Etwa so, wie die Fehlerkorrekur eines CD Players eine zerkratzte CD doch noch
abspielbar macht, das sollte aber nicht zur Regel werden, da sich die Fehlerkorrektur ab einer gewissen Fehlerrate doch im Klangbild nachweisen läßt.Dagegen sind die Vorteile von FastPath unbestritten: Viel schnellere Ping- / kleinere Latenzzeiten.Dies macht sich bei jeder Form von Kommunikation bemerkbar, auch Webseiten laden schneller.Die Sprachqualität dürfte bei FastPath ebenfalls besser sein, und das sogar selbst wenn sich doch mal ein Übertragungsfehler einschleicht.Meine beste
Pingzeit hier ist 10ms , ich denke das spricht für sich.


Grüße

TWELVE


gewissen Fehlerrate

 

[cyberpeter]

Soll heißen, dass sich diese kurze Störung auf mehrere Dateneinheiten verteilt hat. Aber genau das ist der Trick bei der Sache: Kleine Beschädigungen kann die Fehlerkorrektur beseitigen, da jeder Einheit eine Püfsumme mitgeschickt wird, durch die rechnerisch Fehler bis zu einer bestimmten Größe zuverlässig erkannt und korrigiert werden können.

Auf TCP/IP-Ebene kommen als wieder 100% korrekte Pakete heraus. Erst wenn die o.g. Fehlerkorrektur versagt, muss über TCP/IP ein Paket neu gesendet werden. Auf der Netzwerkebene darunter gibt es sowas nicht.

Das Interleaving wird überall dort eingesetzt, wo Datenströme übertragen werden und es zur kurzzeitigen Störungen kommen kann. Auf Audio-CDs, beim digitalen Fernsehen, usw.

Gag

In meinem Link zu dsl-today steht übrigens das, was Du gerade geschrieben hast :wink:

Das Problem bei deinem DSL-Anschluss ist, ob man bei deiner Fehleranzahl in der kurzen Zeit noch von kleinen Fehlern sprechen kann, die sich nicht auswirken. Das glaube ich nämlich nicht. Deshalb auch der Tip mit dem DSL-Port bei der Telekom.

Aber wenn Du es besser weist ... :?

 

[KiRKman]

Naja, ich hatte vor einem Jahr mal Probleme mit meinem damaligen Provider Freenet. Die haben dann behauptet, es läge am T-DSL. Daraufhin hat die T-Com auch meinen Port mal getauscht. Das Ergebnis war, daß ich von dem Mittag an bis zum nächsten Tag um die Mittagszeit keinen Sync hatte Zum Glück war kein Wochenende. Aber nach gut einem Tag haben die ihre Schnitzereien wieder repariert. Gebracht es hat nichts. Immerhin mußte Freenet dann zugeben, daß die Schei*e in meiner Area gebaut hatten...

Kann natürlich sein, daß es anderswo was bringt. Probieren kann man es ja mal. Dazu am besten die 2000 anrufen, die Probleme mit der hohen Fehlerrate schildern und fragen, ob ein Portwechsel möglich wäre. Das gilt natürlich nur für Leute, die auch tatsächlich T-DSL haben. Wahrscheinlich wird man dann aber vom Prüfplatz erstmal die Leitung messen und dann entscheiden, ob ein Portwechsel durchgeführt werden soll. Meist wird der Port erstmal nur resettet und man auf später vertröstet. Wenn die den Port dann tatsächlich mal ändern, kann man nur noch beten Eigentlich sollte nach 20 Minuten alles wieder da sein... Aber als abends um 20 Uhr mein DSL immer noch nicht zurück war, habe ich mich doch mal beschwert

Aber wir wissen ja auch gar nicht, ob unsere VoIP-Probleme nun tatsächlich etwas mit der Leitungsqualität des T-DSL o.Ä. zu tun haben. Fakt ist, daß einige Leute behaupten, mit ihrer FRITZ!Box und Sipgate keine Probleme zu haben, während sie etwas Uploaden. Bei anderen Leuten hört die Gegenstelle derweil nur Brutzel. Vielleicht haben ja auch jene, die angeblich keine Probleme haben, sich nur noch nicht selber angerufen und angehört...

 

[Gag_Halfrunt]

Das Problem bei deinem DSL-Anschluss ist, ob man bei deiner Fehleranzahl in der kurzen Zeit noch von kleinen Fehlern sprechen kann, die sich nicht auswirken. Das glaube ich nämlich nicht. Deshalb auch der Tip mit dem DSL-Port bei der Telekom.

Aber wenn Du es besser weist ... :?

Da ich nicht weiß, wie viele Frames da in der Zeit übertragen insgesamt wurden, ist eine qualitative Bewertung der absoluten Zahl der durch FEC erfolgreich (!) korrigierten Frames nicht möglich.

Zudem steht in dem Protokoll ja sehr deutlich: "Loss of Frames: 0"
Und das interpretiere ich jetzt einfach mal so, dass keine Daten verloren gegangen sind.

Dein Vergleich zur Audio-CD ist richtig: Qualitative Einbußen hat man immer dann, wenn der Kratzer so groß ist, dass ein Sektor nicht mehr gelesen werden konnte. Dann versucht ein guter Player, diese "Lücke" durch Interpolation zu schließen. Und genau hier hat man dann die Qualitätseinbuße.
Bei der Datenübertragung gibt es aber nur zwei Zustände: Geht oder geht nicht. Und unter "geht" fällt auch ein duch die Fehlerkorrektur reparierter Abschnitt.

Gag

 

[KiRKman]

Ich hab' in der Spalte FEC doch alles auf 0, und trotzdem hören meine Gesprächspartner nur Chébruzz... Warum soll das also bei Gag ausgerechnet daran liegen? Macht doch keinen Streß so kurz vor dem Wochenende

 

[markus76]

ist euch eigentlich nicht schon einmal der gedanke gekommen, dass voip einfach (noch) nicht wirklich marktreif ist?
ich habe die beschriebenen aussetzer mit der fritz!box fon wlan UND mit einem zyxel660hw-67.

 

[TWELVE]

ist euch eigentlich nicht schon einmal der gedanke gekommen, dass voip einfach (noch) nicht wirklich marktreif ist?

JA.Schon öfter..
Verglichen mit Skype bietet SIP eine magere Qualität, und gemessen an
den Netzwerkproblemen von SIP und der Einfachheit von Skype ( extrem
routerfreundlich, keine Konfiguration ) erst recht.Die große Chance des SIP
besteht darin, das es ein "Standard" ist.Standard ist gut, dann ist man viel
weniger an bestimmte Provider oder Hardware gebunden.Aber an der Qualität, da stimm ich voll zu, muß noch was getan werden.Sicher kommen die Probleme nicht vom SIP an sich, sondern von der Umsetzung bei einigen Providern ( schlechte Anbindung, lahme Server usw.).Vielleicht
sollte man Provider wie z.B. "Freenet" nicht mit SIP verwechseln.

Grüße

TWELVE

 

[gottboss]

Hallo,

bei mir läuft VoIP mittlerweile auch mit P2P Traffic und Upload, sowie HTTP Bursts exzellent und ohne Paketverlusste oder große Jitter-Probleme.

Allerdings nicht mit jedem Provider. Ich habe in der FBox einen JitterBuffer von 100ms gesetzt. GMX NetPhone akzeptiert dies und puffert fleißig mit. Mit GMX habe ich daher keine Probleme.

Bei Freenet siehts leider ganz übel aus. Die investieren wohl zu wenig oder an der falschen stelle. (Btw. habe ich seit 3 Monaten weder EVN noch Rechnung... naja)

Eine Einschränkung muss ich aber hinnehmen. Ich muss meinen LAN-to-WAN Traffic vor der FBox brutal zusammenstauchen. Ich verwende als Codec den G726-32 mit ca. 55,2 kbit/s Brutto Eth. Bandbreitenverbrauch. Um diesen Betrag reduziere ich meinen Upload VOR der FBox. Mittels IPcop und HTB QoS. Vom 128 kbit/s bleiben so noch ca. 70 kbit/s übrig. Nicht schön aber es funktioniert.
Zusätzlich habe ich den Shaper in der FBox angewiesen, NUR loakeln RTP Paketen Prio 100 zu geben, alle anderen Pakete bekommen Prio 0! So hat VoIP aus der FBox vorrang egal, was sonst passiert.
Skype, Counterstrike und Co - kurz jegliche Echtzeitdienste sind so aus dem LAN nicht mehr möglich - NUR noch meine FBox VoIP Telefonie.

Dafür ist die Lösung günstig und die 128 Kbit/s reichen - 24x7 - egal ob FTP-Upload oder P2P läuft! (Klar: DSL mit 512 kBit/s Upload mit QoS würde auch helfen, aber dann zahlen wir jeden Monat fast drei mal so viel für den Internetzugang.)

Das ist in unserem Falle nicht tragisch, da wir ausschließlich Datendienste einsetzen, zeigt aber:

VOIP IST NOCH NICHT MARKTREIF. Zumindest nicht solange weder Provider noch SoHo Router z.B. mit DiffServ oder IPv6 arbeiten. Und der Weg dort hin wird steinig.

Viele Grüße,
Gottlieb

 

[TWELVE]

@KIRKman:

Ich habe jetzt gerade nochmal ein bißchen getestet.Die Ergebnisse sehen leider so aus, das ich das mit dem TrafficShaping ein wenig relativieren muß.
Bei starkem Traffic ( muß nicht Esel sein, kann auch z.B. BT sein) gibt es nach wie vor ein Hackern auf der Festnetz-Gegenüber-Seite.Bei Freenet ist es deutlich geringer als bei Sipgate, aber im Prinzip kann man es bei beiden nachweisen.Nur die Schwelle, ab wann das passiert, scheint bei beiden unterschiedlich zu sein.Bei Sipgate tritt es deutlich eher auf.Ich widerrufe also die Aussage, das die Probleme mit dem Shaper ab .37 weg sind.Die
Toleranz gegenüber der vorherigen FW ist zwar deutlich besser geworden,
aber ab einem bestimmten Traffic setzt das Problem wieder ein.An den Eckdaten meiner DSL Leitung kann es nicht liegen.Ich habe Arcor DSL3000 mit 384er Upstream ( Fritz zeigt 3136/416 netto, die haben mir wohl ein paar Bit dazugegeben..;-) ), FastPath mit sehr guten Pingzeiten ( schnellster Ping zu einem Server 10ms) und gute Leitungswerte ( 22/13 db).Also kann man wohl feststellen, das das TrafficShaping wohl nicht
funktioniert, bzw. nicht gut genug funktioniert, um störungsfreie VoIP Verbindungen zu haben.Ich werde da wohl keine weiteren Gedanken dran verschwenden, bin übernächste Woche in den Staaten drüben und werde mir viellleicht von da einen VoIP Router mitbringen.Schade eigentlich, ich habe selten ein Gerät gesehen, das so unrund wie die Fritz Fon läuft.

Grüße

TWELVE

 

[KiRKman]

@TWELVE: Das deckt sich haargenau mit meinen Erfahrungen! Danke vielmals für das Update.

Mich kann man bei geringerem Upload natürlich auch mit etwas gutem Willen bei Sipgate noch verstehen, aber der Effekt ist trotzdem unüberhörbar.

Zu Freenet kann ich jetzt nichts sagen, aber dort soll es nach mehreren Aussagen ja viel besser sein. Bei GMX und Nikotel habe ich auf jeden Fall gar keine Probleme!

Die Probleme mit dem Gehacke auf der Festnetzseite treten auch auf bei SipSnip und bei Anrufen auf Stanaphone und IPkall. Bei abgehenden Anrufen von Stanaphone keine Probleme.

Laß Dir in den USA keinen LinkSys-Router mit eingebauter VoIP-Komponente von Vonage andrehen. Die werden momentan dort im großen Stil angeboten; und LinkSys ist ja auch normalerweise supergeiles Equipment. Aber das Teil von Vonage ist gelocked, da kommst Du nicht in's VoIP-Menü rein. Das kann man dann nur mit Vonage nutzen, echt furchtbar. Ich weiß, das ist jetzt hier total off-topic, aber da die von Vonage das in den USA im Moment so extrem forcieren, wollte ich diese Warnung aussprechen. Ein Kumpel in Norfolk VA hat sich letzte Woche dennoch so ein Teil gekauft, da ist nix zu machen, echt übel...

 

[TWELVE]

Ah danke für die Info, hatte die Vonage Teile auch beim Staples rumstehen sehen letztes Mal und dachte mir doch tatsächlich, das ich so ein Teil billig abneppe.Kannst Du hellsehen...? *ggg* Aber da wird es doch sicher eine Möglichkeit geben, da eine Org.Firmware reinzuschießen...? Sollte ich mir jetzt so ein Teil mitbringen, nur um wieder was neues zum spielen zu haben...?..

GMX hat das Gehacke nicht...? Und wieso bin ich dann nicht bei GMX registriert...? Achso erinnere dunkel, bin vor der Festnetznummern-Registrierung zurückgeschreckt...;-) Sonst was negatives bei GMX...?

Grüße

TWELVE

 

[KiRKman]

Die Festnetz-Registrierung ist recht harmlos. Dabei geht es nur darum, die Caller-ID zu verifizieren. Denn man schickt bei abgehenden Rufen in's Festnetz über GMX immer die Anrufkennung mit, die man zuvor angemeldet hat. Das geht aber auch mit geographischen Nummern von Sipgate oder Nikotel Einziger mir aufgefallener Nachteil: man muß bei GMX die Bankverbindung hinterlegen. Das ist eben ein postpaid Service. Die schicken die Rechnung monatlich als PDF per E-Mail. Danach wird der Betrag vom Konto abgebucht. Dabei gab es bei mir aber noch nie Probleme. Das muß man bei einem Preis von 1 Cent pro Minute rund um die Uhr in's Festnetz (ohne spezielle Tarifoption) dann wohl hinnehmen.

Weiterer Nachteil bei mir war, daß ich noch keinen GMX-Account hatte. Ich mußte mich also quasi nur für VoIP bei denen registrieren. Naja, das war ja nur ein kurzer Moment Arbeit. Aber nun habe ich eine E-Mail-Adresse bei denen, die ich gar nicht brauche Du scheinst aber eh schon einen GMX-Account zu haben, also schalte am besten noch Deine Festnetz-Nummer oder eine Deiner geographischen Nummern beispielsweise bei Sipgate frei. Das geht dann halt schnell, kostet nix, und man muß eben nur die Bankverbindung angegeben haben...

Man muß bei dem Verifizierungs-Anruf übrigens einen PIN-Code eingeben, den man vorher genannt bekommt. Das klappt über Sipgate nicht immer auf Anhieb, da die Touchtones da mitunter nicht so gut rüberkommen. Ggf. neu probieren, falls es schief läuft. Geht aber auf jeden Fall! Dann brauchst Du auch gar keine Festnetznummer für GMX-VoIP preiszugeben.

Wegen LinkSys/Vonage evtl. mal den Artikel hier (s.u.) lesen. Wir haben noch nix zum "Unlocken" gefunden... Mein Freund wird das Teil beim Händler zurückgeben, das ist ja in den Staaten kein Problem
http://voxilla.com/voxstory88-nested-order0-threshold0.html