VoLTE: Das "8 Sekunden Problem" und das Bearer Monster

Wir bei sipgate arbeiten ja zur Zeit an VoLTE (Voice over LTE) – also Sprachtelefonie über das 4G Netz. Damit sind wir nun schon seit geraumer Zeit in der BETA-Phase und sammeln mit rund 500 echten Kundinnen und Kunden Feedback. Dabei haben wir festgestellt, dass einige Telefone das Telefonat nach rund 8 Sekunden abbrechen. Das ist zwar gut für die Telefonrechnung aber schlecht, wenn man sich mehr zu sagen hat. So können wir nicht live gehen und somit galt es, die Ursache zu finden und zu fixen. Die Lösung dafür sollte uns rund ein 3/4 Jahr beschäftigen. Was war da los? Wir brauchen Vorwissen und müssen die Grundlagen erklären.

Grundwissen: Bearer im 4G

Im Mobilfunk hat man das Problem, dass auf der Luftschnittstelle zwischen Smartphone und Funkzelle nur begrenzte Kapazität verfügbar ist. Dennoch wollen Mobilfunknetzbetreiber aus wirtschaftlichen Gründen für eine möglichst gute Auslastung ihrer Funkzellen sorgen. So teilt man sich als Smartphoneuser unterwegs die Funkbandbreite einer Zelle mit allen anderen, die dort ebenfalls eingebucht sind. Wenn die Zelle nun an der Kapazitätsgrenze ist, weil dort alle fleißig Netflix gucken, Tiktoks hochladen oder was auch immer, dann hat man als Netzberteiber nun ein Problem: Sprachtelefonie ist ein Basisdienst und sollte immer funktionieren. Es wäre also schön, wenn man für Sprachtelefonie Bandbreite im Funkspektrum reservieren könnte, um zu garantieren, dass Telefonate auch in ausgelasteten Zellen funktionieren und das geht auch: Mit sogenannten „Bearern“.

Ein Bearer ist quasi die „Güteklasse“ der Datenverbindung auf der Luftschnittstelle. Typischerweise verwendet ein 4G fähiges Telefon folgende Bearer:

• QCI 9: Internet
• QCI 5: IMS (Anrufsignalisierung)
  • QCI 1: Sprachdaten

QCI steht für „Quality of Service Class Identifier“ und je niedriger die Nummer, desto höher die Priorität. Netflix, TikTok und Co. verwenden mit QCI 9 den Internet-Bearer und damit die niedrigste Priorität. Für die Signalisierung von Anrufen (SIP Nachrichten wie „INVITE“ aka „Liebes Telefon, hier ist ein Anruf, bitte klingel mal“) laufen über den IMS-Bearer mit QCI 5 auf erhöhter Priorität und bekommen eine gewisse Bandbreite garantiert. Sobald ein Telefongespräch aufgebaut wird, werden für die Sprachdaten ein sogenannter „Dedicated Bearer“ unterhalb des IMS Bearers mit QCI 1  aufgebaut, der die höchste Priorität genießt.

Diese hierarchische Anordnung ist deswegen so, weil diese Bearer auf dem Betriebssystem des Smartphones wieder abstrahiert werden: Der „Internet“ Bearer ist ein eigenes Netzwerkinterface mit eigenen IP-Adressen – ebenso wie der IMS Bearer. Die Telefon-App auf einem Smartphone weiß also vereinfacht gesagt nur, dass ihre Datenkommunikation über das „IMS“ Netzwerkinterface zu laufen hat – sowohl für die Signaliserung von Anrufen als auch für die Sprache. Das macht ein neues Problem auf: Wie unterscheiden wir nun den Sprachverkehr von der SIP-Signalisierung, um die Priorisierung auf der Luft korrekt zu gestalten?

Grundwissen: Paketfilter

Um das zu machen ist in der Nachricht, die den Dedicated Bearer aufbaut (Create Dedicated Bearer) ein Element in dem man einen Paketfilter definieren kann. Man kann hier Regeln definieren, nach denen das Telefon die Pakete aussuchen kann, die über diesen Dedicated Bearer laufen sollen. Die Filter können Netzbereiche, aber auch Portbereiche oder Pakettypen (TCP / UDP) enthalten.

