[Gelöst] Umstellungen im VoIP-Bereich: STUN jetzt offenbar notwendig

meyergru

Neuer User
Mitglied seit
11 Sep 2005
Beiträge
163
Punkte für Reaktionen
3
Punkte
18
Ich hatte bis vor kurzem ein immer öfter auftretendes Problem mit VoIP bei der Telekom, dass ich nun endlich lösen konnte.
Offenbar bin ich nicht der einzige, ich habe etliche Threads mit ähnlichen Symptomen gefunden, z.B.:

https://www.ip-phone-forum.de/threads/keine-anrufe-aus-telekom-festnetz-zu-sip-grandstream-möglich-mobil-d2-funktioniert.294647/

Das Symptom ist, dass eingehende Telefonate an einem Telekom-VoIP-Anschluß direkt bei Annahme abbrechen, während ausgehende Telefonate an die gleiche Rufnummer einwandfrei funktionieren. Das tritt aber nur in bestimmten Konstellationen auf.

Die Besonderheit ist bei mir (und bei den anderen Betroffenen), dass ein VoIP-Endgerät hinter einem anderen Router eingesetzt wird. Bei mir war das eine Fritzbox 7390 hinter einem Edgemax ER-4. Diese Kombination hat in der Vergangenheit einwandfrei funktioniert, bis vor einigen Wochen ein Kollege mit seinem Handy mich konsequent nicht mehr erreichen konnte, während eingehende Telefonate über das Fetznetz gingen. Seit ca. 2 Wochen gehen nun auch die nicht mehr.

Ich habe alles durchprobiert - vom Wechsel der angebotenen Codecs über die Deaktivierung der HD-Telefonie über Wiederherstellen der Basiskonfiguration (ich hatte Nicht-Standard SIP- und RTP-Ports verwendet) bis hin zum Austausch der Hardware (7490 statt 7390) - alles ohne Effekt.

Die Lösung ist ganz einfach, aber unerwartet: Man muss die VoIP-Zugangsdaten von "Telekom" auf "Anderer Anbieter" umschalten und dann in den erweiterten Einstellungen einen STUN-Server (stun.t-online.de) eintragen, dann geht es.

Warum sage ich, dass das dumm ist? Weil das eigentlich komplett unnötig wäre und bis vor kurzem auch bei der Telekom unnötig war. Die Telekom selbst konnte das schon mal besser als jetzt und ich zumindest hatte nicht erwartet, dass sie an dieser Stelle "verschlimmbessern".

STUN ist nämlich ein Mittel, um bei einem VoIP-Endgerät festzustellen, welche IP nach außen verwendet wird und genau diese IP-Adresse im SIP-"Register"-Aufruf mitzugeben. Ansonsten würde das VoIP-Endgerät hinter einem NAT-Router ja nur seine eigene LAN-IP kennen und diese auch nach außen melden - nur dass diese IP vom Internet aus gar nicht erreichbar ist. Das merkt man dann aber erst, wenn man bei einem eingehenden Anruf diese IP mittels RTP zu erreichen versucht, weshalb der Anruf genau beim Annehmen scheitert.

In der grauen Frühzeit von VoIP war der Einsatz eines STUN-Servers also essentiell, wenn das VoIP-Gateway nicht zufällig mit dem Router identisch war (der kennt ja seine externe IP), wie z.B. bei einer Fritzbox, die gleichzeitig als Router und VoiP-Endgerät genutzt wird.

Seit einigen Jahren sind die meisten VoIP-Provider (darunter bislang auch die Telekom) aber so intelligent, dass sie die im SIP-Register-Aufruf gemeldete IP ignorieren und stattdessen einfach die Ansende-IP verwenden - das ist ja genau die externe IP des Anschlusses. Somit muss das VoIP-Endgerät seine externe IP nicht kennen.

Genau so hat es auch die Telekom bislang gemacht. Offenbar tut sie das jetzt aber nicht mehr und hat Zug um Zug die Software auf Ihren VoIP-Gateways umgestellt oder falsch konfiguriert - zuerst bei denen für einige Mobilfunkprovider und jetzt auf allen oder zumindest den meisten.

Den meisten Benutzern wird das gar nicht auffallen. In der Fritzbox beispielsweise ist die Nutzung von STUN dann unnötig, wenn die Fritzbox selbst auch die Routerfunktion wahrnimmt. Nutzt man eine Fritzbox aber nur als VoIP-Client, enthält die Standardeinstellung für den Provider "Telekom" eben auch keinen STUN-Server. Das ging früher, jetzt aber nicht mehr - deshalb sind viele der Einrichtungsanleitungen inzwischen falsch.

