Mit welchen Providern klappt Traffic Shaping?

[KiRKman]

Ich habe das vorher auch immer so gemacht, also eingehend Nikotel und abgehend GMX mit der CID von Nikotel Nun habe ich allerdings die Nikotel Flat. Das lohnt sich aber wirklich nur, wenn man wie ich viel in die Schweiz telefoniert und dazu natürlich auch noch viel nach Deutschland (oder auch Österreich). Für die gleichen 20 EUR kann man bei GMX ja theoretisch über 33 Stunden im Monat in's deutsche Festnetz telefonieren... Für die meisten wird also GMX immer noch günstiger sein als die Nikotel Flat.

Schade, daß Sipgate unbenutzbar ist. Ich finde den Sipgate1000 Tarif gar nicht mal schlecht. Auch bieten die wirklich unheimlich viele Ortsnetze für geographische Nummern an. Der Kundenbereich der Webseite gefällt mir auch. Also praktisch alles gut, alles funktioniert, nur Telefonieren kann man nicht haha

 

[gottboss]

Um meine Theorie mit den zu geringen Jitter Buffern zu untermauern hier ein paar Anmerkungen:

Der TrafficShaper der FBox muss irgendwann einmal ein LAN->WAN Paket durchlassen, sonst wäre während eines Telefonats GAR KEIN Surfen mehr möglich.

Kommt jetzt während eines VoIP Telefonats ein Paket aus dem LAN in Richtung WAN in einer Queue des Shapers an die Sendeposition, so entsteht während der übertragung dieses Pakets ins Internet ein Delay für die VoIP RTP Pakete.
Nehmen wir an dieses Paket wäre gleich der MTU Size von 1492 byte.

Bei folgenden Uploadbandbreiten entstehen dabei folgende Delays durch dieses EINZIGE Paket:

- 128 kbit/s = 91 ms
- 192 kbit/s = 61 ms
- 256 kbit/s = 46 ms
- 392 kbit/s = 30 ms
- 512 kbit/s = 23 ms

> Diese Werte drücken NICHT die Latenz der Verbindung, sondern ausschließlich die Latenz welche zusätzlich durch dieses eine Paket verursacht wurde aus! (Also nicht mit dem Ping verwechseln)

D.h. diese Werte entsprechen dem JITTER der VoIP Verbindung, wenn der Shaper so konfiguriert ist, dass er immer nur ein einzelnes LAN->WAN Paket druchlässt und dann wieder genügend VoIP Pakete um den Jitterbuffer des Gegenüber wieder zu leeren.

(Bitte verzeiht mir, dass ich in diesem Vereinfachten Modell davon ausgehe, dass bei Transport im Internet keine weiteren Latenzschwankungen auftreten. Asche über mein Haupt, aber dies würde alles verkomplizieren. Ist ja nur ein Modell)

Naja, jedenfalls muss bei einer 128 kBit/s Upload Datenrate der Jitterbuffer der Gegenstelle mindestens 91 ms Latenzschwankungen puffern können, sonst kommt es zu Dropframes.

Genau daran scheint Freenet (auch Sipgate, ...) zu kranken. Denn: Drehe ich die LAN Verbindung ganz zu, so verschwinden auch die Dropframes. D.h. die Latenzschwankungen im Internet selbst sind meist minimal (wenn die Backbone nicht unterdimensioniert ist)

Ergo: Abhilfe schafft eigentlich nur mehr Upload Bandbreite.
Dies möchte ich meinen voerherigen Beiträgen hinzufügen. DiffServ und IPv6 (also QoS) alleine werden das Problem leider nicht lösen.

 

[KiRKman]

Deine sehr ausführlichen Erklärungen sind einleuchtend! Ich glaube, daß Du mit Deiner Theorie richtig liegst. Allerdings heißt das für uns nichts Gutes. Wir sind darauf angewiesen, daß bei Sipgate und Konsorten etwas am PSTN-Gateway geändert wird. Möglicherweise ließe sich auch eine Verbesserung auf Seiten der FRITZ!Box erzielen, ich wüßte aber nicht welche. Die Änderung der Paketgröße hat das Problem bei mir nur zeitlich verzerrt (schnelleres oder langsameres Hacken, längere oder kürzere Stille), aber keineswegs beseitigt. Vielleicht fällt den Leutz bei Freenet, Sipgate oder AVM ja doch noch was ein; die Hoffnung stirbt ja bekanntlich zuletzt

 

[gottboss]

Nicht unbedingt. Wo ein Problem da auch immer ein Schweinetrick.

Ich habe gerade eine "unsaubere" Lösung gefunden: Die MTU Size für ausgehende Paketet drastisch reduzieren.

