[Info] FRITZ!Box 7490 / 7580 FRITZ!OS 6.86-44455/44256 (Update 05.05.) SIP Trunking

Robert T-Online schrieb:

Hmmm ich dachte UPLOAD ??

Zum Vergrößern anklicken....

Ein externer Angreifer müsste bei mir (von einem Server) downloaden, dann geht mein Upload hoch, richtig?

Dann muss der Download mit mindestens 2 gleichzeitigen Verbindungen erfolgen. Beim Download von FritzNAS tritt das Telefonie Problem nicht auf.

wspiess schrieb:

Dann muss der Download mit mindestens 2 gleichzeitigen Verbindungen erfolgen. Beim Download von FritzNAS tritt das Telefonie Problem nicht auf.

Zum Vergrößern anklicken....

Doch! Ich teste nur mit dem NAS! Eine Verbindung (FTP) reicht! Voraussetzung: 10MBit/s müssen's etwa sein (bei meiner Leitung). Das gibt beim Online Monitor eine gerade Linie am oberen Rand der Scala!

FTP kann sein. Habs bisher nur übers Webinterface getestet und da konnte ich es nicht nachstellen.

FTP hat immer 2 Verbindungen
1. Steuerkommandos
2. Download/Upload

Mal nicht nur Theorie, was sowas bedeutet.
Ich bin Fotograf und wenn ich meinen Kunden auf meinen Rechner zu Hause über einen gesicherten FTP-Zugang, Zugriff auf ihre Bilder gebe, fällt bei mir zu Hause das Telefon aus, wenn der Kunde seine Bilder herunterläd (z.B. ZIP-Datei ca. 600MB)
Sowas geht gar nicht.

Eigentlich sollte die FB eine gewisse Bandbreite für Telefonie reservieren, die sie aber auch für den Internetverkehr freigeben soll. Nur wenn ein Telefonat geführt wird, dann ist die fest reserviert. Ich hatte da bisher noch nie Probleme. Selbst wenn Up-und Download voll ausgelastet waren konnte ich noch ohne Probleme ein Telefonat führen.

Zwei Paar Schuhe ... einmal die für RTP benötigte Bandbreite, die (sogar intern auch noch einstellbar in der Höhe) bei einem gerade laufenden Telefonat reserviert wird und einmal der "normale" SIP-Traffic, der zu jeder Zeit die Registrierung der Rufnummern beim Provider aufrecht erhalten muß und dazu einerseits selbst aktiv die Verbindung am Leben erhalten kann (durch regelmäßige Requests, deren Inhalt unterschiedlich sein kann, je nachdem, was der Provider unterstützt) oder auf Requests des "Providers" (die Asterisk-Besitzer mit "qualify=yes" für SIP-Clients kennen sicherlich die OPTIONS-Requests vom Server) auch entsprechend (zeitnah) antworten muß.

Wenn da innerhalb von zwei Sekunden eine Antwort auf einen OPTIONS-Request erwartet wird vom Asterisk (das ist der Standardwert bei "yes"), dann muß die Box eben das Paket auch rechtzeitig senden können und das funktioniert nur, wenn dieser Traffic im Upload korrekt bevorzugt wird (klappt bei vielen Modellen/Konfigurationen ja auch) oder nur so wenig in der Upload-Queue gepuffert wird, daß dieses Paket noch "in time" (und da kommt dann natürlich noch die Latenz im "richtigen Internet" hinzu) beim Provider eintrifft. Ansonsten ist eben "der Anschluß" beim Provider (das kann ja auch der eigene Asterisk-Server sein oder irgendein anderer VoIP-Anbieter) erst einmal bis zum nächsten (turnusmäßigen) REGISTER-Request "abgemeldet".

Jedenfalls werden in der "providers-049.tar" für Telekom-Anschlüsse, die per TR-069 konfiguriert werden können, sogar komplette zusätzliche Regeln für solchen Traffic eingeführt (einfach mal in die "ar7.cfg" dort schauen), um z.B. solchen SIP-Traffic (mit "tel.t-online.de" in der SIP-URI) in eine andere Queue (hier "hrealtime") zu stecken.

Bei den vom Problem hier Betroffenen wird ja offenbar auch anderer Traffic nicht richtig priorisiert (obwohl es sogar für die DNS-Abfragen des "voipd" ebenfalls entsprechende Regeln geben sollte, kommen die wohl nicht durch - zumindest nicht in der Zeit, die der "voidp" nach dem Absenden der Anfrage auf eine Antwort wartet) ... wobei es auch problemlos sein kann (wenn da mehr als ein logisches Interface existiert), daß diese DNS-Abfragen lediglich (wg. einer Fehlkonfiguration, die man sich auch durch den Import von einer anderen (früher verwendeten) Box einfangen kann) auf einem falschen Interface gesendet werden.