Das ETSI-Dokument TS24.008 in der Version 13.7.0 erlaubt für IPv6 zwei Arten einen Netzbereich anzugeben. Entweder als Netzwerkadresse plus Netzwerkmaske (also 2 x 128 Bit) oder als Netzwerkadresse plus Prefix (also 128 Bit plus 7 Bit). Mit letzterer Option spart man sich pro Filter 15 Bytes, nicht viel, aber man muss ja nicht unnötig Bits durch die Gegend schieben.

Zurück zur Geschichte

Im SIP Protokoll sahen wir bei von dem „8 Sekunden Problem“ betroffenen Geräten gerne Nachrichten wie diese hier:

Das brachte uns ziemlich schnell auf die Fährte, dass das Telefon unglücklich über die Qualität der Medienströme war und somit kamen wir auf die Spur der Dedicated Bearer. Beim Austauschen von Nachrichten zwischen unserem Mobilfunkkern und den Netzelementen unseres Partners, der die Basisstationen betreibt, konnten wir beim Aufbau des Dedicated Bearers eine Fehlermeldung sehen: „Syntactic errors in packet filter(s)“:

Entweder das Telefon selbst, oder eine Komponente zwischen uns und dem Telefon im Netz unseres Partners ist also unglücklich über die Syntax der Paketfilter. Wir erinnern uns: Die sind dafür gut um den Verkehr zu identifizieren, der die Sprache darstellt. Bis zu diesem Punkt gelangten wir recht schnell – in meiner Erinnerung nach dürften hier von den ersten Meldungen über die Analyse bis zu zum Einkreisen des Problems nicht mehr als 2 Wochen vergangen sein. Nun galt es rauszufinden:

• Wer schickt die Fehlermeldung? Das Telefon selbst oder eine Komponente im Netz zwischen uns und dem Telefon?
• Warum ist jemand (TM) mit der Syntax der Paketfilter nicht einverstanden?
  • Machen wir etwas falsch?
  • Oder doch etwa eine Komponente im Netz unseres Partners?

Das rauszufinden sollte mehr als ein halbes Jahr dauern.

Nadel im Heuhaufen

Mit Hilfe unseres Partners kamen wir zu dem Schluss, dass die Fehlermeldung immer vom Endgerät selbst kommt. Dennoch war das Problem schwer einzukreisen. Die Paketfilter waren immer die selben und wir beobachteten, dass es bei einigen Telefonen funktionierte und bei einigen nicht. Dazu kam aber: Manchmal trat der Fehler auch auf bei Telefonen, wo wir definitiv gesehen hatten, dass die Paketfilter vom Gerät akzeptiert wurden. Lange zeit waren wir ratlos. Unser Mobilfunknetz-Partner meinte: Möglicherweise sind die Portranges in den Paketfiltern schuld. Sie würden selbst keine Range, sondern nur einen einzelnen Port signalisieren. Auf der anderen Seite redeten wir mit dem Zulieferer unserer Komponenten und die sagten: Portranges sind OK, das wäre im Standard, aber vielleicht sei IPv6 das Problem. Außerdem könnten sie ihren Kram nicht so schnell umbauen auf Einzelports. Sie rieten uns, IPv6 zu deaktivieren.

Das war für uns aber keine Option denn in Deutschland erzwingt Apple die Nutzung von IPv6 für VoLTE, sonst weigern sich iPhones, überhaupt mit uns VoLTE zu machen. Davon abgesehen: Wenn die Lösung ist, IPv6 zu deaktivieren, ist es immer noch kaputt. Trotzdem schien an der These was dran zu sein: Wir beobachteten, dass das Problem in der Tat immer nur mit IPv6 auftrat. Und wie gesagt: Auch bei Telefonen, von denen wir wussten, dass Sie die Paketfilter mochten, beobachteten wir dass sie manchmal ebenfalls Fehler meldeten. Wir waren ratlos.

Lösungsansatz: Ein eigenes Labornetz

Wir mussten mehr verstehen, was eigentlich im Netz zwischen Telefon, unserem Mobilfunkpartner und uns passiert. Wir entschieden uns, ein eigenes Labornetz aufzubauen. Richtig mit eigener Mobilfunkbasisstation und allem, was sonst noch dazugehört und dieses Labornetz mit unserem VoLTE Netz zu verbinden. Das brachte uns in der Tat dem Verständnis für das Problem einen großen Schritt näher: Einige Telefone waren entweder zu 100% von dem Fehler betroffen oder nie. Aber auch hier die Gemeinsamkeit: Nur mit IPv6. Mit IPv4 waren diese Telefone alle zufrieden und akzeptierten unsere Paketfilter.