Ich habe die MTU Size von 1492 auf geringe 298 reduziert. D.h. die Nutzdaten pro gesendetem IP Paket im PPPoE Rahmen schrumpfen von 1452 auf 258 byte (40 byte IP Header).
Das ist aber nicht weiter tragisch, solange man keinen eigenen Server betreibt. Handelt es sich doch nur um die gesendeten Pakete. Bei Spielen wie CS & Co ist dies sogar von Vorteil - da deren Pakete sehr klein. Klar: Kleine Pakete - kürzeres Delay.

:evil: Ganz wichtig: NUR die MTU für Ausgehende Pakete ändern - NICHT die MTU des Interfaces selbst - SONST könnt ihr weder ordentlich surfen, noch eMail empfangen! Viele Seiten werden dann nicht mehr Ansprechbar sein !!!!!

Wenn ihr einen Linux Router einsetzt lautet die Lösung z.B.:

"ip route change default via (x).(x).(x).(x) dev eth(x) mtu 298"

Kurz: Ich reduziere die maximal zu sendende Paketgröße auf 1/5 der vorherigen Größe. Oder anders: Ich reduziere das maximale Delay pro Paket von 91 ms auf 23 ms. Dies reduziert den Jitter natürlich enorm. Aber nicht täuschen lassen. Die Pakete vom LAN->WAN werden nicht schneller, sondern auf Grund der Fragmentierung und des gestiegenen Overheads LANGSAMER ausgeliefert.

Aber: Bei einem Normalbenutzer wird der Upload ausser für kleine Anfragen und mal ein paar eMails (oder halt P2P) kaum genutzt.
Auch für mich als Poweruser macht sich dies nicht negativ bemerkbar. (Ich hoste natürlich keine Services)
Wer selbst Services bereitstellt dem empfehle ich eh sich näher mit den IP Grundlagen zu beschäftigen.

PS: Diese Lösung ist natürlich nix für den Massenmarkt. Da müssen schon Freenet, Sipgate & Co ihren Admins ein paar Euro Fünfzig mehr bezahlen, so dass diese auch ordentliche Lösungen entwickeln können...

 

[Gag_Halfrunt]

Kleine Anmerkung von mir: Ich hab 416 kbit/s Upload, trotzdem habe ich mit den genannten Problemen massiv zu kämpfen.

Und jetzt noch eine dumme Frage: Wo stelle ich -- wie von Dir beschrieben -- die MTU ein? Wenn ich das richtig verstanden hab, an dem "störenden" PC, oder? Netzwerktechnisch bin ich nicht so bewandert.

Gag

 

[cyberpeter]

Hallo,

nachdem ich vor ein paar Tagen einen Test am Anschluss meines Bekannten gemacht habe, hatte ich am Wochende Zeit und habe an meinem Anschluss noch etwas experimentiert und zwar mit einem anderen Provider für den Internetzugang. Normalerweise habe ich 1&1 im Einsatz und selbst bei großen Up- und Downlaoads bis auf gelegentliche Echos, die aber nur mein Gesprächspartner hört keine Probleme, egal ob nun mit Sipgate 1&1 oder Freenet. Verwende ich jedoch Freenet für den Internetzugang schaut es etwas anders aus. Hier habe ich vor allem bei Sipgate ein Problem. Hier häufen sich die Echos und es kommt zu teilweisen Gesprächsaussetzern und knacken in der Leitung. Bei 1&1 ist dies zwar nicht so dramatisch, aber auch hier hört sich mein Gegenüber wesentlich häufiger selber und das Gespräch scheint subjektiv lange nicht mehr so klar und es knackt auch manchmal, wenn der Down- bzw. Updload beginnt. Selbst ohne sonstigen Internettraffic habe ich den Eindruck, dass die Gesprächsqualität nicht mehr so gut ist. Bei Freenet läßt sich hier so gut wie nichts feststellen. Sobald ich wieder 1&1 als Internetzugang eingestellt habe, war das ganz wie von Geisterhand verschwunden.

Tja, es schein also nicht nur an den schlechten Leitungen zu liegen, wie ich gedacht und geschrieben hatte, sondern des verwendete Internetprovider macht zumindest bei mir eine Menge aus.

Kann das vielleicht jemand bestätigen bzw. hat andere Erfahrungen. Wenn dieses bei mehreren so sein sollte, dann könnte man ja auf einen Verdacht kommen ...

 

[nightsinger]

Ich vermute einfach mal, dass es am Routing der einzelnen Provider liegt. Ich kann das zwar nicht prüfen, da ich selbst kein T-DSL fahre, aber ich denke, dass 1&1 eine kürzere Route zu seinem eigenen VoIP-Service hat als z.B. Freenet - umgekehrt dürfte das selbe gelten.

 

[gottboss]

Kleine Anmerkung von mir: Ich hab 416 kbit/s Upload, trotzdem habe ich mit den genannten Problemen massiv zu kämpfen.

Und jetzt noch eine dumme Frage: Wo stelle ich -- wie von Dir beschrieben -- die MTU ein? Wenn ich das richtig verstanden hab, an dem "störenden" PC, oder? Netzwerktechnisch bin ich nicht so bewandert.

