Gigaset C430 IP hinter Speedport Verbindungsabbruch nach 5:50 Minuten

Gelöst

Hallo,

 

Ich habe einen Fiber 100 Anschluss mit Router Speedport W921V. Bisher habe ich immer ein ISDN-DECT Telefon am ISDN-Anschluss des Speedport betrieben und hatte damit auch nie Probleme. Da das DECT-Telefon nun seinen Geist aufgegeben hat und ich nicht wieder ein ISDN-Gerät kaufen wollte, um später auch einen Router ohne ISDN Anschluss verwenden zu können, habe ich mir nun ein Gigaset C430A IP gekauft. Ich hatte keine Probleme bei der Einrichtung, ich habe nur die Telefonnummer als Benutzername eingetragen und schon lief es.

ABER: Nach ca. 5:50 Minuten bricht jedesmal das Gespräch ab! (bisher nur ausgehend getestet).

Woran kann das liegen? Ist hier evtl eine Firewall o.ä. im Speedport schuld? Muss ich eine Portweiterleitung schalten?

Da muss doch irgendein Timer ablaufen, damit das jedesmal nach dieser Zeit passiert. Da ich ansonsten keine 3rd Party VOIP-Software verwende kann ich nicht sagen, ob das dann auch passiert. Die HomeTalk App habe ich nur mal probeweise verwendet und hatte damit auch einen Verbindungsabbruch, aber das hatte ich aufs WLAN geschoben.

 

Wer hat solche Probleme auch schon mal gehabt? Es nervt schon ziemlich und ich möchte nicht deswegen das Telefon wieder umtauschen. Sowohl auf dem Speedport als auch auf dem Gigaset ist die neueste Firmware installiert.

 

Grüße

T. Muders

1 AKZEPTIERTE LÖSUNG

So, um mir noch mal selbst zu antworten und das Thema zu schließen:

 

Durch Einsatz einer Fritzbox (3490) anstatt des Speedports konnte das Pro blem gelöst werden - ich kann jetzt einwandfrei telefonieren!

 

Lösung in ursprünglichem Beitrag anzeigen  

Hallo @Waage1969

sorry für die späte Antwort, aber ich war in der Zwischenzeit nicht untätig. Die Geräte haben alle den neuesten, aktuellen SW Stand. Das war nicht der Grund für den erneuten Fehler.

Ich habe in den letzten zwei Tagen mindestens 8 wireshark traces von abgehenden Gesprächen mitgeschnitten und den SIP Protokoll Ablauf analysiert. Ich komme zu folgendem Ergebnis:

Telekom hat scheinbar den SIP UPDATE request nach RFC 3311 implementiert und startet den UPDATE request nach exakt 900 Sekunden.

Dieser UPDATE Request wird vom Telekom Proxy2 des Angerufenen initiiert und zurück an den Telekom Proxy1 des Anrufers geschickt, und zwar mit einer (neu vergebenen?) Portadresse, die vom Proxy1 nicht erkannt wird. Die Portadresse liegt im 5xxx (z.b. 5080, 5086, 5119) Bereich, wird aber bei jeder Verbindung scheinbar neu generiert.

Da der Port vom Proxy1 nicht erkannt wird, (Fehler „Status:481 Call leg/Transaction does not exist“) kann Proxy1 kein ACK SIP an Proxy2 schicken. Nun versucht Proxy2 das Gespräch zu beenden, indem er ein BYE request auf den gleichen Port schickt. Der BYE request wird dann auch nicht erkannt, folglich wird der UDP Transportstrom unterbrochen. Eine SIP standardkonforme Beendigung des Gesprächs sieht anders aus.

Das alles passiert im Netz, nicht auf meiner Endgeräteseite.

 

Ich zweifele an der korrekten Telekom Implementation der SIP UPDATE request Funktion. Allerdings stellt sich die Frage, ob der der UPDATE request bei allen VoIP Verbindungen im Netz der Telekom geschickt wird, und wenn ja, warum es generell vernünftig funktioniert und warum genau bei meiner Installation die abgehenden Gespräche dieses Fehlverhalten zeigen.

Auf meiner Seite habe ich natürlich auch andere Tests gefahren, die Portweiterleitungen im Router gelöscht, Portweiterleitungen neu eingetragen und STUN für den NAT Traversal aus und eingeschaltet. Das Fehlerbild ist immer das gleiche.

 

Es gibt doch bestimmt einen Netz-Protokollexperten, der sich in der Welt der SCSF-Routern auskennt und diese Problematik aus dem Hemdsärmel beantworten kann?

