IP-Telefonie und ihre Tücken

– warum nicht jede IP-Telefonie gleich robust ist

Wer „Telefonie über IP“ hört, denkt schnell: Alles ist doch nur Netzwerk. Ob aber ein kabelgebundenes SIP-Tischtelefon spricht, ein DECT-Mobilteil in einer Multizellen-Umgebung unterwegs ist, ein Smartphone per SIP-Softclient über WLAN/LTE telefoniert oder ein UC-Client wie die STARFACE App oder Microsoft Teams aktiv ist, macht in der Praxis einen gravierenden Unterschied.

Der Grund: SIP ist nur Signalisierung auf Anwendungsebene; Mobilität, Medienpfad-Stabilität und NAT-Durchdringung müssen darunter oder daneben gelöst werden. RTP selbst ist für Echtzeitmedien gedacht, garantiert aber weder QoS noch Zustellung.

Wer zudem nur auf die Anwendungsschicht schaut, kommt leicht zu falschen Schlüssen, denn SIP ist kein Mobilitätsprotokoll.

SIP baut Sitzungen auf, ändert sie und beendet sie. RTP transportiert danach typischerweise den Medienstrom (Audio/Video). Das sagt aber noch nichts darüber aus, wie stabil der Funkzugang ist, ob ein Endgerät seine IP-Adresse behält, wie NAT/Firewall mit wechselnden UDP-Strömen umgehen, oder wie ein aktiver Call beim Netzwechsel weitergeführt wird. Genau deshalb können zwei Geräte beide „SIP“ sprechen und sich dennoch völlig unterschiedlich verhalten – denn die Randbedingungen auf den Layern 2 bis 4 können sich massiv unterscheiden:

• Ein kabelgebundenes SIP-Tischtelefon ist zuverlässig, weil sich unterhalb von SIP fast nichts ändert.
• Ein mobiler SIP-Softclient ist fragiler, weil sich unterhalb von SIP ständig etwas ändern kann: Medium, Link, IPv4-Adresse, NAT-Mapping, UDP-Port, Firewall-Pinholes.

Die Robustheit eines Gesprächs hängt stark von Linkwechseln, IP-Adresswechseln, NAT-Bindings und beteiligten Firewalls ab.

Kommunikationsdienste wie Microsoft Teams wirken oft robuster, weil dort nicht zwei nackte SIP-Peers gegeneinander arbeiten, sondern eine serviceverankerte Kommunikationsarchitektur mit Relays und zentralem Kontrollpfad (dazu später mehr).

Die Technologien im Vergleich

Kabelgebundene SIP-Tischtelefone über Ethernet haben die günstigsten Randbedingungen: kein Funk, kein Client-Roaming, kein Zellwechsel. Das Medium ist stabil, moderne Ethernet-Verbindungen sind im Regelfall vollduplex; das Verhalten ist damit deutlich deterministischer als z.B. bei WLAN.

WLAN-Telefonie ist dagegen ein Funk-LAN mit contention-basiertem Medienzugriff. 802.11 arbeitet mit CSMA/CA, also „listen before talk“, ist halbduplex und hat zusätzlichen Overhead durch Beacons, Acknowledgements und Interframe-Spaces. Außerdem wird der Wechsel von einem Access-Point zum anderen in 802.11 primär vom Client entschieden; Infrastrukturhilfen wie 802.11k/v/r können helfen, nehmen dem Client die Entscheidung aber nicht vollständig ab.

DECT ist dagegen von Hause aus ein Sprach-Funksystem. Standards und Multizellen-Produkte sehen Roaming und Handover explizit vor; Hersteller werben bei professionellen Multizellensystemen entsprechend mit „seamless roaming and handover“. Das ist ein grundlegend anderer Ansatz als bei generischem WLAN mit einem beliebigen Softclient. Unter DECT vs. WLAN hatten wir das bereits zuvor ausführlicher thematisiert.