Gag

Wie gesagt - ich denke nicht das VoIP in dieser Beziehung so Marketreif ist wie alle Hersteller behaupten. Mitte der 90er haben ja schon die Globalplayer von VoIP und fertigen Geräten geredet, obwohl nicht nicht einmal fertige Konzepte existierten.

Ich habe einen QoS Router zwischen FBox und LAN gehängt, der die max. Bandbreite für den Upload um den Betrag einer G.726-32 Verbindung reduziert. Somit beuge ich einem Überlauf des Puffers in der FBox vor.
Dann habe ich in der FBox die das Verhältniss von VoIP zu normalem IP Traffic auf 100 zu 0 gesetzt. D.h. es kommt zu keinem Stau der VoIP Pakete (und dank QoS vor der FBox wird die kleine FBox auch nicht überlastet.)
Zusätzlich habe ich die MTU für Pakete aus dem LAN ins WAN auf 1/5 reduziert, um Delays zu verringern.

Das ganze klingt recht einfach - man sollte sich aber schon gut mit der Materie auskennen, wenn man eine derartige Lösung implementieren will.
Und ohne Linux oder BSD geht es natürlich auch nicht.

Dass es bei mir wunderbar klappt liegt einfach daran, dass genau das finden derartiger Lösungen mein Job ist. Wäre ich darin nicht gut, so sollte ich über einen anderen Beruf nachdenken.
Aber genau deshalb ist VoIP derzeit im Massenmarkt noch problematisch: Es kann nicht nur IT Consultants geben. Dann würde die Menschheit kurzfristig aussterben.

 

[gottboss]

Ich vermute einfach mal, dass es am Routing der einzelnen Provider liegt. Ich kann das zwar nicht prüfen, da ich selbst kein T-DSL fahre, aber ich denke, dass 1&1 eine kürzere Route zu seinem eigenen VoIP-Service hat als z.B. Freenet - umgekehrt dürfte das selbe gelten.

Ja, das Problem sind wohl überlastete Backbones einiger 'billig' Provider. Ist traurig ist aber so.
Traurig ist das Freenet noch nicht einmal die eigenen IPhone Pakete bevorzugt behandeln kann. :roll:

Eine schöne Lösung kommt evtl. bald von QSC. Einfach mal reingucken. :idea:

 

[TWELVE]

Ich dachte, das interessiert mich jetzt doch mal und da habe ich mal mit der Capture Funktion der Fritz einen Packet Trace der PPPoE Seite gemacht, während ich Upload erzeugt habe und gleichzeitig über VoIP telefoniert habe.

Ich konnte zwischen den Traces für sipgate und gmx keine großen Unterschied feststellen.Schöne, immer gleichlange Pakete ( 302 Byte PPPoE), schön in Sequence und immer der gleiche Codec.Die Paketlänge ist deutlich unter den möglichen 1492, und hier hat GottBoss glaubich einen Denkfehler in seiner Rechnung, da er den Upload durch Pakete von 1492/1500 geteilt hat. Dies würde natürlich einen Offset von z.B. bei 28ms( 414kbit) ergeben, aber die Pakete sind wesentlich kürzer, weshalb das so nicht mehr hinkommt. Ich habe mal gezählt, wie so die Paketsequenz ist.Bei Sipgate z.B. :

1,3,5,1,1,2,2,1,2,5,1,1,2

Bedeutet folgendes: Nach dem ersten VoIP Paket ist direkt das nächste wieder für VoIP, dann erst wieder das 3., danach erst wieder das 5. und so weiter.Der größte Abstand waren also 5 Pakete, solange wurde maximal
kein VoIP Paket zum Server gesendet.Daraus kann man aber noch nicht allzuviel ableiten, da die Nicht-VoiP Pakete ja ganz andere und variable Längen haben können.Bei dem einen 5er Offset war der Abstand 1688 Bytes.Ganz im Gegenteil, zu dem was man jetzt vermuten könnte, nämlich, das der Abstand der VoIP Pakete bei GMX nun gegenüber sipgate geringer
wäre, war der Paketabstand bei gmx sogar noch größer:

9,1,7,1,1,3,8,4,1,5,1,4

Das muß man allerdings relativ sehen, da der erste 9er Abstand nur 668 Bytes beinhaltet, während in dem 7er Abstand 1840 bytes über die Leitung gingen.Entscheidend ist denke ich die zeit, die zwischen zwei VoIP Paketen vergeht.Die sieht sowohl bei sipgate als auch gmx gleichmäßig aus.
Auf jeden Fall ist das Ergebnis für mich nicht ganz schlüssig:

- bisher dachte ich, der Trafficshaper arbeitet auf Paketbasis.Dies kann
ich hier irgendwie nicht erkennen.Entweder arbeitet der Shaper nicht
richtig, oder ich habe den Alghorithmus noch nicht erkannt.