Andererseits werden die Betroffenen ja AVM (anders als uns hier) alle diese Informationen zur Verfügung gestellt haben, denn eine vollständige Support-Datei enthält natürlich auch diese Angaben ... aber es bleibt eben doch dabei, daß das Aufrechterhalten der SIP-Registrierung (mit allem dazu notwendigen Drumherum wie DNS-Abfragen für den Registrar des Providers) und das Reservieren der Bandbreite für eine aktives Telefonat, vollkommen verschiedene Sachen sind.

Ich habe die Schnauze so voll. Ich bin immer noch bei der 6.54. damit läuft zumindest bei mir alles tadellos. Sync 104/40. Vollsync geht sowieso nicht mehr. In meiner straße haben alles sonst nur 96/36 oder 102/39.

Ich habe seit 19 Tagen keinen Abbruch und keine Fehler in der Verbindung. Ich habe auch keine Lust mehr zu experimentieren.

Hat die neue Beta neue DSL-Treiber? oder immernoch die aus der letzen offiziellen Version?

Ja, immer noch der 1.148.135.11.

PeterPawn schrieb:

Bei den vom Problem hier Betroffenen wird ja offenbar auch anderer Traffic nicht richtig priorisiert (obwohl es sogar für die DNS-Abfragen des "voipd" ebenfalls entsprechende Regeln geben sollte, kommen die wohl nicht durch - zumindest nicht in der Zeit, die der "voidp" nach dem Absenden der Anfrage auf eine Antwort wartet) ... wobei es auch problemlos sein kann (wenn da mehr als ein logisches Interface existiert), daß diese DNS-Abfragen lediglich (wg. einer Fehlkonfiguration, die man sich auch durch den Import von einer anderen (früher verwendeten) Box einfangen kann) auf einem falschen Interface gesendet werden.

Zum Vergrößern anklicken....

Ich habe hierzu die Box von Grund auf neu konfiguriert und keine Einstellungen importiert. Trotzdem diese Fehler in der Telefonie/PushMail versenden, wenn der Upload ausgelasstet ist.

@penum:
Das war auch nur eine denkbare Ursache, wenn da irgendeine DNS-Abfrage nicht rechtzeitig beantwortet wird ... irgendjemand hatte hier iirc auch DNS-Fehler, die in der Folge zu einem Fehler bei der Registrierung führten.

Ansonsten kann es eben schon einen Unterschied machen, welchen konkreten Eintrag aus der Providerliste man nun für die Konfiguration verwendet hat (oben beschreibe ich ja, daß da unterschiedliche QoS-Settings die Folge sind) und welchen Provider an welchem Anschluß man überhaupt verwendet ... weil eben auch die Frage, ob da eine weitere Verbindung für die Telefonie in Benutzung ist oder nicht, schon wieder das Zünglein an der Waage sein kann.

Ich wollte also - von den verschiedenen Leuten, die hier ja mit Problemen bei ausgelastetem Up- oder Download zu kämpfen haben - niemandem irgendeinen konkreten "Ratschlag" geben ... das geht ohne die Kenntnis der gesamten Konfiguration ohnehin nicht. Aber wenn es immer wieder Probleme mit der QoS-Konfiguration gibt, dann sollte man die eben auch mal "zeigen" ... es gibt in den Provider-Einstellungen durchaus auch die Möglichkeit, daß da QoS-Einstellungen vorgenommen werden, die man bei "Anderer Anbieter" dann leider nicht automatisch kriegt und ggf. - wenn man das Problem selbst lösen oder zumindest näher untersuchen will - von Hand eintragen muß in der eigenen "ar7.cfg".

Nur mal exemplarisch ... in so vielen "Provider-Einstellungen" ist zumindest mal eine "nqos"-Sektion enthalten bei der 113.06.83 (das wird bei einer 06.86 nicht viel anders aussehen - abgesehen davon, daß das meist auch nur bei der Konfiguration des DSL-Anbieters ausgewertet und übernommen wird):
Wenn es dann so offensichtliche Probleme (zumindest würde ich die dort ansiedeln, aber ich kann mich natürlich auch irren) mit den QoS-Einstellungen gibt (den Aufbau der Queues hatten wir letztens irgendwo anders erst beim Wickel), dann muß man vielleicht (sofern man nicht nur auf AVM warten will) auch mal selbst dort nachsehen ... das steht tatsächlich alles in den Support-Daten.

