Telefonie: Abbruch nach exakt 15 Minuten (900 Sekunden)

[#1]

Hallo liebe Telekom,

hallo liebe Community.

Mich treibt ein seltsames Phänomen um.
Natürlich habe ich zuvor ausgiebig gegoogelt und auch hier gestöbert.
Denn das Problem scheint an sich öfter vorzukommen - nur gibt es bisher keinen verläßlichen Lösungsansatz.

Exakte Beschreibung:
Ich habe einen BNG-Anschluss. Als Telefon verwende ich das Gigaset DX800A im VoIP-Modus.
STUN verwende ich NICHT, da mein bintec RS353jv als Media Gateway das überflüssig macht.
Die Telekom-IP-Telefonie-Daten sind entsprechend im Telefon hinterlegt. Das klappt soweit auch seit langem.
Jetzt das ABER:

Ortsgespräche,  eingehend: brechen nach exakt 15 Minuten ab
Ortsgespräche, ausgehend, ohne Vorwahl: brechen nach exakt 15 Minuten ab
Ortsgespräche, ausgehend, mit Vorwahl: brechen nach exakt 15 Minuten ab
Ferngespräche, eingehend: funktionieren unbegrenzt

Ferngespräche, ausgehend: funktionieren unbegrenzt

Das Verhalten ist reproduzierbar. Es passiert IMMER nach diesem Schema.
Mir fehlt jegliche Fantasie, was ich von meiner Seite aus hier tun kann.

[#2 · Accepted solution]

@Stefan D.

Ja, die Lösung in eurer Wissensdatenbank speichern, damit der nächste Kunde nach mir nicht Monate gefrustet ist. (jetzt bin ich wieder happy)

Problem: VoIP-Gigaset C430A Go an einer Fritzbox 3490 anschließen erzeugt Gesprächsabbruch nach 900 Sekunden.

Lösung: Nicht das Gigaset mit dem Provider "Telekom" konfigurieren, sondern in der Fritzbox einen Telefonie-Account anlegen und das Gigaset mit diesem Fritzbox-Account konfigureren. Damit umgeht man die -in diesem Falle fehlerproduzierende- NAT problematik und die Fritzbox übernimmt die Telefoniefunktion.

[#3]

Welche Box hält denn die Verbindung zum Telekom-Server? bintec oder Gigaset?*

In der fraglichen Box kann man doch sicher an so etwas wie keep-alive rumspielen (das würde ich zunächst mal probieren)

Eigentlich dachte ich ja, dass die bintec Box keine iP-Telefonie macht - aber Du schreibst dass sie MediaGateway wäre.

[#4]

Hallo @Chili-FFM,

Sie haben in der bintec RS353jv das "VoIP PBX im LAN" konfiguriert?

Und die RS353jv läuft mit der Firmware 10.1. Rev. 27 Patch 5 ?

Übrigens: Die bintec RS353jv hat KEIN Media Gateway eingebaut.

[#5]

Wenn du mit "Verbindung zum Telekom-Server"  die VoIP-Strecke meinst, dann ist es das Telefon.
(Ich schrieb ja, dass dort auch die - rudimentären - Telefonie-Einwahldaten abgelegt sind.)
Mir ist bewusst, dass die 15 Minuten den 900 Sekunden entsprechen.
Allerdings ist mir das als Erklärung etwas zu kurz gehüpft, da das Problem nur bei Ortsgesprächen auftritt und eben NICHT genereller Natur ist.

[#6]

---

Sie haben in der bintec RS353jv das "VoIP PBX im LAN" konfiguriert?

Und die RS353jv läuft mit der Firmware 10.1. Rev. 27 Patch 5 ?

Übrigens: Die bintec RS353jv hat KEIN Media Gateway eingebaut.

---

Zweimal JA.
Was das "Media Gateway" angeht: da müsste man vorher mal klarstellen, was genau damit definiert ist.
Wenn damit gemeint ist, ein Analog-Telefon auf VoIP umzusetzen - das hat der 353jv nicht. Spielt in meinem SetUp auch keine Rolle.
Wenn damit zusätzlich gemeint ist (und so verwendete ich den Begriff), dass auch die Telefonie - egal wie angebunden -  entsprechend geroutet und priorisiert wird (das ist es, was sich hinter "PBX" verbirgt) - dann habe ich den Begriff vielleicht nur falsch verwendet.
Bei der älteren Firmware gab es sogar den entsprechend betitelten Menüpunkt, wenn ich mich recht entsinne - der ist so in der Tat nicht mehr vorhanden.

[#7]

Mit PBX ist in dem Fall das Gigaset DX800A gemeint. "Media Gateway" heisst, das sich das Media Gateway beim Provider registriert und die Telefonie in anderer Form (analog, ISDN) für nachgeschaltete Geräte zur Verfügung stellt.

Ansonsten gibt es auch noch Geräte die als Session Border Controller laufen können. Das verwendet man dann, wenn die SIP - Implementierung nicht zum SIP - Server des Anbieters kompatibel ist.

Aber zum Thema: Es gab in einer früheren 10.x - Firmware der RS353jv einen Fehler beim "VoIP PBX im LAN" - Assistenten. Aber wenn es von der Gegenstelle abhängt, das die Gespräche abbrechen, dann scheint mir hier eher das DX800A der Schuldige zu sein.

Ich habe eine RS353jv mit einer Gigaset GO 100 Box bei Kunden im Einsatz, und von dort werden mir keine Probleme berichtet.

[#8]

@Chili-FFM

Ich dachte Du wolltest mit "MediaGateway" möglicherweise ausdrücken

- bintec hat die IP-Telefonie-Zugangsdaten

- bintec hat zwar weder analog noch ISDN-Anschlussmöglichkeiten aber bietet sich selbst als Server fürs Gigaset an, weshalb das Gigaset mit bintec Zugangsdaten (und nicht mit Telekom IP-Telefonie-Zugangsdaten)arbeitet

Dann wäre der Fehler zunächst beim bintec zu suchen gewesen.

Aber es hat sich ja mittlerweile geklärt: Gigaset arbeitet mit Telekom IP-Telefonie-Zugangsdaten

[#9]

So, ich habe die vergangenen Tage noch einmal genutzt und etwas herumprobiert.

Die VoIP Instanz ist das Gigaset DX800A, die dortigen rudimentären Einstellungen sehen wie folgt aus:

Wie man sieht steht die Refreshzeit sogar nur auf 600 Sekunden (und nicht 900 Sekunden = 15 Minuten).
Ich habe den Wert frecherweise mal auf 6000 Sekunden erhöht: das wirkt sich überhaupt nicht aus.

Im Router selbst ist diese PBX Geschichte aktiviert, wirklich einstellen lässt sich da nichts:

Allen Bemühungen zum Trotz ist es bis zum heutigen Tage so, dass die Ortsgespräche nach 15 Minuten (+ oft 8 Sekunden) einfach abbrechen.
Die sofortige Wiederwahl geht problemlos.

Ich muss inzwischen davon ausgehen, dass das eventuell tatsächlich ein Problem auf Seiten der Telekom ist!!

[#10]

Ich verstehe weiterhin nicht weshalb Du in der bintec Box IP-Telefonie einträgst. Das könnte allerdings daran liegen, dass ich die bintec-Box nicht kenne und nicht verstehe, was dieser Eintrag bewirken soll.

[#11]

Es kommt wohl zum Session Timeout, und das Telefon scheint keine Funktionen zu haben um das zu verhindern.

Vielleicht hilft es, in der Firewall unter Richtlinien -> Optionen den Timer für "UDP-Inaktivität" und "Andere Inaktivität" zu erhöhen.

@muc80337_2,

Der Assistent "VoIP PBX im LAN" erstellt zwei NAT - Einträge für die IP - Telefonie.

[#12]

Das eigentlich Verdächtige ist doch, dass es ausschließlich Ortsgespräche betrifft (mein Vorwahlbereich: 069).
Und zwar unabhängig davon, ob ich hier innerorts die 069 vorwähle oder nicht, egal ob ein- oder ausgehend.

Bei Telefonaten (ein- oder ausgehend) mit anderen Vorwahlen tritt dieser Abbruch nach 15 Minuten NICHT auf.

Deswegen muss ich davon ausgehen, dass es nicht am Router liegen kann.
Nur das Telefon kennt seine eigene Vorwahl und könnte deshalb das Verhalten verursachen.
Oder eben der Provider Telekom.

Das alles ist reproduzierbar und ist IMMER so, es sind keine Ausnahmen sondern konstantes Verhalten.

Was ich jetzt mal teste:
Ich werde - mangels anderem IP-Telefon - mal ein Soft-Phone (also ein Programm) auf dem Laptop als VoIP-Client nehmen.
Damit versuche ich, den Fehler einzugrenzen - vielleicht kann ich so rausfinden, ob das clientabhängig ist.
(Nur jedesmal 15 Minuten telefonieren bei jedem Test ist auch etwas ätzend...!!)

[#13]

Das einfachste Softphone ist die Telekom HomeTalk App für Anroid / iOS.

[#14]

Es ist inzwischen wirklich kurios.
Eins vorweg: an den Symptomen hat sich noch nichts geändert.

Was habe ich getan:
Die vom Assistent "VoIP PBX im LAN" erstellten zwei NAT - Einträge für die IP - Telefonie habe ich mal gelöscht.
Es gibt nun im Router überhaupt nichts VoIP-spezifisches mehr (kein NAT, nichts; nur allgemeine Firewall-Regeln).
STUN wird nicht verwendet (nicht vom Telefon und auch der STUN-Handler der Firewall ist aus).
Und trotzdem funktioniert die Telefonie weiterhin einwandfrei - bis eben auf die unveränderte 15 Minuten Problematik bei Ortsgesprächen.

Dass die Telefonie überhaupt noch funktioniert, kann ich mir nur dadurch erklären, dass die Firewall nach SPI arbeitet und daher weiss, welche eingehenden Datenpakete wohin gehören Telefon meldet sich ja beim Provider an und refresht das alle 600 Sekunden).
Die Zeitspannen für das SPI habe ich mal hochgeschraubt, um Seiteneffekte zu vermeiden. Daran kann es aber eigentlich nicht liegen, da die Firewall bei Datenpaketen nicht nach "Orts- oder Ferngespräch" unterscheiden kann.

Was ich jetzt noch mal versucht habe: im Telefon DX800A habe ich - entgegen allen Anleitungen - als Anmeldename die Telefonnummer NICHT mehr "069380xxxx" sondern JETZT "004969380xxxx" eingegeben.
Die Registrierung beim Provider funktioniert damit genauso - mal kucken, ob das irgendwelche Effekte hat.

[#15]

Ganz nebenher habe ich mich nochmal mit dem Thema SIP-Proxy befasst.
Auslösender Gedanke war: wenn ich mehrere IP-Telefone betreibe (Wohnzimmer, Arbeitszimmer etc), dann wäre es doch eigentlich doof, wenn sich alle Telefone separat beim Provider anmelden.

Das Googeln bracht mich zu diesen Seiten:
http://classic.faq.bintec-elmeg.com/faq_bintec_269_sip_proxy_vs_assistent_voip_pbx_im_lan_01_de,5860...
http://faq.bintec-elmeg.com/index.php?title=bintec_RS353jw_-_Hinweise_zur_Abl%C3%B6sung_des_GUI-Men%...

Relevante Zitate:
"Ab Einführung ... 10.1.21 Patch 1 wurde ... das GUI-Menü "VoIP"  mitsamt der darin enhaltenen Proxy-Funktionen komplett entfernt."

Passend zu ""Bedingt also durch die ähnlichen Funktionalitäten ist entweder SIP Proxy oder STUN zu verwenden. "
Heisst es dann auch: "In der VoIP-TK-Anlage selbst muß außerdem für die meisten SIP-Provider die Funktion STUN (Session Traversal Utilities for NAT) aktiviert werden (nicht vergessen!)."

Also teste ich mal damit weiter.
Ich frage mich nur, wie das ein entwas unbedarfterer Endkunde hinbekommen sollte...

[#16]

@Chili-FFM

---

@Chili-FFM schrieb:

Ich frage mich nur, wie das ein entwas unbedarfterer Endkunde hinbekommen sollte...

---

Der hat typischerweise

• entweder einen Speedport und daran nur normale analoge (ggf. ISDN) oder DECT Telefone angeschlossen bzw. eine Fritzbox und kann an der Fritzbox das IP-Telefon anmelden und dann läuft das auch unkompliziert
• oder einen Router aus dem eher Geschäftskundenbereich wie einen bintec und nutzt dann die Kompetenz eines Spezialisten wie z.B. @Kalle2014

Es ist natürlich auch möglich, das mit dem bintec als Herausforderung und eigenes Lernprojekt aufzusetzen und an der Aufgabe selbst zu wachsen.

Und das soll nicht sarkastisch sein sondern ist nur eine nüchterne Betrachtung.

[#17]

Das Telefon ist eher dafür gedacht, an einer IP-fähigen TK-Anlage betrieben zu werden.

Es kommt also immer auch auf die Kombination der Geräte an.

[#18]

---

@Kalle2014 schrieb:

Das Telefon ist eher dafür gedacht, an einer IP-fähigen TK-Anlage betrieben zu werden. 

---

Wie kommst du denn jetzt darauf?
Abgesehen davon dürfte es dem Telefon selbst herzlichst egal sein wo es sich anmeldet: ob beim Provider selbst oder bei einer TK-Anlage mit Proxy.

[#19]

Nein, das ist nicht egal.

Begründung: Wenn noch ein NAT - Router dazwischen hängt, muss das Telefon den Router dabei unterstützen die Telefonie-Session offen zu halten.

Hinzu kommt: Die letzte Firmware Version für das Gigaset DX800A kam im Februar 2015 heraus.

[#20]

---

Begründung: Wenn noch ein NAT - Router dazwischen hängt, muss das Telefon den Router dabei unterstützen die Telefonie-Session offen zu halten.

---

Tut es doch (bzw. kann es, wenn man STUN aktiviert).

---

Hinzu kommt: Die letzte Firmware Version für das Gigaset DX800A kam im Februar 2015 heraus.

---

SIP stammt aus dem Jahr 1999 ( RFC 2543) und hat sich quasi bis 2001 zum nahezu heutigen Stand entwickelt ( RFC 3261).
Von daher ist 2015 ganz sicher kein Grund.

Alle diese Argumente laufen zudem sowieso in's Leere, weil es - siehe mein Grundproblem - bei allen anderen Gesprächen ausser Ortsgesprächen keinerlei Probleme gibt.

[#21]

Es ist wirklich zum Mäuse melken!!!

Ich habe auf dem Router mittels des "PBX im LAN" Assistenten die NAT-Einträge erzeugen lassen.
Bewirken tut das am Ende, dass u.a. für das Telefon ein "full cone NAT" angelegt wird.
Bedeutet, dass nach extern beim NAT-ten ein statischer Port verwendet wird. Soweit so gut.

Am Telefon ist STUN jetzt aktiviert. Mittels STUN müsste jetzt festgestellt werden können, dass da ein full cone NAT werkelt.
Von aussen initiierte Verbindungen könnten jetzt uneingeschränkt an das Telefon gelangen, sobald diese von aussen an die entsprechende IP-Port-Kombination adressiert sind.

So weit, so logisch.
Aber: jetzt klingelt das Telefon nur noch, ein Gesprächsaufbau findet NICHT mehr statt. Man hört sich also nicht mehr.

Mögliche Fehlerquelle:
Ich bin nicht sicher, ob ich im Telefon als STUN Server tatsächlich "stun.t-online.de" eingegeben habe oder fälschlicherweise nochmal die Registraradresse "tel.t-online.de".

Komisch ist aber nach wie vor, dass die Telefonie vorher OHNE das full cone NAT (also mit normalem symmetrischen NAT) und OHNE STUN funktionierte. Und vor allem OHNE Firewall-Regel-Anpassungen (die der "PBX im LAN" Assistent ja zusätzlich auch noch erzeugt hat).

[#22]

Auch wenn es hier inzwischen zu einem Monolog geworden ist - hier meine Fortsetzung.

Telefonie geht inzwischen wieder.
Vermutlich gab es gar kein Problem, nur eine "Verkettung ungünstiger Umstände".
Ich hatte am Telefon erst STUN aktiviert und dann am Router "PBX im LAN" eingerichtet.
Die STUN Prozedur lief also zeitlich vor dem "full con NAT".
Nach STUN im Telefon einmal aus und wieder an ging es dann plötzlich ohne weitere Anpassungen.
Wobei dieser Erklärungsversuch etwas hinkt, denn es gibt standardmäßig einen STUN Refresh alle 240 Sekunden und ein NAT Refresh alle 20 Sekunden, so dass die zeitliche Reihenfolge hätte egal sein müssen.

Jetzt kucken wir mal, ob all diese ganze Fummelei sich irgendwie auf das 15-Minuten-Problem ausgewirkt hat.

Nebenbei:
Es war zwischendurch wieder reproduzierbar, dass ohne STUN und NAT-Anpassungen die Ferngespräche gut funktionierten und die Ortsgespräche nach 15 Minuten abbrachen.

[#23]

Et voila!
Die 15-Minuten-Problematik besteht immer noch. Und wie gehabt nur bei Ortsgesprächen.

Liebe Telekom: es wäre nett, wenn ihr euch an einer Problemeingrenzung beteiligt. Merci.

[#24]

@Chili-FFM

Ich würde mir einfach mal einen Speedport besorgen und den ans DSL ranhängen und das Gigaset als analoges Gerät an eine TAE des Speedport und wenn das da genauso ist, dann der Telekom das Problem unter die Nase reiben.

Und wenn das mit einem Speedport nicht so ist, dann ist das Problem zumindest etwas näher eingegrenzt.

[#25]

Oder man nimmt - wenn man schon bei bintec Geräten ist - eine bintec be.IP plus als TK-Anlage und schließt das DX800 dort als Nebenstelle an.

Oder man wendet sich an Gigaset, denn das Verhalten des DX800 ist schon etwas ungewöhnlich.

[#26]

@Kalle2014

Eine bintec be.IP plus ist aber eher aus dem Geschäftskundenbereich und da muss man dann schon aufpassen ob das gesetzliche Widerrufsrecht da gilt. Außerdem würde ich wenn ich die Telekom als "Schuldige" in Verdacht habe nicht einen Dritten durch telefonische/online Bestellung/Widerruf schädigen wollen.

Zudem ist es für Telekom-Mitarbeiter viel zwingender/überzeugender dass es mit einem Speedport funktionieren muss als mit einer bintec.

Wenn es dagegen um eine beabsichtigte Ersatzlösung geht, dann bin ich bei Dir.