GSM/LTE/VoLTE/VoWiFi sind ebenfalls Mobilfunksysteme mit eingebautem Mobilitätskonzept. 3GPP beschreibt Mobilität als "vom Endgerät unterstützt", aber netzgesteuert; Handover ist dort ein Kernbestandteil des Systems. Bei nativer Spracharchitektur wie VoLTE/VoWiFi kommen zusätzlich IMS, definierte Ankerpunkte und – je nach Szenario – nahtlose Übergaben zwischen Funkzugängen hinzu. Das ist nicht mit einem beliebigen SIP-Softclient über „irgendeine Datenverbindung“ gleichzusetzen.

Das Kernproblem: Es gibt nicht „die eine Adresse“

Bei SIP/RTP muss man drei Ebenen sauber auseinanderhalten:

1. Die echte Transport-Realität auf Layer 3/4: also die Quell-IP und der Quell-UDP-Port, die ein Paket tatsächlich auf dem Medium hat.
2. Die SIP-Sicht der Signalisierung: insbesondere Via für Antworten und Contact für spätere Requests innerhalb des Dialogs. rport aus RFC 3581 sorgt nur dafür, dass eine Antwort an die Quelladresse und den Quellport der empfangenen Anfrage zurückgeht.
3. Die Medien-Sicht in SDP: c= beschreibt die Zieladresse, m= den Medienport. Genau dorthin soll der RTP-Strom gesendet werden.

Das ist die eigentliche Falle: Die IP/Ports im IP-/UDP-Header, die SIP-Header und die SDP-Angaben können auseinanderfallen. NAT erzeugt genau diese Diskrepanz. Ein Paket kann also physisch von 203.0.113.10:62000 kommen, während im SIP/SDP noch 192.168.1.20:5060 oder eine alte LTE-Adresse steht. Solange diese drei Ebenen konsistent sind, funktioniert Telefonie meist. Sobald sie auseinanderlaufen, bekommt man typische Effekte wie „kein Audio“, „nur einseitiges Audio“, „BYE kommt nicht an“ oder „Call stirbt beim Netzwechsel“.

Was auf den OSI-Layern beim Netzwechsel passiert

Beim Wechsel von LTE nach WLAN oder umgekehrt passiert nicht „nur ein anderes Netz“, sondern meist Folgendes:

• Layer 1/2: Das Funkmedium und der Zugang ändern sich vollständig. Das Gerät verliert den bisherigen Link und baut einen neuen auf.
• Layer 3: Es bekommt typischerweise eine neue IPv4-Adresse und einen neuen Default Gateway-Kontext.
• Layer 4: UDP-Sockets und NAT-Bindings ändern sich effektiv mit; aus Sicht des Gegenübers ist das oft ein komplett neuer Transportpfad.
• Layer 5–7: Der aktive SIP-Dialog und die in SDP ausgehandelten RTP-Ziele wissen davon zunächst nichts. Sie zeigen weiter auf die alte Erreichbarkeit. Das ist keine SIP-Besonderheit, sondern eine direkte Folge daraus, dass SIP/SDP Adressen und Ports explizit beschreiben, während RTP standardmäßig einfach zu den ausgehandelten Zielen sendet.

Wenn sich bei einem solchen Netzwechsel die IP-Adressen, Gateways, etc. ändern, dann kommen Pakete für beteiligte Firewalls plötzlich von anderen Source-IPs und evtl. sogar Interfaces. Die Pakete fallen dann nicht mehr unter "Antwortpaket einer bekannten Session", sondern sind "neu" werden je nach Regelwerk nicht selten verworfen.

Beispiel 1: LTE mit öffentlicher IPv4 → WLAN hinter NAT/Firewall

Nehmen wir an, das Smartphone telefoniert im LTE-Netz und hat dort tatsächlich eine öffentliche IPv4-Adresse. Der Softclient sendet ein INVITE, Bob antwortet, und im SDP steht etwa:

• c=IN IP4 198.51.100.20
• m=audio 40000 RTP/AVP ...

Bob sendet also RTP an 198.51.100.20:40000. Das Gespräch funktioniert.