Lösungsmöglichkeiten in dieser Situation:

1. Man trägt selbst den STUN-Server ein.
2. Für AVM: man passt die Standardeinstellungen für den Provider Telekom entsprechend an.
3. Für die Telekom: Stellt das bisherige Verhalten wieder her!
 
Ich bezweifele, dass sich bzgl. NAT-traversal etwas am Plattformverhalten geändert hat.

Wie sah denn die konkrete SIP-Signalisierung im Fehlerfall aus? Wurde der Call direkt nach dem Annehmen (200OK) mit einem BYE beendet? Oder „beschwert“ sich die IMS-Plattform mit OPTIONS, dass sie kein Media (RTP) bekommt?
 
Ich habe das im Telekom-Hilft-Forum schon diskutiert:

1. Ich kann durch An- und Abschalten des STUN-Servers nach Belieben das Problem verschwinden und wieder auftauchen lassen. Es kann als Fakt angesehen werden, dass hier bei mir der STUN-Server in dieser Konstellation benötigt wird. Ganz getreu der Spezifikation ist das ja auch O.K., nur konnte die Telekom das schon mal besser.

2. Einige User haben gesagt, dass sie keinen STUN-Server eingetragen haben und dies auch nach wie vor nicht brauchen. Das ist insofern kein Widerspruch, als auch bei mir nacheinander mehr und mehr VoIP-Gateways das neue Verhalten zeigten - erst die, die für Vodafone-Mobilfunk zuständig waren, jetzt auch die für's Telekom-Festnetz. Da die Gateways regional unterschiedlich sind, kann es durchaus sein, dass andere Gebiete als München (noch) nicht betroffen sind. Am Rande bemerkt betreibe ich einen eigenen SIP-Service, der die übermittelte IP ignoriert und stattdessen die Absende-IP nutzt. Mit diesem gab es nie Probleme.

3. Anscheinend wird in den Fritzbox Default-Einstellungen für den Provider Telekom offenbar manchmal doch ein STUN-Server vorgegeben. Eventuell trat das Problem bei mir nur auf, weil die Konfiguration mehrfach migriert wurde (noch aus Zeiten, da die Fritzbox auch als Router verwendet wurde). Das kann auch von der Firmware-Versions abhängig sein, ich weiß es nicht.

Tatsache ist, dass in der Konstellation Router != VoIP-Gateway bei mir neuerdings der STUN-Server wieder notwendig ist, was er früher nicht war, denn auf meiner Seite hat es: a. keine Konfigurationsänderungen gegeben und b. war es kein plötzlich auftretendes Problem, sondern trat schleichend bei immer mehr VoIP-Gateways der Telekom auf.

Und: ja, ich kann nur unterstellen, dass etwas umkonfiguriert wurde oder andere Software/Hardware eingesetzt wird, aber das ist nach Occam's Razor für mich die einzige plausible Erklärung angesichts der Symptome.
 
Zuletzt bearbeitet:
1. Ich kann durch An- und Abschalten des STUN-Servers nach Belieben das Problem verschwinden und wieder auftauchen lassen. Es kann als Fakt angesehen werden, dass hier bei mir der STUN-Server in dieser Konstellation benötigt wird. Ganz getreu der Spezifikation ist das ja auch O.K., nur konnte die Telekom das schon mal besser.
Kannst Du das immer noch, wenn Du den Edgerouter durch einen anderen Router ersetzt?
 
Das weiß ich nicht und werde ich auch nicht versuchen.

Der Router ist aber händisch auf dauerhafte Port-Weiterleitung konfiguriert (also haben entsprechende Einstellungen zum Offenhalten der Ports an der Fritzbox keinen Einfluss) und greift weder in die SIP-Signalisierung noch in die RTP-Datenströme sein (falls Du ein ALG für SIP vermutest).

Und letztere ist deswegen ziemlich sicher, weil a.) die entsprechenden Module nicht geladen sind ("set system conntrack modules sip disable") und b.) die verwendeten SIP-und RTP-Ports alle Nicht-Standard sind, wie ich schon schrieb (und - um die nächste Frage gleich vorwegzunehmen - auch mit den Standard-Ports lief es nicht).

Belassen wir es doch dabei: Mein Problem ist gelöst - vielleicht hilft der Hinweis jemand anderem, nicht wie ich mehrere Wochen danach suchen zu müssen - insbesondere, weil alles über Jahre schon mal lief.
 