- wenn ich die Traces von sipgate und GMX vergleiche, dann müßte
meiner Logik nach die Qualität bei GMX sogar noch schlechter sein.
Auf jeden Fall kann ich nicht erkennen, das der Shaper bei GMX besser
oder anders arbeitet - wenn er denn überhaupt arbeitet.

- der Codec scheint bei Sipgate und GMX identsich zu sein
rtp.p_type = .000 1000 = Payload type: ITU-T G.711 PCMA

- die durchschnittlichen Ping-Antwortzeiten ( heavy traffic) sind bei sipgate am besten, gmx liegt in der Mitte und freenet hat die schlechteste.

Ich werde das ganze nochmal ohne TrafficShaper probieren, mal sehen, wie sich das Ganze unterscheidet.

Grüße

TWELVE

 

[gottboss]

Danke für deinen ausführlichen Beitrag!

Im Prinzip sollte bei einem TrafficShaper sowohl die Zeit (Paketgröße), wie auch die Anzahl der Pakete eine Rolle spielen. Es wäre ja "unfair", wenn ein Sender von 100 großen Paketen gleich einem Sender von 100 extrem kleinen Paketen behandelt werden würde.

Allerdings habe ich die Vermutung, dass der FBox Shaper hier leider doch unsauber und daher "unfair" arbeitet. Denn: Deaktiviere ich den Shaper vor dem Shaper (klingt lustig, ist aber so), so bekommt die FBox massive Probleme, da mehr Pakete geshapt werden sollen als die Software/Hardware im aktuellen Stadium behandeln kann, dann wird das Shaping uneffektiv. Die Lücken zwischen den einzelnen VoIP Paketen werden dann Zeitlich zu groß. GMX gleich hier mit Empfangspuffern aus. Ich spühre diese in Loopback-Tests sehr deutlich - klar, alles über 25 ms hört man!

Ich konnte zwischen den Traces für sipgate und gmx keine großen Unterschied feststellen.Schöne, immer gleichlange Pakete ( 302 Byte PPPoE), schön in Sequence und immer der gleiche Codec.Die Paketlänge ist deutlich unter den möglichen 1492, und hier hat GottBoss glaubich einen Denkfehler in seiner Rechnung, da er den Upload durch Pakete von 1492/1500 geteilt hat. Dies würde natürlich einen Offset von z.B. bei 28ms( 414kbit) ergeben, aber die Pakete sind wesentlich kürzer, weshalb das so nicht mehr hinkommt.

Nicht unbedingt ein Denkfehler. Ich schrieb ja dass es sich nur um ein vereinfachtes Modell handelt (daher gehe ich vom Worst Case aus - habe ich zwar nicht geschrieben, meinte ich aber - man darf mir auf die Füße treten):

...Nehmen wir an dieses Paket wäre gleich der MTU Size von 1492 byte.
Bei folgenden Uploadbandbreiten entstehen dabei folgende Delays durch dieses EINZIGE Paket...

Dieses Delay wird natürlich schlimmer, bzw. tritt bei hoher Uploadbandbreite auch dann in dieser Form auf, wenn der TrafficShaper nicht "fair" arbeitet.

Viele Grüße

 

[TWELVE]