Jetzt wechselt das Smartphone ins WLAN. Dort hat es lokal vielleicht 192.168.1.50, nach außen aber wegen NAT die Adresse 203.0.113.44 mit einem zufälligen UDP-Port, etwa 62000. Aus Netzwerksicht existiert der alte LTE-Pfad nicht mehr. Bob weiß das aber nicht. Er hat im Dialog noch den bisherigen Remote-Target-Kontext und im SDP noch das alte Medienziel. Deshalb sendet er weiter an die alte Adresse bzw. an die alten Ziele. Das RTP landet also am falschen Ort; in-dialog Requests wie BYE oder re-INVITE gehen ebenfalls auf Basis des bisherigen SIP-Routings weiter. rport hilft hier nur für Antworten auf eine konkrete Anfrage, nicht für bereits etablierte Dialogziele und nicht für den RTP-Pfad.

Damit der Call nicht stirbt, müsste der Client nach dem Wechsel sehr schnell einen gültigen neuen Signalisierungspfad etablieren und erfolgreich ein re-INVITE oder UPDATE mit neuer SDP durchbekommen, oder ein Proxy/B2BUA/SBC müsste den Dialog und idealerweise auch die Medien verankern. Wenn dieser neue Steuerungsschritt nicht rechtzeitig gelingt, läuft der bestehende Audiofluss in Leere.

Beispiel 2: LTE ebenfalls hinter NAT

In der Praxis ist LTE oft gar nicht „öffentlich bis zum Endgerät“, sondern ebenfalls genattet. Dann wird es noch heikler. Der Client kann intern 10.x oder 100.64/10 sehen, außen aber erscheint ein Carrier-NAT mit einer anderen öffentlichen IP und einem gemappten UDP-Port. Wenn der SIP-Stack in Contact oder SDP eine nicht erreichbare Adresse anbietet oder wenn der NAT die Zuordnung je nach Zieladresse/-port verändert, dann sehen die Gegenseite und der Signalisierungsserver nicht mehr dieselbe Erreichbarkeit. RFC 4787 beschreibt genau solche Unterschiede in Mapping- und Filtering-Verhalten von NATs; insbesondere nicht endpoint-unabhängiges Mapping erschwert UDP-basierte Echtzeitkommunikation deutlich.

Dazu kommt der Zeitaspekt: UDP ist verbindungslos. NATs halten Mappings nur für begrenzte Zeit offen. RFC 4787 verlangt zwar mindestens zwei Minuten für allgemeine UDP-Mappings und empfiehlt standardmäßig fünf Minuten oder mehr, aber in realen Netzen ist das Verhalten trotzdem stark implementierungsabhängig. Für VoIP bedeutet das: Ohne regelmäßigen Verkehr oder Keepalives können Signalisierungs- oder Mediapfade schlicht „verdunsten“.

Warum zwei Standard-SIP-Peers unter denselben Bedingungen scheitern können

Der springende Punkt ist: Zwei Standard-SIP-Peers tauschen Reachability-Informationen explizit miteinander aus und verlassen sich dann darauf. Der eine Peer sagt dem anderen über SIP/SDP sinngemäß: „Du erreichst mich für weitere Requests hier“ und „mein Audio schickst du dorthin“. Wenn diese Informationen durch NAT, Netzwechsel oder Portwechsel veralten, gibt es keinen magischen Unterbau, der das repariert. RFC 3581 repariert nur die Rückantwort auf eine Transaktion; RFC 5626 kann clientinitiierte, bestehende Signalisierungsverbindungen und Keepalives nutzbar machen, ist aber nicht dasselbe wie echte Medienmobilität und auch nicht überall implementiert.

Anders gesagt: Ein nackter SIP-Peer-to-Peer-Ansatz ist robust, solange die ausgehandelten Pfade stabil bleiben. Er ist nicht automatisch robust gegen Pfadwechsel während des Calls. Genau deshalb wirkt ein stationäres Tischtelefon so zuverlässig: Es bleibt meist im selben VLAN, mit derselben IPv4-Adresse, ohne Funk-Roaming, ohne OS-seitiges Energiesparen, ohne Mobilitätswechsel und oft mit vorhersehbarer QoS.

Welche Voraussetzungen erfüllt sein müssen, damit SIP und RTP zuverlässig laufen

