640
Bearbeitungen
Diskussion:Telekom: Unterschied zwischen den Versionen
Neuer Abschnitt →464XLAT, IPv4-Adresssharing bei NAT'ing und 5G evtl. nicht vollständig kompatibel, Fehlerreport
Rrr56 (Diskussion | Beiträge) (→IPv6 mit anderen Leistungsmerkmalen als IPv4 + APN internet.t-d1.de?: Evtl. Irreführung des Lesers, IPv6-Betrieb seitdem geändert, internet.v6.telekom neuer Standard-APN und -Zugang) |
Alumni (Diskussion | Beiträge) |
||
| Zeile 147: | Zeile 147: | ||
"Hier finden Sie eine Anleitung, wie die Online-Anmeldung auch ohne Zusendung eines Freischaltcodes auf dem Postweg möglich ist." | "Hier finden Sie eine Anleitung, wie die Online-Anmeldung auch ohne Zusendung eines Freischaltcodes auf dem Postweg möglich ist." | ||
Kann ersatzlos gelöscht werden. Funktioniert nicht mehr. Telekom hatte das vor längerer Zeit schon umgestellt. | Kann ersatzlos gelöscht werden. Funktioniert nicht mehr. Telekom hatte das vor längerer Zeit schon umgestellt. | ||
== 464XLAT, IPv4-Adresssharing bei NAT'ing und 5G evtl. nicht vollständig kompatibel, Fehlerreport == | |||
Heute wurde von mir in einem edit folgender Abschnitt aus "Telekom" entfernt:<br/> | |||
Inzwischen wurde die frühere VoIP-Störung im Netz Störung der Sprachübertragung bis zur Unkenntlichkeit ausschließlich '''bei 5G''' bei einer Magenta Prepaid-Karte eingegrenzt (zwei Samsung-Testgeräte und ein Xiaomi-Testgerät, SoCs: Exynos (Samsung), Dimensity (Mediatek) und Snapdragon (Qualcomm), sowie Magenta Prepaid 5G Jahrespaket, Magenta Prepaid-Datenkarte und Tarif Stufe S). Da es bei Telekom Prepaid (Discount), z. B. bei Congstar, kein 5G, sondern nur 4G gibt, ist diese Vertriebsschiene, wie auch aktuelle Tests (März 2023) belegen, von dieser VoIP-Einschränkung nicht betroffen (siehe auch [[Congstar|:Seite zu Congstar:]]). Es besteht eine 5G-spezifische Störung der Sprachübertragung bei Verwendung von SIP-VoIP (vermutlich unregelmäßig durchgeleitete Datenpakete) bei Telekom 5G im NSA-Modus, die meisten VoIP-Dienste sind davon nicht merkbar betroffen und funktionieren normal, einige spezielle aber schon (etwa Sipgate's SATELLITE, siehe Support/Status-Seite [https://status.satellite.me/ :hier:] "Stickied Incidents Dienstag, 24. Januar 2023", hier gelang nur im '''4G-Netz überhaupt eine verständliche Sprachübertragung''', desweiteren SIP-Konnektivitätsprobleme (App "Sipnetic") in derzeit nicht eingrenzbaren Konfigurationen bei anderen Anbietern). In einem Test im März 2023 wurde nach einer Tarifumstellung etwa eine halbe Stunde lang eine unvollständige IP-Verbindung mit 5G hergestellt (nur IPv6 am Endgerät verfügbar, dies ist sonst nicht (am Samsung- oder Xiaomi-Gerät) einstellbar), hierbei trat mit Sipgate's [[Satellite|SATELLITE]] der Fehler one way audio bei Verwendung von six ggü. dem SIP-VoIP-Anbieter auf (man hört nicht, was der von der App und über die 5G-six-Verbindung angerufene Teilnehmer sagt, auch kein Anläutesignal). Dieser (SIPGATE's SATELLITE-) one way audio-Fehler war dabei auch 5G-spezifisch, denn an einem nur 4G-fähigen Endgerät erschien er zuvor als vollständig ge'fix't (wurde nach Entdeckung&Eingrenzung durch Sipgate durch ein App-Update behoben). Mit CLINQ (siehe [[Sipgate]]) | |||
Grund dafür ist, dass mit einer App, die den Datenverkehr aufzeichnet, vermutlich eine valide Eingrenzung des Problems mit 5G Telekom Mobil und verschiedenen SIP-VoIP-Anwendungen gelungen ist. | |||
Es ergab sich folgender Zusammenhang: Wurde bei einer zweiten Verbindung dieselbe IPv4-Adresse (aber mit anderen Ports) verwendet, entstanden die Sprach-Artefakte am Anfang der Sprachübertragung, welche schließlich zum Absturz der App führen und zuvor die Sprachübertragung komplett unverständlich (und teilweise auch instabil, dies galt zumindest für frühere Versionen der App) machen. Wurde eine differente IPv4-Adresse (Sipgate SIP-Server) verwendet, war die Störung nicht vorhanden. | |||
Es wird jetzt vermutet, dass (da das Problem mit allen [[APN|APNs]] der Deutschen Telekom auftritt) die netzinterne Umsetzung von 4 auf six (IPv4 auf IPv6) in 5G hierbei einen Riegel vorschiebt und den Nutzer effektiv auf wieder denselben Port bei mehr als einfacher Verwendung einer "angesteuerten" IPv4-Adresse "zwingen" will. Hierbei geschehen nach dieser Lesart dann Verzögerungen oder sonstige "Unordnung" im IP-Datenfluss, so dass ein Knacken am Anfang der Verbindung (SIP-VoIP-Apps) hörbar ist, Fehler detektiert werden können oder aber eine App wegen dem "Datensalat"/"Überschneidung" ihre Funktionalität vollständig verliert (Sipgate's SATELLITE-App). Grund dafür dürfte die NAT sein. | |||
Dies passt auch zu SIPGATE's Version der Störung auf https://status.satellite.me/ ("Stickied Incidents, Dienstag, 24. Januar 2023"), wo man sich auf ein Anbindungsproblem bei Nutzung von six (IPv6-Zugang der App) konzentriert und sich deshalb wahrscheinlich den Ärger mit der bei 5G irgendwie nicht "passgenau" funzenden NAT'ung in IPv4 einhandelt. Dies passt dann auch zu der oben zitierten Beobachtung mit dem mobilen Internetzugang, der die SATELLITE-App im proof-of-concept auf IPv6 gezwungen hat, woraufhin außer dem von Sipgate selbst eingeräumten (wahrscheinlich zunächst einmal Sipgate-verschuldeten) IPv6-one-way-Audioproblem keine weiteren Probleme vorhanden waren. Sipgate empfiehlt zur Zeit die Verwendung von LTE/4G statt 5G, da hierbei das spezifische IPv4-Problem mit der SATELLITE-App nicht mehr zu beobachten ist. Dies stellt jedoch für zahlreiche Nutzer keine echte Lösung dar, sie hätten dann evtl. ihr Endgerät und ggf. auch den verwendeten Tarif völlig umsonst nach dem Kriterium 5G vorhanden (ja/nein) ausgewählt. | |||
--[[Benutzer:Alumni|Alumni]] ([[Benutzer Diskussion:Alumni|Diskussion]]) 09:09, 28. Mai 2023 (CEST) | |||