Dadurch, dass der Fehler nun deterministisch wurde, konnten wir zwei Dinge ableiten:

1. Wir machen definitiv bei einigen Telefonen etwas falsch. Es gibt Telefone, die in IPv6 mit uns zu 100% unzufrieden sind.
2. Es muss aber etwas im Netz unseres Mobilfunkpartners anders sein, sonst wäre das Ergebnis dort nicht so „schwankend“

Methodisches Testen

Wir organisierten also eine große Tracing-Session mit unserem Mobilfunknetz-Partner. Wir waren bewaffnet mit einem Haufen SIM-Karten, verschiedenen Telefonen (Known Good, Known Bad) und einer Excel-Tabelle mit Call-Szenarien. Wir machten jede Menge Testanrufe: Mal nur mit IPv4, mal nur mit IPv6, mal im Dual-Stack betrieb mit IPv4v6. Zwischen jedem Anruf notierten wir uns das Szenario, Startzeit, Endzeit und das Resultat (Hat geklappt / Telefonat brach ab). Dies machten wir verteilt in verschiedenen Regionen, sowohl in Düsseldorf, als auch in Oldenburg in Niedersachsen, wo einer unserer Remote-Kollegen saß.

Wir ließen uns die Mobilfunk-Trace für die SIM-Karten von unserem Mobilfunkpartner geben und dann fiel uns eine Sache auf: Manches mal wurden die Paketfilter von einem Netzelement im Netz unseres Partners entfernt:

Während wir sie korrekt losgeschickt hatten:

Das erklärte, warum es bei einigen Telefonen manchmal klappte und manchmal nicht: Je nachdem, über welche Netzelemente im Netz unseres Partners der Verkehr lief, wurden die Paketfilter einfach zerstört und somit meldete auch ein kompatibles Telefon immer „Syntactic errors in packet filter(s)“ an uns zurück 🤯. Dennoch: Das Problem kam nur dann vor, wenn IPv6 im Spiel war. Mit IPv4 klappte alles.

Standards lesen hilft

Wir versuchten zu verstehen, was wir falsch machten. Immerhin gab es sowohl Telefone als auch Netzelemente im Partnernetz, die unsere Paketfilter nicht vertragen haben. Zum Glück sind die Standards alle offen einsehbar und wir blätterten in der ETSI TS 124.008 in der die Paketfilter für IPv4 und IPv6 beschrieben stehen. Und zunächst wurden wir nicht schlauer… bis wir durch Zufall feststellten, dass es das Dokument TS 124.008 auch in älteren Versionen gab, und siehe da, in Version 8.19.0 war für IPv6 nur die verschwenderische Variante mit der Netzmaske enthalten (Wir erinnern uns: Grundlagen: Paketfilter). Wir aber schickten die neuere Nachricht mit der Prefixlänge! Das erklärte, warum einige Netzelemente und Telefone, die nur die alte Spec implementiert hatten, diesen Fehler ausgaben.

(Für die Interessierten: Seite 517 in der alten Spec bzw. 702 in der neuen: Dort stehen die validen Paketfilter beschrieben)

Das hier ist der problematische Filter:

Und hier nun der nach älterem Standard:

Wir baten unseren Hersteller nun darum, den alten Standard ebenfalls zu implementieren und uns dazu eine Option zu geben, diesen immer zu verwenden anstelle des neuen. Denn man kann davon ausgehen dass alle Geräte, die die neue Fassung können, ebenfalls die alte unterstützen (kleinster gemeinsamer Nenner).

Fazit

Die Umsetzung durch unseren Zulieferer erfolgte schnell und wir konnten nun endlich das „8 Sekunden Problem“ zu Grabe tragen – keine Abbrüche mehr aufgrund von mangelnder Quality of Service in den Medienströmen 🎉. Das war bisher mit Abstand die härteste Nuss in dem VoLTE Projekt und wir sind froh, sie geknackt zu haben. Der VoLTE Launch bei sipgate rückt damit nun in greifbare Nähe!

Geschrieben von: Christian Berger und Lennart Rosam