crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
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.
Gelöst! Gehe zu Lösung.
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.
07.01.2018 15:38
Da ich weder einen Speedport noch einen anderen bintec in der Schublade liegen habe (und auch nicht extra für einen Test kaufen werde) hilft mir das leider gar nicht weiter.
Aber ich habe eben festgestellt, dass über die Update-Funktion des Gigaset DX800A eine neue Firmware-Version verfügbar ist: die Version 175.
Über die Website http://www.gigaset.com/de_de/cms/home/kundenservice/privatkunden/downloads/software/download/listSof... ist die Version 172 die letzte.
Mal schauen...
08.01.2018 21:43
Chili-FFM schrieb: Liebe Telekom: es wäre nett, wenn ihr euch an einer Problemeingrenzung beteiligt. Merci.
08.01.2018 21:59
Wie schätzt Du die Chancen ein, dass der TE im Telekom Shop ein Leihgerät für einen Tag mal zum probieren mitnehmen kann?
08.01.2018 22:06
muc80337_2 schrieb: Wie schätzt Du die Chancen ein, dass der TE im Telekom Shop ein Leihgerät für einen Tag mal zum probieren mitnehmen kann?
08.01.2018 22:07
Keine Angst, ich beisse nicht.
Mit der neuen Telefon-Firmware 175 hat meine Frau heute ein über einstündiges Ortsgespräch geführt.
Ich mag es noch gar nicht recht glauben.
Mir erschließt sich die Systematik dahinter nicht. Die Telefonnummer=Anmeldename ist als 004969380xxxxx eingegeben. Das Telefon sollte also kaum einen Unterschied machen können zwischen Orts- und Ferngesprächen.
Würde mich nicht wundern, wenn es Zufall ist und das Problem doch eher in irgendeinem lokalen "SIP-Hub" im Frankfurter Raum lag.
09.01.2018 11:03
Hallo @Chili-FFM
schön zu lesen, dass noch weitere Leute so verbissen versuchen, das 900 Sekunden Problem einzugrenzen. Ich habe mittlerweile 30 traces mit wireshark mitgeschnitten und kann nachweisen, dass bei abgehenden Calls der Telekom SIP-Proxy nach 900 sekunden ein SIP update request schickt, dessen Port vom T-Server nicht erkannt wird. Eindeutig passiert dieser Fehler in den Proxy Servern der Telekom. Wenn doch Telekom nur standardkonformes SIP implementieren würde . Siehe auch meinen Thread, leider auch hier kein Ergebnis. Seit 6 Monaten Gesprächsabbrüche nach 15 Minuten. Frust!
09.01.2018 11:12
Hallo @pepsimagenta,
mit Ihren Ausführungen komme ich nicht klar. Wenn der SIP Server (oder Proxy) der Telekom etwas schickt, dann ist das Ziel doch nicht der T-Server sondern der lokale Router und das Telefon dahinter. Und das funktioniert nur, wenn der Router die Session offengehalten hat.
Hinzu kommt, das die Telekom mit DNS SRV Requests arbeitet. D.h., der SIP Client muss sich den Port per DNS SRV Request holen.
09.01.2018 11:14 Zuletzt bearbeitet: 09.01.2018 11:35 durch den Autor
Hast Du denn mal folgendes probiert, ob das etwas ändert
(Ich führe so selten Ortsgespräche und wenn dann sind die in der Regel ein oder zwei Minuten lang - aber ich lasse gerade im Hintergrund ein Gespräch in dem ich mich selbst angerufen habe laufen, ich werde berichten wie lange das Gespräch dauerte bis zum Abbruch
Setup hierbei: Fritzbox 7590 mit zwei AVM Fritzfon C4; die Fritzbox hat ihre Internetverbindung über einen Speedport W925V - also ein sowieso verschärftes Szenario)
Update: Mein Ortsnetz-Gesprächstest mit Fritzbox/C4 wurde nicht nach 15 Minuten unterbrochen.
Das heißt noch nicht zwangsläufig, dass die Gigaset Basisstation eine Inkompatibilität mit der Telekom hat - wäre aber zunächst mal mein Anfangsverdacht.
09.01.2018 11:31
Eine ganz andere Frage, da Du hier im Thread suggerierst dass du genau dasselbe Problem hast (also sprich dass nur Ortsgespräche nach 15 Minuten abbrechen):
Siehst Du in Deinen Mitschnitten irgendwelche Unterschiede zwischen Ortsgesprächen (die nach 15 Minuten abbrechen) und Ferngesprächen (die stundenlang dauern können)?
09.01.2018 13:45
Ich orakle mal, dass LOKAL keine Unterschiede zwischen Orts- und Ferngesprächen bestehen.
Welche LOKALE Instanz sollte denn diese Unterscheidung machen können?
Für den Router sind die Datenpakete völlig transparent - er hat keine Ahnung, was da drin steckt.
Allenfalls das Telefon kenn seine eigene Rufnummer und die Zielrufnummer. Aber was sollte das Telefon in Abhängigkeit davon anders machen?
Nee, das Telefon hat diesbezüglich keine Logik.
Wenn ich raten müsste:
Die Telekom betreibt nicht DEN EINEN SIP-Server/Proxy/Gateway.
Gespräche innerhalb von Frankfurt (in meinem Beispiel) werden hier in FFM geroutet und verlassen den Großraum wahrscheinlich nicht.
Ferngespräche hingegen werden eine ganz andere Route haben (müssen) mit anderen "Relais-Stationen".
Und international eben nochmal ganz andere Routen.
Und irgendwo hier würde ich das Problem vermuten: der "Server/Gateway" für die lokalen Gespräche verhält sich anders als der "Server/Gateway" für die Ferngespräche.
09.01.2018 13:50
hallo @muc80337_2
erstmal vielen Dank für Deine schnelle Rückmeldung.
Die Fritzbox 3490 hat keine IP-Telefoniefunktion, daher habe ich ja das Gigaset C430Go gewählt und direkt an einen LAN port der Fritzbox angeschlossen. (ja, ich habe schon alle hier im Forum vorgeschlagenen Portweiterleitungen für NTP/UDP und STUN an/aus durchgetestet)
Das Phänomen tritt ausschließlich auf bei abgehenden Anrufen, aber hier bei allen Calls, also ins Ortsnetz oder Fernnetz oder Mobilfunk.
Das ist aber auch egal, denn der Proxy der Gegenstelle, Teilnehmer B, sendet in Sekunde 900 einen "SIP UPDATE" an "meinen" Proxy, also Teilnehmer A. Nun erkennt "Mein" Proxy den von B adressierten Port nicht und schließt somit das Gespräch mit SIP BYE ab.
Aber dass will meine Frau nicht, sie möchte gerne länger telefonieren.
09.01.2018 13:59 Zuletzt bearbeitet: 09.01.2018 14:00 durch den Autor
pepsimagenta schrieb:Die Fritzbox 3490 hat keine IP-Telefoniefunktion
Aber sicher hat die 3490 eine solche IP-Telefoniefunktion.
Man kann halt nur kein analoges/ISDN/DECT-Telefon anschließen sondern nur ein IP-Telefon wie Dein Gigaset oder z.B. ein Smartphone mit der Fritzfon App.
Es ist allerdings so, dass man nicht denselben Umfang an Telefoniefunktionen einer Fritzbox genießt mit einem IP-Telefon.
Ist aber doch trotzdem u.U. auch nett, wenn man unterwegs per VPN-Verbindung über den heimischen Anschluss telefonieren kann.
Und wenn am Gigaset die Gespräche nicht mehr abbrechen (sollten)
09.01.2018 14:07
@Chili-FFM schrieb:
Wenn ich raten müsste:
Die Telekom betreibt nicht DEN EINEN SIP-Server/Proxy/Gateway.
Ziemlich sicher reicht es nicht einen einzigen Server unter derselben Adresse zu betreiben. Das wird eine Serverfarm mit Load Balancern sein - möglicherweise auch geographisch redundant. Meine Vermutung.
Ich halte es auch nicht für ausgeschlossen, dass es da eine inkonsistente Einstellung gibt.
Aber mangels tieferer Einsicht ins Netz der Telekom bleibt doch nur der Benchmark mit anderen Lösungen. Z.B. einer Fritzbox oder einem Speedport. Und wenn die durch die Bank keine Abbrüche produzieren, dann vermute ich, dass die an der Stelle ein Mehr an Wissen haben gegenüber Gigaset und entsprechend eine weiß-der-Geyer-zusätzliche Nachricht richtig handhaben was das Gigaset nicht tut.
Na ja, so ganz durch die Bank ist das auch nicht. Ich habe sporadisch bisweilen auch Gesprächsabbrüche. Mal sagt mein Kumpel dann "bei mir ging der Akku zur Neige" und mal ruf ich halt einfach wieder an und schau gar nicht nach was los war.
09.01.2018 14:15
Das gibt's doch nicht!! Der erste vielversprechende Hinweis seit langem.
Und dass die Telefoniefunktion in der Fritzbox im Bereich WLAN versteckt ist, darauf muß man mal kommen
Ich teste mal direkt und melde mich wieder
09.01.2018 19:57
@muc80337_2@Chili-FFM@Kalle2014
so, hat etwas gedauert, aber mein erster Test ist zuende und wurde nicht nach 900 Sek beendet, sondern ich habe nach 16 Minuten ganz konventionell aufgelegt. Yippi!!!
Der SIP UPDATE request nach 900 Sekunden hat sauber funtioniert, und wurde von der Gegenstelle sauber mit SIP 200 OK bestätigt.
Muc80337, ich bin Deinem Vorschlag gefolgt, und habe:
Das könnte die technisch einwandfreie und saubere Lösung Lösung zu meinem Problem sein. Vielleicht hat AVM wirklich mehr Einblick in die Proxy-Serverfarm-Eigenheiten der Telekom. Na, dann muß sich mein Gigaset eben jetzt erst mit meiner Fritzbox beschäftigen und darf nicht mehr direkt in die Telekomwelt
Ich mache noch ein paar weitere Tests zu verschiedenen Gegenstellen, abgehend und ankommend, aber schon mal vielen Dank, @muc80337_2, für den wahrscheinlich entscheidenden Tipp nach monatelangem Suchen.
09.01.2018 22:49
Die Ursache für das Problem ist der Router, denn die Verbindung scheitert am NAT. Dadurch das jetzt die FB sich um die Telefonieverbindung kümmert, wird das NAT - Problem umgangen.
Ich habe einen Kunden mit einem anderen Router und der gleichen Gigaset GO - Box, und bei dem brechen die Telefongespräche nicht ab.
In dem Router gibt es dazu aber auch eine spezielle Konfiguration für "VoIP PBX im LAN".
10.01.2018 06:13
@Kalle2014 schrieb:Die Ursache für das Problem ist der Router, denn die Verbindung scheitert am NAT. Dadurch das jetzt die FB sich um die Telefonieverbindung kümmert, wird das NAT - Problem umgangen.
...
In dem Router gibt es dazu aber auch eine spezielle Konfiguration für "VoIP PBX im LAN".
"PBX im LAN" ist keine spezielle Konfiguration, sondern nur ein Assistent, der NAT-Einträge anlegt.
Das könnte man auch manuell tun.
Entscheidend ist dabei, dass die interne IP des Telefons beim NAT nach aussen immer den gleichen Port erhält - statt einen zufälligen Port.
Damit wird das Telefon von aussen erreichbar auf diesem Port.
Das gleiche erreicht man im Grunde mit einer fixen Portweiterleitung auch.
10.01.2018 08:47
Hallo @Chili-FFM,
dann schau dir das Ergebnis mal genau an, was der Assistent da gemacht hat. Denn das was dabei rauskommt, das kann nicht jeder Router, denn es ist nicht das was z.B. ein Speedport als fixe Portweiterleitung unterstützt.
10.01.2018 09:30
@Kalle2014 schrieb:Die Ursache für das Problem ist der Router, denn die Verbindung scheitert am NAT. Dadurch das jetzt die FB sich um die Telefonieverbindung kümmert, wird das NAT - Problem umgangen.
Das habe ich mittlerweile auch so erkannt. Aber krass ist schon, dass alle meine Versuche, das NAT zu umgehen, mit der FB3490 gescheitert sind: Alle möglichen Portweiterleitungen angelegt und wieder gelöscht, STUN ein, fixe Ports ein/aus, haben nicht geholfen.
Ich kann auch die Existenz von Serverfarmen bestätigen, denn bei jedem Anruftest bisher bin ich auf einem anderen A-Proxy aus dem IP Bereich 84.xxx.xxx.xxx gelandet.
Nun gut, dann kümmert sich jetzt die FB. Ganz pragmatisch: Wenn's funzt, dann gut
Meine 15 Minuten Tests laufen weiter, bisher keine Ausfälle mehr.....
10.01.2018 09:49
Man fragt sich bisweilen schon weshalb das mit VoIP so viel komplizierter aufgesetzt werden musste für NAT Router als z.B. ein Entertain TV-Dient oder ein Netflix Video Streaming-Dienst, die ja auch nicht alle 15 Minuten abbrechen
Aber das ist so seit Beginn von VoIP - was habe ich damals nicht alles rumgeschraubt an den Routereinstellungen meiner diversen Router (für den Home-Bereich) und Grandstream VoIP-Adapter-Einstellungen.
Bis dann die erste richtige Fritzbox kam und es damit dann auf Anhieb super funktioniert hat. War damals natürlich noch nicht Telekom IP-Telefonie.
10.01.2018 12:00 Zuletzt bearbeitet: 10.01.2018 12:04 durch den Autor
Man fragt sich bisweilen schon weshalb das mit VoIP so viel komplizierter aufgesetzt werden musste für NAT Router als z.B. ein Entertain TV-Dient oder ein Netflix Video Streaming-Dienst, die ja auch nicht alle 15 Minuten abbrechen
Entertain-TV basiert auf Multicast. Da ineragiert der Client (Receiver) überhaupt nicht mit einem Server.
Der Multicast-"Sender" in der Telekom-Welt schickt seine Datenpakete exakt EINMAL raus - egal wieviele Clients bei den Tausenden von Kunden in der weiten Welt am Ende Kopien dieser Datenpakete bekommen. (Deswegen hat der Router - genau wie nahezu alle Switche in der Kette die Funktionen "Multicast-Routing" und IGMP-Proxy.)
Im Kleinen auch zuhause: die Datenpakete zu einem TV-Sender kommen exakt EINMAL am Router an. Egal, wieviele Receiver im Haushalt dieses eine Programm kucken. Das können theoretisch Dutzende und Hunderte Receiver in einem Haushalt sein. Das erhöht die Last auf der Internetleitung nicht im geringsten.
Die Streaming-Dienste hingegen sind normale Unicast-Dienste - also 1:1 Verbindungen.
Wie der Aufruf einer Internetseite theoretisch auch. Also client-getrieben. Kein Problem für NAT, dafür ist es gemacht.
VoIP hingegen ist drauf angewiesen, dass auch von aussen eine Unicast-(Sprach)-Verbindung aufgebaut werden können muss.
Das ist also alles drei nicht miteinander vergleichbar.
10.01.2018 12:05
@Chili-FFM schrieb:
VoIP hingegen ist drauf angewiesen, dass auch von aussen eine Unicast-(Sprach)-Verbindung aufgebaut werden können muss.
Das ist also alles drei nicht miteinander vergleichbar.
Dass das technisch vergleichbar ist wollte ich auch nicht behaupten. Aber das eine funktioniert halt und das andere nicht. It's not rocket science...
10.01.2018 12:18
Das "Problem" bei der IP-Telefonie ist die Verwendung von zwei getrennten Verbindungen für Daten (SIP) und Sprache (RTP) und deren Abhängigkeit voneinander. Ähnliche Probleme gibt es z.B. oft auch beim FTP.
10.01.2018 12:21
Das ist aber nichts, das nicht hätte irgendwie eleganter gelöst werden können. Zu welchen ggf. zusätzlichen Kosten sei mal dahingestellt.
10.01.2018 12:41
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.