Eine Unterbrechung des Telefonats ist salopp ausgedrückt blöd. Den Grund dafür zu finden, kann im Idealfall einfach sein. Jedenfalls kämpften wir nun recht lange mit einem solchen “Abbruch”-Problem bei einem Kunden.

Zunächst wurde man durch unterschiedliche Angaben mehr oder weniger in die Irre geführt. Mal hieß es, es wäre nur beim Chef, mal betraf es Alle. Lange war nicht klar, in welcher Richtung die Gespräche, die abbrachen, geführt wurden. Gemeint ist: Wurde der Kunde angerufen oder hat er angerufen. Ferner gab es je nach Mitarbeiter/in und dem Geschäftsführer unterschiedliche Definitionen von einem längeren Gespräch, diese lagen zwischen drei Minuten bishin zu mehrere Stunden.

Die Bitte dochmal mitzuschreiben, wann mit welchem Teilnehmer und nach welcher Zeit die Gespräche abbrachen zu notieren, wurde leider nicht erfüllt. Nach langem Hin und Her und ein paar Tests zeigte sich dann in folgender Kombination das Problem:

Rief man jemanden an, wurde das Gespräch nach 15 Minuten + wenige Sekunden unterbrochen. Es spielte dabei keinerlei Rolle, ob man in dieser Zeit wirklich sprach oder nicht.

Mit dieser Erkenntnis dass das Limit bei 15 Minuten, sprich 900 Sekunden, lag, konnte schnell der Rückschluss gezogen werden, das es am Session Timer liegt.

Ein wenig Hintergrund, mal grob ausgedrückt: Das System des Angerufenen prüft alle 15 Minuten, ob das Gespräch noch besteht. Zu diesem Zweck wird im Rahmen des SIP-Protokolls ein Re-INVITE gesendet, bleibt dieser unbeantwortet, wird das Gespräch beendet.

Nun blieb die Frage, warum der Re-INVITE unbeantwortet blieb. Das Naheliegenste ist dabei die Firewall, in dieser Umgebung also eine Securepoint UTM. Die Maßnahmen aus dem Beitrag Securepoint UTM und AskoziaPBX halfen leider nicht, geschadet hat es aber auch nicht.

Mir dämmerte dann eine Aussage aus einer Askozia-Schulung. Sinngemäss lautete diese: “Wenn es irgendwelche Probleme mit der VoIP-Telefonie (bei der Telekom) gibt, dann einfach mal alles in der Firewall was von ‘tel.t-online.de’ kommt Richtung Telefonanlage zulassen.”

Also erstmal wirklich eine solche any-Regel gebaut, getestet und siehe da: Es lebt! Da any-Regeln böse sind, das Ganze dann auf SIP (Port 5060/udp) eingedampft:

Bemerkung: Ggf. muss man noch einen Dienst “sip-tls” mit Port “5061/udp” anlegen, sofern verschlüsseltes VoIP zum Einsatz kommt. Bei der Telekom ist das wohl nur bei (manchen) SIP-Trunks der Fall. Wie man im Screenshot sieht, wird eine 3CX-Telefonanlage verwendet, zuvor war es eine Askozia, davor eine von der Telekom, das Problem wanderte immer mit, selbst als noch statt einer Securepoint UTM eine IPFire verwendet und der Kunde nicht durch uns betreut wurde.

3CX bzw. deren Doku als auch der Firewall-Tester geben an, man solle Port 5060/udp (SIP) und Weitere öffnen. Das würde zwar im Rahmen des geschilderten Problems wohl ebenfalls helfen, ist aber in Sachen Sicherheit nicht unbedingt zu empfehlen. Das kommt natürlich ganz darauf an, welche Funktionen und Dienste der 3CX genutzt werden.

Nach einem abschließenden Support-Call mit Securepoint konnte nichts weiter verschlimmbessert werden. Der Supporter meinte sogar, er habe dieses Problem erst zum zweiten Mal gehabt bzw. gehört.

Quelle:

3CX Forums – Calls are dropped after 15 and 30 minutes

Update 05.04.2019

Bei der Neueinrichtung einer 3CX-Telefonanlage taucht als Server im Telekom-SIP-Trunk-Template “transport-tcp.tel.t-online.de” auf. Direkt zu einer IP-Adresse auflösen kann man den Namen nicht, funktionieren tut es dennoch. netstat vom Debian-Linux der 3CX liefert folgende IP-Adresse als via SIP-Verbunden: 217.0.21.64.

Update 21.05.2019

Beim Vergleich der Einstellungen des Telekom SIP-Trunks bei 3CX fielen mir nun noch folgende Änderungen auf:

• Allgemein
  Registrar/Server/Gateway: Hostname oder IP-Adresse: transport-tcp.tel.t-online.de
  Ausgehender Proxy: leer
• Optionen
  Versand von INVITES an IP-Adresse des Registrars erzwingen: Aktiviert

Offenbar gab es Änderungen an der Provider-Vorlage, bislang wurde bei Registrar/etc. und Ausgehender Proxy “tel.t-online.de” angegeben und “Versand von INVITES…” war deaktiviert.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.