Es ist eben nicht so, das man z.B. meinen Upload ( 416Kbit) in ca. 35 Päckchen zu 1492 bytes aufteilen kann und nun annimmt, das das VoiP mindestens ein Päckchen innerhalb einer Sekunde nicht nutzen darf, woraus sich ein Offset von 28ms ergeben würde.Die VoIP Pakete sind viel kleiner als die Max MTU ( ~ ein Fünftel davon =~ 5.6 ms) und viele der anderen Pakete sind sogar noch viel kürzer ( TCP-ACK 62 bytes =~ 1.2 ms) .Bei einer Rate von 100kbit/sec =~12Kbyte/sec. reicht so ein VoIP Paket ( 302 byte PPPoE~260 Bytes Payload) für ca. 21ms.Dann sollte das nächste folgen.Allerdings, und hier hast Du absolut recht, wird die Übertragung
eines Max MTU Pakets mindestens 28ms dauern, womit die eben empirisch
errechnete zeit von 21ms überschritten würde.Dies läßt sich auch gar nicht
verhindern, da ein einmal zur Übertragung zugelassenes Paket ja nicht
nach 21ms einfach abgebrochen werden kann.Insofern glaube ich schon, das der Shaper nur rein Paket-orientiert arbeiten kann, zumindest muß
ein Max MTU Paket als größtmögliche Schweinerei in Betracht gezogen werden.Die Übertragung wird über das rtp-Protokoll abgewickelt, welches
für jedes Paket einen Time Stamp und eine Sequence Number vergibt.
Der VoIP Gateway weiß also, welches Paket er als nächstes erwartet
und merkt, wenn da zwischendurch eins fehlt. Der Time Stamp gibt im Prinzip so eine Art "Sende-Takt" vor.Wäre jetzt die Frage, was der VoIP Gateway macht, wenn das Paket nicht rechtzeitig eintrifft.Ein anfänglich geschaffenes "Pre-buffering"-Polster von sagen wir 100ms wäre ja bald aufgebraucht, wenn nicht zwischendurch "nach-gebuffert" werden kann,
sprich die Daten schneller gesendet werden, als sie gebraucht werden.
Das würde auf jeden Fall gehen, wenn man einen Pre-Buffer von sagen wir 60 ms hat und nach der VoIP-Paketpause dann gleich zwei oder mehr Pakete hintereinander schickt, da ja die Übertragung eines solchen Paketes in einer empirischen Rechnung nur 5.6 ms dauert, aber Gespräch für 21ms enthält.Dann könnte man die Pre-Buffer time sozusagen wieder zurückholen
und hätte sie für das nächste mal Warten/Verzögerung zur Verfügung.Eine
Wartezeit für ein ganzes max MTU Paket ( 28ms) wäre kein Problem , wenn der Gateway mindestens ein Paket im voraus erhalten zwischenspeichern würde.Da stellt sich mir die Frage: Kann der TrafficShaper diese Aussetzer überhaupt verhindern...? Meiner Meinung nach nein.Denn irgendwann wird er mal ein Nicht-VoIP Paket durchlassen müssen, und dieses könnte eine Länge von 1492 bytes einnehmen.Die Fritz kann nicht ein Paket mitten in der Übertragung abbrechen, also wird dieses problem solange auftreten,
solange während eines Gespräches auch anderer Traffic "nach oben" darf.
Selbst wenn diese Situation nur einmal in 1 min auftreten sollte, es würde
für eine Störung sorgen, wenn der VoIP Gateway das "Vorsenden" von Gesprächsdaten nicht unterstützen würde. Also nehm ich mal an, das dies
generell unterstützt wird.Wo kann jetzt der Unterschied liegen zwischen
sipgate und GMX..? Eins scheint auf jeden Fall klar, der D/A Wandler beim VoIP Gateway scheint im Fall von viel Upload und sipgate nicht genügend
Daten zu bekommen, so das Aussetzer entstehen.Wäre jetzt die Frage, ob die Fritz vielleicht nicht genügend Pakete voraus schickt bzw. zuviele der anderen Pakete passieren läßt oder ob der Provider nicht genügend Pre-Buffer Pakete annimmt bzw. diese einfach fallen läßt.Ich mein, ich seh beim Telefonieren deutlich am T-DSL Speedmanager, das die Upload Rate deutlich zurückgeht.Also kann man auch nicht sagen, das der Shaper nicht funktionieren würde.Eine Sache hab ich mir bisher noch nicht genau genug angesehen, und zwar muß der Gateway ja die Pakete auch bestätigen.Wenn er das jetzt nicht tut, bzw. dieses sich wegen Netzwerkproblemen verzögert, dann würde die Fritz nicht schnell genug Pakete nachschicken, um den Buffer zu füllen.Da werde ich wohl noch ein bißchen tracen müssen, um vielleicht dahinter zu kommen.

Noch ne Frage.Was habt ihr in der voip.cfg an den folgenden Werten wie
geändert und was hat es gebracht..?:

jitter {
auto_on = yes;
in_ms = 50;
in_packets = 0;
}
tx_packetsize_in_ms = 0;

Speziell den letzten Parameter finde ich ziemlich interessant.

So, jetzt hab ich meinen Gedanken mal freien Lauf gelassen und einfach beim Denken geschrieben.Diskussion natürlich wie immer willkommen.

Grüße

TWELVE

 

[gottboss]

Eins scheint auf jeden Fall klar, der D/A Wandler beim VoIP Gateway scheint im Fall von viel Upload und sipgate nicht genügend
Daten zu bekommen, so das Aussetzer entstehen.Wäre jetzt die Frage, ob die Fritz vielleicht nicht genügend Pakete voraus schickt bzw. zuviele der anderen Pakete passieren läßt oder ob der Provider nicht genügend Pre-Buffer Pakete annimmt bzw. diese einfach fallen läßt.

Wie gesagt meine ich dass dieser Empfangspuffer zu gering dimensioniert ist - zumindest bei Freenet und Sipgate.

Noch ne Frage.Was habt ihr in der voip.cfg an den folgenden Werten wie
geändert und was hat es gebracht..?:

jitter {
auto_on = yes;
in_ms = 50;
in_packets = 0;
}
tx_packetsize_in_ms = 0;

Speziell den letzten Parameter finde ich ziemlich interessant.

"in_ms = 50" scheint in der SIP Verhandlung die Empfangspuffergröße des PSTN Gateways zu beeinflussen. Beweise habe ich aber keine. Ich meine, dass GMX diesen Wert interpretiert, da ich dort das Delay im Loopbacktest unangenehm erhöhen konnte. Bei Freenet tut sich durch ändern dieses Parameters nix.