2. Einige User haben gesagt, dass sie keinen STUN-Server eingetragen haben und dies auch nach wie vor nicht brauchen. Das ist insofern kein Widerspruch, als auch bei mir nacheinander mehr und mehr VoIP-Gateways das neue Verhalten zeigten - erst die, die für Vodafone-Mobilfunk zuständig waren, jetzt auch die für's Telekom-Festnetz.
Es macht kein Unterschied, von welchem Ziel / Quelle die Gespräche kommen, denn die P-CSCFs sind immer die gleichen.
Bei unterschiedlichen Zielen verändert sich nur "hinter" den P-CSCFs die I-BCF / I-BGFs. Für das NAT-traversal sind aber die P-CSCFs zuständig.

Du hast aber immer noch nicht geschrieben, was konkret im Fehlerfall schiefgelaufen ist, ob du bspw. überhaupt kein media bekommen hast, oder auf dem falschen Port, oder ob die Calls direkt aufgelegt / abgelehnt wurden?!
 
Ich habe die Traces nicht verfolgt. Die Einträge unter "Sprachübertragung" sehen im Fehlerfall meist so aus:

u3.png

Aber die VoIP-Gateways, die konkret die Verbindung aufnehmen sind nicht immer die gleichen, rein und raus schon mal nicht:

u2.png

und pro Provider/Mobilfunknetz auch nicht:

u1.png

Beim letzten Bild kann man schön sehen, dass das VoiP-Gateway 217.0.6.119 rein und raus funktionierte (bei einer Festnetznummer). Das für die Vorwahl 0170 verwendete 217.0.6.22 funktionierte dagegen eingehend zwei Mal nicht.

Hier sieht man auch, wieso ich erst die Codecs im Verdacht hatte: Es sah so aus, als könne in der einen Richtung keins ausgehandelt werden. Dem war aber nicht so.
[Edit Novize: Alle Bilder auf forentaugliches Miniformat eingedampft, siehe Forumsregeln]
 
Zuletzt bearbeitet von einem Moderator:
Ohne einen Mitschnitt, zumindest von der Signalisierung, besser auch inkl. media (RTP), lässt sich keine konkrete Aussage tätigen, was dort genau vorgefallen ist.
Das ist alles Mutmaßung, ohne PCAP.

Hier sieht es fast als hätte die Fritzbox Probleme die eingehenden Codecs zu verarbeiten, da auf der eingehenden Seite keine Codecs angezeigt werden.

Aber die VoIP-Gateways, die konkret die Verbindung aufnehmen sind nicht immer die gleichen, rein und raus schon mal nicht:

Anhang anzeigen 101109
Die Statistik zeigt nur die Media-Gateways (A-BGFs), einem P-CSCF (Signalisierung) sind oft mehrere A-BGFs zugeordnet. Die IP-Adresse des P-CSCF taucht in dieser Statistik jedoch nicht auf.

und pro Provider/Mobilfunknetz auch nicht:

Anhang anzeigen 101110
Hier sieht es auch wieder so aus, als hätte die Fritzbox Probleme mit den Codecs bei eingehenden Anrufen.
Eine Überraschung wäre dies nicht, da die Telekom mittlerweile alle Codecs aus dem Mobilfunknetz auch ins Festnetz übergibt.
Damit kommt es nun bei SIP über UDP zu UDP Fragmentation. Wenn das Endgeräte nicht korrekt arbeitet, kann es dann natürlich zu Problemen bei der SDP-Verarbeitung kommen, wenn das zweite Paket nicht korrekt empfangen wird. Oder sonstige Probleme mit der Verarbeitung auftreten.
 
Genau die Codecs waren auch meine erste Vermutung, weshalb ich die Liste der Codecs auf den sicher funktionierenden G.711 eingeschränkt habe - wie schon geschrieben mit negativem Ergebnis.

Außerdem kommt es zu keinem RTP Austausch, es wurden 0 Pakete über die RTP-Ports gesendet, auch keine Fragmente, siehe oben die 0-Anzeigen.
 
Wenn die Fritzbox ein Problem mit der Verarbeitung der Codecs bei einem eingehenden Call hat, hilft es natürlich nichts die eigenen Codecs einzuschränken.

Der RTP-Anzeige würde ich nicht trauen, nur ein ungefilterter PCAP kann wirklich aufdecken, was passiert ist.
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
244,872
Beiträge
2,219,904
Mitglieder
371,593
Neuestes Mitglied
Häuslebauer_BW
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.