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,
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
Gelöst! Gehe zu 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!
10.12.2017 12:28
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?
10.12.2017 13:28
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
10.12.2017 19:07
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 ?
12.12.2017 10:30
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?
12.12.2017 15:44
Hallo @pepsimagenta
mal sehen ob z. B. @Detlev K. @Henning H. sich dazu melden.
Teste gerne nachher auch mal abgehende Gespräche
Gruß
Waage1969
12.12.2017 16:22 Zuletzt bearbeitet: 12.12.2017 16:54 durch den Autor
Hallo @pepsimagenta
mal ergänzend:
abgehendes Telefonat über Telekom Festnetz zu Telekom Festnetz, Dauer bisher 25 Minuten ohne Probleme
Gruß
Waage 1969
Ergänzung: auch 55 Minuten ohne Probleme
Hier mal meine Einstellungen zu Deiner Gegenkontrolle:
12.12.2017 17:00
Super, Danke !
12.12.2017 17:06
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?
12.12.2017 17:08
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.
12.12.2017 17:14
Hallo @pepsimagenta
aber gerne doch:
Übrigens, Gespräch steht jetzt seit über 75 Minuten, beende den Test nun mal
Gruß
Waage 1969
12.12.2017 17:40
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?
12.12.2017 17:44
Hallo @pepsimagenta
sieht zumindest nicht nach deutschen Nummern aus
Aber wieso klappt es bei Dir nicht !?
Gruß
Waage1969
12.12.2017 17:49
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
12.12.2017 18:13
Hallo @pepsimagenta
vielleicht habe ich es überlesen, welchen Speedport mit welcher Firmware hast du ?
Gruß
Waage1969
13.12.2017 08:22
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
13.12.2017 08:32
Hallo @pepsimagenta
kannst Du die Gigaset mal (zumindest zum testen) ohne den Switch betreiben !?
Gruß
Waage1969
13.12.2017 09:14
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.
13.12.2017 17:43
Hallo @pepsimagenta
tja, sehr kurios das ganze.
DSL hast Du auch mal während der Gespräche mitgeschnitten / protokolliert !?
Gruß
Waage1969
14.12.2017 09:38
mhh, ich habe den gesamten Verkehr mitgeschnitten. Welche Daten wären denn interessant?
14.12.2017 16:29
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
15.12.2017 09:43
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 !!!
15.12.2017 14:57
Hallo @pepsimagenta
ok, dann wären meine ersten Überlegungen mal den @prophaganda mal mit hinzuzuziehen und mal den @Super-Andy mit anzupingen
Mal sehen ob das nicht irgendwie herausgefunden werden kann mit dem "900 Sekunden" Abbruch Thema in der Telefonie.
Gruß
Waage1969
15.12.2017 16:07
@Waage1969 schrieb:
Hallo @pepsimagenta
ok, dann wären meine ersten Überlegungen mal den @prophaganda mal mit hinzuzuziehen und mal den @Super-Andy mit anzupingen
Das Setup inclusive dem Gigaset ist nicht so wirklich meine "Baustelle"
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
16.12.2017 10:38
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.
16.12.2017 13:08
Hallo @prophaganda
merci, dann werde ich mal @Hubert Eder anpingen, der hat ja immer eine Idee
@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
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.