Beiträge von wahndreieck

Zitat von jap.net

Klar geht es problemlos, halt ohne VoLTE und WLAN Call

Klar, mir ging es darum da die Listen ja teilweise was anderes sagen wie es wirklich aussieht. Hast du es getestet mit einem G34 5G ?

Zitat von CKrummi

Habe eben Mal nachgeschaut:

Moto G34

VoLTE geht nicht

Vo5G geht nicht

VoWifi geht nicht

Ich hatte überlegt mir das G34 als Zweithandy zuzulegen.

Abseits der Kompatibilitätslisten, hat es mal einer mit GMX FreePhone getestet ?

Ich hab das derzeit nicht.

Verwendest du IOS oder Android ?

Für Android zunächst bei den Apps die betroffen sind die Akku Optimierung deaktivieren und schauen ob es was bringt.

Ansonsten kann das auch normales verhalten sein. Push Nachrichten können mit unterschiedlichen Prioritäten gesendet werden.

Interaktive Nachrichten/Apps kommen mit Hoher Priorität und wecken das Gerät auf (z.B Voip Apps oder Messenger). Andere Apps senden mit normaler Priorität, die werden zugestellt wenn das Smartphone selbst aus dem Deep sleep aufwacht um den Akku zu schonen.

hrgajek 1&1 hat sich bei mir gemeldet. Die TCP Timer sind Bundesweit angepasst und der Fehler damit behoben. Letztlich das was wir ja gestern auch beobachtet haben.

Ja 10 Min ist schon ganz gut. Aber eher das unterste Limit.

Ich würde Werte wie die typischen home CPEs nehmen.

Fritzboxen z.B haben.

TCP 900 Sekunden (15 Minuten)

UDP 300 Sekunden (5 Minuten)

Und für v6 könnte man 3600 Sekunden (1h) nehmen.

Das dürfte für die meisten Dienste passen.

Kann man nur spekulieren.

- Vielleicht tatsächlich ein Regionales Problem in einem oder mehreren der Core Rechenzentren. Falsche Konfiguration eingespielt oder teile vergessen.

- Endgeräteabhängig, vielleicht nimmt das Netz verschiedene Profile für bestimmte Endgeräte

Kann auch Protokollabhängig sein. Google nutzt für Verbindungen zur seiner Cloud neben TCP teilweise QUIC. Das ist UDP basierend und damit von kurzen Session-Timern weniger anfällig.

Gibt sicher noch x andere mögliche Punkte wo das zerbrechen könnte.

Edit: Fairerweise konnte ich den Fehler heute bisher auch nicht mehr nachvollziehen. Vielleicht hat 1&1 ja tatsächlich nach der Mail von Henning etwas angepasst.

Zitat von kammann

Die IPv4 NAT-Adressen variierten leider nur innerhalb der 61.8.155.x Range, also vermutlich desselben Core Datacenters - so dass diese Aussage vielleicht nicht allgemeingültig für das gesamte 5G Netz von 1&1 ist - aber ein grundsätzliches Problem lässt sich ausschließen.

Aus dem Kontext lässt sich nur sagen das Problem tritt bei dir nicht auf, daraus lässt sich Grundsätzlichkeit ebenso wenig ableiten.

Zitat

Meine Zeit als App-Programmierer liegt schon etwas zurück, aber spätestens seit Android 8 kann eine App auch keine TCP session über einen längeren Zeitraum offenhalten, um so auf Push-Nachrichten zu warten. Diese werden von diversen Stromsparmechanismen mindestens "schlafen gelegt". Der offizielle Weg zur asynchronen Kommunikation läuft über das "Android Notification API", das mit vielfältigen Netzunterbrechungen klarkommt und dann die jeweilige App wieder "aufweckt".

Auch heute lassen sich die Batterie Optimierungen abstellen (aber ja Standard ist das von dir beschriebene), bei mir ist ist jedenfalls so das die Verbindung zum Google FCM (Firebase Cloud Messaging) abreißt damit klappt keinerlei Push mehr.

Zitat von hrgajek

wahndreieck Bitte eine e-mail (gajek @ teltarif.de) an mich mit allen Details und dem Satz, dass ich Deine Kontaktdaten an 1&1 weiterleiten darf.

Mail hast du, bin mal gespannt ob da was bei rumkommt.

Vielleicht kann hrgajek mit dem Timer Problem auf 1&1 zugehen, Tickets beim Drillisch Support kann man sich jedenfalls schenken?

Insgesamt muss man wohl feststellen das die Technik von 1&1 offenbar selbst andere Netze nutzt sonst wäre ihnen das sicher aufgefallen.

Könnte ein kompatibilitätsproblem mit Gruppennachrichten zwischen Apple Clients und einigen von Carriern eingesetzten RCS Server Software sein.

Telekom und Vodafone verwenden ihre eigenen RCS implementationen, O2 die Google Jibe Cloud.