Die Frage ist am Ende sicherlich auch, wieviele Mitarbeiter im 1st-Level-Support bei AVM sich mit QoS an sich und den Einstellungen im FRITZ!OS im besonderen auskennen und wieviele im 2nd-Level-Support dann dazukommen. AVM hat da auch auf dem TBF-Scheduler für das generelle "Regeln" des Upstream-Durchsatzes (der i.d.R. auch nur auf 99% der verfügbaren Upload-Bandbreite angesetzt ist, so daß da noch "etwas Luft" ist) noch einen eigenen Scheduler für "low latency queueing" am Start, auch der könnte durchaus das/ein Problem sein, wenn der nicht richtig funktionieren sollte und seinerseits die höherpriorisierten Queues nicht als erstes komplett leert, wie er das eigentlich machen sollte.

Wenn erst im 3rd-Level-Support dann solche Support-Daten wirklich gründlich geprüft werden (wir wissen ja auch alle hier aus dem IPPF, daß solche Beschreibungen von Fehlern lange nicht immer eindeutig sind und man oft genug auch raten muß, was der "Kunde" da nun wirklich für Probleme haben könnte), dann dauert das eben seine Zeit - deshalb ja die Idee, daß Selbsthilfe manchmal deutlich schneller sein könnte. Zumal es ja offenbar eben lange nicht alle 7580- oder 7490-Besitzer trifft und selbst wenn es zwei mit denselben Symptomen sind, müssen das noch nicht automatisch auch dieselben Ursachen sein.

Ich habe auch lange nicht alle "Meldungen" hier, die in diese Richtung gehen, verfolgt ... aber mein Eindruck ist es eben, daß es (zumindest überwiegend) Telekom-Kunden mit All-IP-Anschlüssen trifft (den Signaturen nach zu urteilen). Ich bin zwar auch Telekom-Kunde, aber mit einem ISDN-Anschluß und trotzdem habe ich in meinen QoS-Einstellungen der 7490 eben (weil ich Telekom als Anbieter beim DSL-Anschluß ausgewählt habe) auch die SIP- und RTP-Priorisierungen, die in diesem Profil vorgesehen sind - vollkommen sinnlos bei mir, weil eben gar keine SIP-Konten "@tel.t-online.de" bei mir existieren, die mit TOS-Flags von 192 in der drittwichtigsten Queue verwurstet werden müssen (andere SIP-Pakete kommen in dieselbe Queue, aber mit TOS 0).

Auch wenn das bei mir nur ein 25/5-Anschluß ist, kann ich problemlos den Upload voll auslasten (bei mir sogar meist mit einer VPN-Verbindung, die ggü. der Datenrate am LAN-Interface noch einen zusätzliche Overhead hat, aber da gibt es auch keine (sichtbare) Drosselung o.ä.) und trotzdem bleibt die Registrierung meiner SIP-Nummern (bei anderen VoIP-Anbietern als der Telekom und am eigenen Asterisk-Server in Internet) aktiv - offenbar funktionieren bei mir die QoS-Einstellungen, obwohl sich ja die Buffer bei meiner Verbindung nur mit der halben Geschwindigkeit leeren sollte, als wenn das eine 50/10-VDSL-Verbindung wäre.

Wareman schrieb:

Die gibt es immer noch. Nur werden die nicht mehr für die breite Öffentlichkeit bereit gestellt, sondern nur für die eingetragenen Labortester. Ein Linkerstellen ist demnach nicht mehr möglich um an die aktuelle Labor zu kommen. Anscheinend hat es da von Seiten AVM's klare Ansagen an die Labortester gegeben. Es wird ja nicht einmal mehr die Buildnummer gepostet. Warum kann man als Aussenstehender nur vermuten.

Zum Vergrößern anklicken....

Und wie kann man dann noch ofizieller Tester werden, eben so wie man bisher immer die Labors von der SEite nutzen konnte?

Bei AVM als Tester bewerben und hoffen das man genommen wird.

Pom-Fritz! schrieb:

Ja, immer noch der 1.148.135.11.

Zum Vergrößern anklicken....

Dann ist sie uninteressant für mich. Mit der 6.54. seit 24 Tagen stabiler Sync mit 104/40. Keinerlei Probleme. Alles läuft.

Neue Version per E-Mail vom Schalker Erwin erhalten: FRITZ!OS 113.6.86-44455
Jetzt auch hier erhältlich: https://service.avm.de/downloads/beta/fritzbox_7490/deutsch/

Na die hätte ich aber auch gern.

Hi,

Ist auch hier verfügbar:

https://service.avm.de/downloads/beta/fritzbox_7490/deutsch/

Gruß
Basti

Ohhh auch ohne Schalker Erwin.

Mensch ey! Und für die 7580 so unerreichar, wie eine Schale für die Schalker ? *scnr*