neue Internet-Schaltung: bei Download funktioniert keine IP-Telefonie

[speedy55]

So ... anscheinend ist es wirklich ein Provider-Problem.
Ich denke einfach mal, dass bei den paar zur Zeit geschalteten Anschlüssen keiner wirklich darauf geachtet hat.
Die meisten nutzen wohl das Internet 'normal' und schieben keine großen Daten hin und her.

Ich habe mich jetzt mit den SIP-Daten von einem Freund über die FritzBox bei 'netcomcity.de' eingeloggt, mit dem gleichen Ergebnis, dass die Telefonie gestört wird.

Also gleiches Problem bei der SIP sowohl über 'vitroconnect.de' als auch über 'netcomcity.de'.
Wir hier schon geschrieben wurde, wäre das wohl ein Problem bzgl. DSLAM oder weiter vorgelagerte Komponenten oder ggf. QoS.
Keine Ahnung, ob hier die Technik irgendeinen Finger krumm macht, wenn ich dieses Problem anspreche.

Bei der vorherigen Telekom, 6MBit, war das jedenfalls nie ein Problem. Hier konnte man den Download laufen lassen, ohne dass jemals die Telefonie beeinträchtigt wurde.

 

[Hayda Ministral]

Keine Ahnung, ob hier die Technik irgendeinen Finger krumm macht, wenn ich dieses Problem anspreche.

Der Trick ist es, nicht "das Problem anzusprechen" sondern ganz schlicht eine Störung zu melden. Der Trick ist weiterhin, sich nicht am Telefon abwimmeln zu lassen sondern darauf zu bestehen dass die Störung beseitigt wird.
Falls sich der Provider nicht in der Lage sieht die Störung zu beseitigen dann könntest Du auf die Idee kommen darauf zu bestehen dass er Dir schriftlich die Gründe darlegt. Du könntest auf die Idee kommen mit dieser schriftlichen Begründung die Bundesnetzagentur und Heises "Vorsicht Kunde" zu fragen was sie davon halten das hier die Routerfreiheit durch die Hintertür ausgehebelt werden soll.

 

[speedy55]

Habe ich gestern auch getan.
Ich habe eine Störung gemeldet und ihnen zusätzlich per Email nochmal alles schriftlich mitgeteilt, was ich auf meiner Seite getan habe und das das Problem irgendwo auf deren Seite liegt im Bezug auf VOIP Priorität.

Abhilfe schafft erstmal NetLimiter. Ich habe vorerst den Downloadspeed um 300kb reduziert.

Ergänzung (10. April 2020)

Mal einige Probleme:
Wenn ich z.B. über Firefox die Open Suse starte, dann funktioniert die Telefonie.
Nutze für den Download z.B. den Torrent, dann funktioniert die Telefonie gar nicht.
Ich nutze einen Cloud-Account beim chin. 115.com. Als Down- un Upload Programm wird ein mod. Chrome-Browser genutzt.
Wenn ich hier mit voller Bandbreite runterlade, dann funktioniert die Telefonie ebenfalls nicht. Erst wenn ich mit NetLimiter den Speed auf 1MB/s festsetze, funktioniert die Telefonie. Auch bei 2MB/s oder auch 1.5MB/s machts Probleme bei der Telefonie, obwohl hier mehr als ausreichend Resourcen zur verfügung stehen.

 

[0x8100]

rein aus interesse könntest du mal capturen. auf der fritzbox das machen:

• http://fritz.box/html/capture.html aufrufen
• Internetverbindung -> auf "start" klicken
• dich selbst anrufen oder anrufen lassen & gespräch annehmen
• auf "stop" klicken, warten bis es fertig ist
• die datei speichern und mit wireshark öffnen

in wireshark nach sip (die signalvermittlung) bzw. rtp (der eigentliche voice stream) filtern und dir die werte in den empfangenen (also die als ziel deine ip haben) paketen anschauen.

hier bei mir kann ich am telekomanschluss sehen, dass normaler internettraffic in vlan 7 mit prio 0 reinkommt, voip dagegen mit prio 5. auch im ipv4 header ist der diffserv wert richtig gesetzt. diese werte braucht z.b. ein dslam um die pakete richtig priorisiert auf die leitung zu schicken.

selbst wenn das bei dir gegeben ist, ist das aber noch kein beweis, dass alles in ordnung auf der netzseite ist. denn ob das entsprechende qos profil z.b. im dslam auch konfiguriert und deinem port zugewiesen ist, kannst du so nicht sehen.

 

[speedy55]

Ich habe eine Aufzeichnung gemacht und im Programm geöffnet. Dann nach 'SIP' gefiltert und bin alle Einträge runter gegangen. Wenn ich das richtig sehe, steht das unter '802.1Q Virtual Lan, PRI: 0, DEI: 0, ID: 7' ... also 'PRI: 0'?

 

[0x8100]

ja, die priorität (beim vlan) ist "pri" bei "802.1Q Virtual Lan".

bei allen (eingehende als auch ausgehende) paketen ist die prio 0? das würde darauf hinweisen, dass voip- und normaler traffic gleich behandelt werden was die priorität angeht. dann ist es auch kein wunder, dass du aussetzer beim telefonieren hast, wenn der downstream ausgelastet ist. ein weiteres zeichen, dass das problem beim provider zu suchen ist.

 

[speedy55]