Hallo @pepsimagenta

tja das kann unter Umständen problematisch sein / werden.

Habe bei mir mal Tests gemacht, mehere Anrufe vom Handynetz (T-Mobile)  mit unterdrückter & aktiver Nummerübermittlung mit mehr als 35 Minuten gemacht, alle ohne Probleme.

Gruß

Waage1969

Ok, das sind ankommende Anrufe, nicht abgehende. Bei ankommenden Anrufen habe ich auch keine Probleme.

Bei ankommenden Gesprächen aus dem Telekom-Mobilnetz ist der Proxy1 ja im IMS eingebunden. Da scheint alles protokolltechnisch OK zu sein.

 

Vielleicht liest noch jemand mit und hat eine Idee ?

Ich versuche es nochmal, der Frust steigt nach über 40 Stunden investigativer Analyse.  Endegeräteseite habe ich mittlerweile alles durch, jeder Vorschlag ist getestet, keine Besserung.

Ich bitte die Telekom Forenexperten, firmenintern mit einem Telekom NetzProtokollexperten in Kontakt zu treten und ihn zu bitten, beigefügten wireshark trace (anonymisierte Anlage) zu analysieren.

Warum enden meine abgehenden Gespräche immer nach 900 Sekunden?

Warum kann der Proxy bei dem UPDATE request nach 900 Sekunden den Port 5060 nicht finden?

 

 

Hallo @pepsimagenta

mal sehen ob z. B. @Detlev K. @Henning H. sich dazu melden.

Teste gerne nachher auch mal abgehende Gespräche Zwinkernd

Gruß

Waage1969

Hallo @pepsimagenta

mal ergänzend:

abgehendes Telefonat über Telekom Festnetz zu Telekom Festnetz, Dauer bisher 25 Minuten ohne Probleme Zwinkernd

Gruß
Waage 1969

Ergänzung: auch 55 Minuten ohne Probleme Zwinkernd

 

Hier mal meine Einstellungen zu Deiner Gegenkontrolle:

Mehr Infos
Gigaset
Gigaset Sicherheit 1.PNGGigaset Sicherheit 2.PNGGigaset Audio Codec.PNGGigaset Voip 1.PNGGigaset Voip 2.PNGGigaset lokale Einstellungen.PNGGigaset Firmwareversion 081217.PNG

 

Super, Danke !

@Waage1969

Deien screenshots hätten auch von mir kommen können, exakt alle Einstellungen gleich!

lediglich die FW ist bei mir 42.243 (422430000000 / V42.00) anstatt 42.245 (Gigaset sagt mir aber ich bin aktuell)

Kannst Du bitte mal in die einzelen Telefoneinstellungen schauen, ob STUN an oder aus ist?

 

Ich versuche mal als nächstes, auch ein abgehendes Festnetz zu Festnetz Gespräch zu testen, bisher habe ich immer mein eigenes Mobile angerufen, das ist schön einfach.

Hallo @pepsimagenta

aber gerne doch:

Gigaset weitere Einstellungen 1.PNGGigaset weitere Einstellungen 2.PNG

Übrigens, Gespräch steht jetzt seit über 75 Minuten, beende den Test nun mal Zwinkernd


Gruß
Waage 1969

@Waage1969

jetzt wird mir langsam mulmig

Ich habe gerade einen Test zu einem anderen Festnetztelefon gemacht. Nach 900 Sekunden war das Gepräch wieder abgebrochen. Also hier nix neues. Der Proxy findet nach 900 Sek den Port nicht.

Aber:

Schau bitte mal in den wireshark trace. Während der gesamten 15 Minuten hat es 13 Gesprächsversuche gegeben, die meine Fritzbox mitgeschnitten hat.

Werde ich etwa von einem Hacker angegriffen?

Hallo @pepsimagenta

sieht zumindest nicht nach deutschen Nummern aus Zwinkernd

Aber wieso klappt es bei Dir nicht !? Besorgt

Gruß

Waage1969

@Waage1969

Danke übrigens für deine screenshots zu den einzelnen Telefonen. Konfig ist bei mir genau gleich, ich habe auch drei Endgeräte zuhause. STUN "ein" habe ich auch. Macht ja auch Sinn für das NAT Traversal.

Wenn Deine und meine Einstellungen genau gleich sind, es bei Dir funktioniert und bei mir nicht, Warum funzt es nicht? Fruuuust

 

Hallo @pepsimagenta

vielleicht habe ich es überlesen, welchen Speedport mit welcher Firmware hast du ?

Gruß
Waage1969