"tx_packetsize_in_ms = 0" hatte ich bei meinen Tests mit G.729 auf 20 bzw. 30 ms hochgesetzt um Overhead einzusparen. Jetzt verwende ich allerdings wieder G.726-32, da dieser besser klingt (ist aber erst seit meinem MTU Trick im Gateway möglich).

Habe mal zwei Bilder einer RTP Session angehängt. Beim Bild ohne vorgeschalteten TrafficShaper war ich zu faul die MSS am Gateway für eMule von 248 wieder auf 1492 zu erhöhen. Man möge mir verzeihen - dann wäre der sichtbare Effekt noch viel viel viel Stärker ausgebildet.
(Denn ich helfe ja der FritzBox mittels kleiner Fragmentierter IP Pakete bei der Arbeit - und eMule macht Arbeit)

Wichtig: Ich habe den Shaper der FBox aktiviert gelassen wie er war. NUR den Vorgeschalteten HTB QoS Shaper habe ich deaktiviert.

Und: Sorry für die großen Bilder - habe sie aber stark komprimiert.

 

[KiRKman]

Die Veränderung der Jitter-Werte hat bei mir nichts gebracht, auch nicht das komplette Ausschalten. Ebenso verhält es sich mit dem Erzeugen vom Hintergrundrauschen beispielsweise bei CAPI-Underrun. Aber bei tx_packetsize_in_ms bin ich bis 100ms hochgegangen und merke den Effekt sofort bei Sipgate, wenn ich mich selber anrufe. Die Hacker werden dann zeitlich auseinandergezogen, aber es werden nicht etwa weniger, sondern zwischen den Hackern ist mehr Stille, sprich Aussetzer Das brachte mir also alles leider nichts.

Ich habe allerdings eine interessante Neuigkeit für Euch, die mir neulich aufgefallen ist. Die PSTN-Gateways von Nikotel und GMX scheinen das Hackern schlicht und einfach wegzuoptimieren, aber auch bei EINGEHENDEN Verbindungen!

Wenn ich Upload laufen habe und mich per Sipgate auf dem Festnetz anrufe, höre ich starkes Hackern, wie gehabt. Rufe ich nun meine geographische Nikotel-Nummer an, wird dies von Sipgate natürlich in's PSTN geroutet, ist ja kein internes Gespräch. Dort labere ich auf die Voicemail. Wenn ich mir das nachher abhöre, ist die Qualität glasklar, kein Hackern! Obwohl es sich ja für Sipgate um ein ganz normales Festnetzgespräch handelt; denn die können ja nicht wissen, daß die Nummer bei Nikotel ist. Das Hackern wird doch glatt bei Nikotel wieder beseitigt! Ich habe auch einen Freund auf seiner geographischen Nikotel-Nummer angerufen, der hört auch alles glasklar! Es liegt also nicht etwa nur an der Voicemail! Auch habe ich per Telnet-Logging geprüft, ob die Gespräche wirklich per Sipgate rausgingen, und dies war der Fall!

 

[TWELVE]

@Kirkman:

War jetzt beim Staples und habe mir so ein Linksys PAP2 auf Vonage gelockt geholt.Nicht das ich es unbedingt herausfordern wollte, aber
es sieht im Moment leider so aus: Keine freien (ungelockten) VOIP Adapter in USA erhältlich... Selbst die ungelockte Modell vom PAP2,
der PAP2-NA wurde inzwischen von LInksys aus dem Verkehr gezogen
und kann nur noch erworben ist, wenn man Provider ist und von Linksys authorisiert wurde.Desweiteren höre ich des öfteren, das ISPs SIP-Traffic
blockieren.Unglaublich, oder...? Und das im Land der unbegrenzten Möglichkeiten....

Der PAP2 ist ein schnuckeliges Gerät und gefällt mir sowohl vom Aussehen als auch von der Bedienung her ziemlich gut.Der Lockmechanismus ist ziemlich ausgeklügelt und nur möglich, weil
dies von der Firmware ( welche übrigens von Sipura ist - SPA2000)
schon so vorgesehen ist.Stichwort Provisoning - der Adapter verbindet
sich nach dem Einschalten mit z.B. Vonage und zieht sich dort ein Konfigfile.Dieses ist sowohl targeted ( auf die MAC Adresse gelockt) als
auch encrypted.Da steht dann drin, wie sich das Gerät einstellen soll
und disabled dann z.B. Webinterface und weitere Adminfunktionen.
Dies konnte ich bei meinem Exemplar verhindern ( ), war sogar in der Lage, nach ein bißchen Packetsniffing eine neue Firmware drauf zu laden,
aber der Lock ( Customization) ist immer noch drauf.Scheint so, als würden diese Daten separat gespeichert werden.Ein Reset auf die Factory Settings bringt es leider auch nicht, da dann die Vonage Defaults erneut geladen werden.Clever, Clever...aber noch habe ich nicht aufgegeben,
so gut gefällt mir das Teil... Was man da alles einstellen kann, da ist die Fritz die reinste Krücke dagegen...Sollte ich das nicht hinbekommen,
dann werd ich das Teil wohl leider zurückbringen müssen...