Ich habe jetzt einfach sämtliche Einträge ohne Filter Zeile für Zeile runterlaufen lassen. Überall ist 'PRI: 0'. Auch mit 'SIP' Filter kann ich nachvollziehen, wann sich mit Vitroconnect verbunden wird und hier sind ebenfalls alle Einträge 'PRI: 0'

 

[speedy55]

Zum Post #4:
Müsste nicht in der Downstreamgrafik neben dem gelben Feld auch noch anders farbige Felder auftauchen wie z.B. Echtzeitanwendungen, priorisierte Anwendungen, ...; halt gleich dem Upstream?

 

[0x8100]

die fritzbox kann nur in richtung upstream priorisieren, auf den downstream hat sie ja keinen einfluss. daher gelten diese ganzen klassifizierungen (echtzeit, priorisiert, normal usw.) nur für den upstream und damit hat eine änderung an dieser stelle auch keinen einfluss auf dein problem.

 

[speedy55]

Alles klar ...
Danke für den Hinweis mit den Paketen. Ich habe dies der Netcom ebenfalls mitgeteilt.

 

[speedy55]

Hallo,

hier gibt es die Antwort vom Techniker:

Da liegt der Fehler, zum einen PRI:0 ist nicht die Priorität sondern ob ein Prio-Bit gesetzt wurde und der Kunde hat als VLAN-ID 7 stehen, was der VLAN der Telekom ist.

PRI:0 steht in dem Fall für best effort!!!
Auszug aus Wikipedia!

Priorisierungslevel

Die Priorisierungslevel werden durch das 3-bit-PCP-Feld folgendermaßen in 8 Level unterteilt:

PCP​	Network priority​	Kürzel​	Traffic-Eigenschaften​
1	0 (niedrigste)	BK	Hintergrund (Background)
0	1	BE	Best Effort
2	2	EE	Excellent Effort
3	3	CA	Kritische Anwendungen (Critical Applications)
4	4	VI	Video, < 100 ms Verzögerung
5	5	VO	Sprache (Voice), < 10 ms Verzögerung
6	6	IC	Internetwork Control
7	7 (höchste)	NC	Network Control

Die oben genannten Empfehlungen wurden in IEEE 802.1Q-2005 revidiert und unter

Unserer Telefonie läuft über den Internet VLAN 132 und nicht 7.

 

[0x8100]

wenn dein provider vlan 132 für voip verwendet, dann frage ich mich schon warum du die 7 empfängst und dass überhaupt voip funktioniert

du kannst in wireshark ja nochmal schauen, ob der filter "vlan.id == 132" dir irgendwelche pakete anzeigt.

 

[speedy55]

Ich habe nun unter der 'Anschlusseinstellungen' -> 'Verbindungseinstellungen für DSL/WAN' -> 'VLAN für Internettelefonie wird benötigt' aktiviert. Dazu habe ich die VLAN-ID 132 und PBit 5 und 7 probiert. Ich nehme an, dass PBit die obige Priorität setzt?

 

[speedy55]

Ebenso wurde unter 'Internetzugang' -> 'Verbindungseinstellungen' -> 'VLAN für den Internetzugang verwenden ' noch eine ID 132 eingegeben.

... ok! In wireshark ist jetzt die ID immerhin 132. Jedoch die Prio immer noch auf 0:
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 132

Wie bekomme ich die denn auf 5?

 

[0x8100]

die priorität ankommender pakete kannst du nicht verändern. sicher dass du vlan 132 für datentraffic nutzen kannst? sollte das wirklich gehen und laut aussage des technikers ist das vlan nur für voip, dann macht der provider da was falsch - komischer verein...

theoretisch ist es möglich, dass der voip traffic mit der richtigen vlan prio am dslam ankommt, dieser das richtig priorisiert UND dabei die prio der pakete auf 0 setzt. technisch möglich, aber unnötig und daher unwahrscheinlich.

die priorität ausgehender pakete brauchst du nicht verändern, da diesem wert im traffic des users nicht vertraut wird. anhand klassifizierungsregeln setzt das z.b. der dslam selber.

 

[speedy55]

... jo! Sollte laut Einrichtungshilfe auf 132 stehen ... https://cdn.marketing-cloud.io/wp-c...ung_Einrichten_der_Fritzbox_V1.3_13012020.pdf

 

[0x8100]

ok, laut der anleitung gehen daten und voip über vlan 132 (bei der telekom ist das die 7). dann muss der provider nur noch voip richtig priorisieren... wie in der mitgeschickten tabelle zu sehen ist, sollten eingehende sip/rtp pakete die vlan prio 5 haben.

 

[speedy55]

Ein Techniker, welcher jetzt mal Ahnung hatte, hatte das Problem zufällig mitbekommen und ist noch spontan abends vorbei gekommen. Das Problem wurde gefunden: Traffic-Shaping ... also das, was ggf. hier schon angesprochen wurde.
Die haben da anscheinend etwas korrigiert, womit immerhin alles seit zwei Tagen problemlos funktioniert.

 

[deo]

Die haben da anscheinend etwas korrigiert, womit immerhin alles seit zwei Tagen problemlos funktioniert.

Hauptsache, der Techniker hat an der Fritzbox nichts korrigiert. Das kann wichtig sein, wenn dir etwas in Rechnung gestellt wird.

 

[speedy55]

Wurde nichts in der FB geändert.
Zudem habe ich ggf. Zeugen, welche die Aussage vom Techniker, dass das Problem in Kassel liegt und nicht bei mir im Haus, belegen können.