Ohne STUN und ohne ICE wird IPv4-SIP/RTP zuverlässig, wenn mehrere Bedingungen gleichzeitig erfüllt sind:

1. Die Signalisierung muss einen stabilen, erreichbaren Pfad haben. Das bedeutet in der Praxis oft: Registrar/Proxy/SBC bleibt im Pfad, Antworten laufen symmetrisch zurück, NAT-Bindings werden offengehalten, und bei mobilen Clients werden vorhandene clientinitiierte Verbindungen bevorzugt weiterverwendet.

2. Die Medienadresse in SDP muss wirklich erreichbar sein. c= und m= dürfen also nicht auf eine private oder veraltete Adresse zeigen, wenn die Gegenseite direkt dorthin senden soll. SDP ist ausdrücklich dafür da, die Zieladresse und den Zielport für Medien zu beschreiben. Wenn diese Informationen falsch sind, sendet RTP korrekt — nur eben an den falschen Ort.

3. Das NAT-Verhalten muss „voip-freundlich“ sein. Endpoint-unabhängiges Mapping, vernünftige UDP-Timer und regelmäßiger ausgehender Verkehr helfen. Symmetric RTP — also Senden und Empfangen über dasselbe UDP-Portpaar — wird in RFC 4961 ausdrücklich empfohlen, weil es die Wahrscheinlichkeit erhöht, dass NAT/FW die Rückrichtung akzeptieren.

4. Es darf während des Calls idealerweise keinen unkoordinierten Interface-Wechsel geben. Ein Wechsel von LTE zu WLAN ist aus Sicht eines laufenden RTP-Stroms kein kleines Detail, sondern effektiv ein neuer Pfad mit neuer Adressierung. Wenn man das sauber abfangen will, braucht man eine Architektur, die Signalisierung und Medienpfad aktiv neu verankert oder umschaltet.

Ein VPN kaschiert Netzwerkveränderungen

Beim Einsatz eines VPN zwischen zwei SIP-Peers, können die meisten Veränderungen in den verschiedenen Netzwerkschichten kaschiert werden. Die beteiligten Peers kommunizieren über unveränderte private IP-Adressen. Solange das VPN stabil aufrechterhalten wird, ist auch eine Telefonie darüber möglich. Die Verantwortung für die Stabilität wird in Richtung der VPN-Implementierung verlagert. Diese ist für Re-Connects bei Veränderungen der Netzwerkeigenschaften zuständig.

Warum Microsoft Teams unter denselben Bedingungen oft robuster wirkt

Der entscheidende Unterschied liegt in der Architektur: Teams ist in der Praxis nicht „zwei Standard-SIP-Peers, die sich gegenseitig ihre Medienadressen geben und dann allein klarkommen“. Clients kommunizieren mit Microsoft-365-Diensten in der Cloud. Transport Relays sind integraler Bestandteil der Medienarchitektur.

Daraus folgt technisch: Teams kann sich auf einen zentralen, serviceverankerten Kontrollpfad stützen. Wenn sich die lokale Netzwerkumgebung ändert, muss nicht primär der entfernte Endpeer spontan die neue private/public Tuple des Clients erraten. Stattdessen verbindet sich der Client erneut bzw. weiter mit einem bekannten Dienst, und die Medien können — wenn nötig — über Relays geführt oder neu aufgebaut werden. Das ist kein Wundermittel; auch Teams kann bei schlechten Netzen Calls verlieren. Aber es ist deutlich robuster als ein Modell, in dem zwei Peers direkt auf selbst angekündigte Contact- und SDP-Ziele vertrauen. Diese Robustheit ist also Architekturgewinn, nicht „besseres SIP“.

Noch zugespitzter: Ein Standard-SIP-Call zwischen zwei Peers scheitert oft daran, dass die Reachability-Informationen im Dialog und im SDP veralten. Ein Cloud-UC-Client wie Teams hat stattdessen einen stabilen Dienstanker, Telemetrie, zentrale Medienkomponenten und Relay-Fallbacks. Deshalb kann er Netzbrüche, Pfadänderungen und Firewalls oft besser abfedern.