Hab das mal hier geschrieben, auch wenn es off-topic ist hier...


Grüße

TWELVE

 

[markus76]

hier die antwort vom avm-support, um zu zeigen wie weit voip noch von der marktreife entfernt ist:

"Vielen Dank für die Beschreibung. Wir haben die Daten zu diesem Problem
aufgenommen und versuchen den Fehler zu reproduzieren oder weitere
Randbedinungen herauszufinden. Es ist derzeit noch nicht möglich eine
Aussage zu treffen, an welcher Stelle das Problem verursacht wird, und wie
es gelöst werden kann. Wenn der Fehler innerhalb der AVM Hardware bzw.
Firmware liegt und wir ihn reproduzieren können, werden wir darauf so
schnell wie möglich mit einem Update reagieren."

 

[TWELVE]

Naja, das kannste so auch nicht sagen, auch wenn ich Deine Enttäuschung verstehen kann.Das Hackern ist ja kein Bestandteil des SIP
Protokolls, also wird hier irgendwer die Specs nicht einhalten.Man muß - auch wenn es eine Standardantwort von AVM ist - auch AVM die Möglichkeit geben, das Problem nachzustellen und die Ursache zu identifizieren.Leider ist das bei den verschiedenen Kombinationen von VoIP Providern wohl nicht ganz einfach, zum Testen brauchen die dann auch erstmal einen Account dort, und selbst wenn sie einen haben, wer sagt, das der sich genauso verhält wie Deiner..AVM hat ja nie behauptet, das die mit jedem SIP Provider funktionieren und was ist, wenn es morgen 100 neue gibt, wie lange soll das dauern, bis die alle durchgetestet haben..? Und selbst dann könnte wieder jemand kommen, der eine einzigartige Kombination hat, bei der es dann gerade wieder nicht funktioniert.Die haben einfach einen VoIP Chip in ein Gehäuse verpackt, und dieser Chip hält sich an ein Protokoll.Wenn sich alle daran halten, sollte es wohl keine Probleme geben.

Grüße

TWELVE

 

[KiRKman]

@TWELVE: Danke für Deine Infos, die habe ich bereits an diverse Kumpels und Kollegen in den USA "weitergelitten". Bezüglich der dortigen Sperren bei den ISP's müßte das hier recht interessant sein: http://www.heise.de/newsticker/meldung/57105

EDIT: Wegen des Hackerns... Ich gehöre zu den wenigen Leuten, die die Box bei Sipgate gekauft haben! Und ich mußte schnell feststellen, daß die Box mit Sipgate überhaupt nicht funktioniert. Zum Glück konnte ich dann schnell andere Provider finden, mit welchen die Box einwandfrei funktionierte. Habe Sipgate seitdem immer nur noch kurz zum Testen benutzt, aber dort hat sich nie was geändert. Ist meiner Meinung nach total bescheuert, daß ausgerechnet selbige die Box verkaufen, wo die doch gar nicht mit deren Service funktioniert haha Zumindestens nicht mit T-DSL-Providern über ADSL-DSLAM's der T-Com von TI. Dabei is der AR7 von TI. Irre Welt...

 

[TWELVE]

So, erzähl noch mal kurz die Story weiter:

Ich hatte mir also diesen PAP2 beim staples besorgt.Während des Herumprobieren und Sniffens hatte ich dann die Firmware von 2.0.10 auf eine (angebliche..?) PAP2-NA 2.0.13 hochgezogen, weil ich mir davon einen kompletten Reset versprochen hatte.War ja leider Fehlanzeige.Nach dem Upgrade hatte ich noch weniger Rechte und konnte eigentlich nichts mehr machen, als den PAP das ( von ihm so begehrte) spaxxxxxxxxxxxx.xml File ziehen zu lassen.Ich hab es ihm aber nicht direkt ziehen lassen, sondern hab mir das File von Vonages TFTP Server besorgt und versucht, ob ich da nicht was manipulieren kann.Der PAP2
fragt also als erstes eine Datei namens spa<MAC Adresse>.xml an.Diese
Datei ist MAC targeted und encrypted.Als nächstes fragt er dann ein Firmware file namens spa.bin an.Der genau Name ist aber nicht fest und
wird im xml file festgelegt ( von Vonage).Zuletzt war dies die Datei
PAP2-bin-2-00-13-LSb.bin, welche im Ordner +MAC-Adresse liegt, also z.B. +0012172D3818.Für die ganzen Experimente braucht man einen lokalen TFTP Server ( z.B. TFTP32) und einen Bind/DNS Server, damit wir uns selber als DNS eintragen können und dem PAP2 brav antworten, das ls.tftp.vonage.net auf unserem Rechner liegt.Auf diese Art kann man auch
die Upgrades selber starten, und zwar über die URL