hallo @Waage1969

ich habe folgende Konstellation:

VDSL50, Fritzbox 3490, daran direkt (wegen IGMPv3)  3 x MR303 plus direkt ein Switch TPLINK 108E. An diesem Switch hängt eine Basisstation Gigaset C430A Go mit drei Telefonen für VoIP

Hallo @pepsimagenta

kannst Du die Gigaset mal (zumindest zum testen) ohne den Switch betreiben !?

Gruß

Waage1969

Guten Morgen @Waage1969

Du bist ja früh morgens am Start !

Gute Idee, ich habe nun einen Test ohne Switch gemacht. Ein neues Verhalten: Nach 556 Sekunden hat sich das Gespräch mit frame 66521 einfach mit SIP:BYE verabschiedet. Das klingt jetzt nicht mehr nach session timer Problem.

Der trace ist wieder anbei, ich habe frame 66521 mit source EricsXXX_21 mal besonders hervorgehoben und detailiert darunter aufgelistet.

Hallo @pepsimagenta

tja, sehr kurios das ganze.

DSL hast Du auch mal während der Gespräche mitgeschnitten / protokolliert !?

 

Gruß

Waage1969

mhh, ich habe den gesamten Verkehr mitgeschnitten. Welche Daten wären denn interessant?

Hallo @pepsimagenta

schwierig zu sagen.

Ich würde suchen ob es DSL Abbrüche gibt oder der DSL unter ein 384er Profil absinkt.

Gruß
Waage 1969

Die DSL leitung steht wie eine Eins. Minimale Bandbreite upstream 2,78 Mbit, downstream 27,9 Mbit, also weit weg von jedem kritischen DSL Profil.

Hab gerade noch mal einen Test gemacht. Gleiche Ergebnis, nach 900 Sekunden Abbruch.

Ich bin enttäuscht, weil sich bisher kein Netzprotokollexperte in diesem Chat gemeldet hat. Allerdins sehe ich, dass der Telekom Proxyserver 84.163.91.60 unter Beobachtung steht. Es werden in regelmäßigen Abständen von ca 2 Minuten SIP test calls abgeschickt. Erstaunlich, dass die testcalls alle an sehr merkwürdige Nummern gehen. Da stimmt doch was nicht.

 

Wenn ich nun wieder eine offizielle Störung wegen meinem 15 Minuten Problem an Telekom schicke, kommt wieder das übliche: Haben Sie die aktuelle Software? Wir messen Ihre Leitung. Es kommt ein Experte raus. Sind Ihre Kabel richtig? Wenden Sie sich an AVM. Reklamieren Sie mal die Endgeräte beim Hersteller. Das muß ich an den 2nd Level eskalieren.

 

FRUST !!!

Hallo @pepsimagenta

ok, dann wären meine ersten Überlegungen mal den @prophaganda mal mit hinzuzuziehen und mal den @Super-Andy mit anzupingen Zwinkernd

Mal sehen ob das nicht irgendwie herausgefunden werden kann mit dem "900 Sekunden" Abbruch Thema in der Telefonie.

Gruß

Waage1969


@Waage1969 schrieb:

Hallo @pepsimagenta

ok, dann wären meine ersten Überlegungen mal den @prophaganda mal mit hinzuzuziehen und mal den @Super-Andy mit anzupingen Zwinkernd


@Waage1969 & @pepsimagenta

Das Setup inclusive dem Gigaset ist nicht so wirklich meine "Baustelle"

 

@Waage1969

Du hast da ja schon einiges angesprochen, was in Betracht kommen könnte... Ich könnte jetzt nur noch Spekulationen einwerfen, wo ich noch nicht mal weiß welche überhaupt Zwinkernd

Hallo  @prophaganda

vielen Dank an @Waage1969 fürs Weiterleiten, aber meine Frage war, warum der Telekom Proxy nach 900 Sek einen SIP UPDATE request schickt und dann das Gespräch verworfen wird, weil der Port nicht erkannt wird. Das alles passiert im DT Netz, nicht im Endgeräte setup.

Hallo @prophaganda

merci, dann werde ich mal @Hubert Eder anpingen, der hat ja immer eine Idee Zwinkernd

@Hubert Eder kannst Du mal sehen ob du was in Richtung der Thematik von @pepsimagenta hast:

warum der Telekom Proxy nach 900 Sek einen SIP UPDATE request schickt und dann das Gespräch verworfen wird, weil der Port nicht erkannt wird. Das alles passiert im DT Netz, nicht im Endgeräte setup.
Danke !
Gruß
Waage 1969