http://<PAP2 IP>/upgrade?TFTP://<lokale TFTP IP>/<firmware file>

Auf die gleiche Weise kann man den PAP2 auch veranlassen, sich ein neues Config File zu ziehen.Beim baugleichen Sipura SPA2000 ( den PAP2
baut Sipura für Linksys) funktioniert dies alles genauso, bis auf die Tatsache, das dieser mit .cfg Dateien arbeitet.Für die Erstellung der
.cfg Files gibt es den Sipura Config Compiler, genannt spc.Erst erstellt
man eine .txt Datei, die man mit allen möglichen Parametern füttern kann.
Unter anderem kann man darin auch das Web Admin Passwort festlegen.
Das Provisioning Konzept ist mehrstufig, bzw. kann mehrstufig eingerichtet
werden.Für den SPA2000 braucht man eine spa2000.txt, die man mit dem
spc in die spa2000.cfg umwandelt.Die Datei ist "targeted", sprich über die
MAC Adresse verschlüsselt.Noch keine harte und unknackbare Encryption, aber schon ganz gut.In dieser kann eine Provisioning URL stehen, von wo dann später z.B. die SIP Config geladen wird.Ohne Packetsniffing wissen die Leute hier also noch nichtmal ihre SIP Server.Das scheint hier so üblich zu sein, am besten sollen die Leute gar nicht merken, das das über IP läuft.Das ganze steht und fällt also mit dem Admin Passwort oder dem ominösen spc tool.Leider bekomm ich da meine Hände nicht dran, da es
nur für Priviligierte zugänglich ist.Für die PAP2 gibt es entweder ein eigenes Tool von Vonage oder ein umgeschriebenes von Sipura.
Die Sipura Firmware wurde leider nicht akzeptiert vom PAP2 und es kommt noch besser: Ist das Provisioning erstmal aktiviert, dann akzeptiert die Box nur noch Files, die mit dem gleichen Schlüssel encryptet wurden,
der auch in der Box hinterlegt ist ( "Client Certificate").Der erste Schritt wurde wohl schon bei Sipura in der Fabrik gemacht, also gibt es im Prinzip nur 3 Chancen: Admin Passwort oder unlock-XML-File oder Vonage XML Tool.Eine echt harte Nuss.Mit Sicherheit gibt es da noch eine Backdoor oder Exploits, nur habe ich leider auch nicht die Zeit hier, um soviel Research zu betreiben.Ziemlich gefrustet kam ich auf eine echt scharfe Idee: Ich erlaubte dem PAP2, das Vonage XML File vom lokalen TFTP Server zu laden.Hatte ja sonst keine Optionen mehr.Es trat natürlich genau das erwartete Ergebnis ein: Der Zugriff zum Web UI wurde deaktiviert,
und der Reset über IVR ( über Telefon) wurde mit einem Passwort belegt.
So gänzlich abgewrackt, kam ich auf eine noch kühnere Idee: Ich erlaubte dem PAP2, die Firmware zu laden, die ich vorher in seinem Auftrag bei Vonage besorgt und untersucht hatte.Der Plan war, mitten im Upgrade den Strom zu ziehen.Die meisten flashbaren Geräte haben einen Not-Bootloader im Rom oder einem zweiten Flash, der ein Recovery nach einem fehlgeschlagenen Upgrade möglich macht.Die Idee war also, durch
den Not Bootloader alle settings aus dem gerät zu blasen und in aller Ruhe das Gerät neu aufzusetzen.Der PAP2 war nach dem Steckerziehen sofort tot, rote Lampe an und das wars.Das tat sich überhaupt nichts mehr *lol*
Ok, also Gerät zurück zu Staples geschafft.Dann nach CompUSA gefahren und das gleiche Gerät nochmal geholt.Schließlich war ich noch nicht fertig mit meinen Forschungen.. Bin aber nicht wesentlich weiter gekommen,
morgen will ich ein bißchen ins Wochenende fahren, also hab ich das Teil
heute wieder zurückgebracht.Das Angebot ist hier im Moment etwas mager.Es gibt

- PAP2 Vonage
- Linksys Router RT31P2 Vonage oder AT&T
und einen Single Port ATA von "Packet8".Sah aber häßlich und groß aus,
also hab ich da mal die Hände von gelassen...

Das war's erstmal von der amerikanischen
VoIP Front...

Grüße


TWELVE

 

[KiRKman]

Dann mal schönes Wochenende Mein Freund in den USA hat nun einen LinkSys-Router an seinem Cablemodem dran, sowie einen Sipura SPA-2000 am LinkSys. Der hat sich quasi den PAP2 selber gebaut Er hat sich den Kram irgendwo bestellt, und das wurde auch sehr schnell per FedEx Express geliefert. Ich frage mal nach, wo genau er bestellt hat.