[Problem] C610 IP - bei ankommenden Gesprächen nach 1-3 Minuten Abbruch der Verbindung [Telekom

[EXP1337]

Hallo liebe Gigaset Experten,

Da ich nun mittlerweile als Mann vom Fach schon viel versucht habe aber bisher keine Lösung gefunden habe ich mich an euch.

Situation:

• VDSL50 IP Anschluss
• Speedport W722V-Typ B 1.18
• Gigaset C610IP V49 sowie V51 versucht

Problembeschreibung:
Bei (ausschließlich) ankommenden Gesprächen habe ich das Problem dass die Verbindungen reproduzierbar abbrechen.
1und1 Anschluss wählt -> meine Nummer -> ~80Sek Abbruch
Telekom Mobilfunk -> meine Nummer -> ~ 200Sek Abbruch

Ich besitze das Gerät seit Januar und konnte die ersten Wochen problemlos telefonieren und dann ungefähr ab Mitte März ging die Problematik los.

Wichtiger Hinweis. Mit meinem SNOM / elmeg IP290 kann ich ohne Probleme ankommende Gespräche führen solange ich will. Daher vermutte ich ein Problem Zusammenspiel Gigaset <-> Telekom Netz.

Hier mein Wireshark Trace:

No.     Time        Source                Destination           Protocol Length Info
   1824 6.366024    217.0.17.230          192.168.5.55          SIP/SDP  1202   Request: INVITE sip:0351*****@93.218.174.112:5061, with session description
   1838 6.409160    192.168.5.55          217.0.17.230          SIP      623    Status: 100 Trying
   2063 7.125693    192.168.5.55          217.0.17.230          SIP      674    Status: 180 Ringing
   2650 9.061745    192.168.5.55          217.0.17.230          SIP/SDP  1000   Status: 200 OK, with session description
   2664 9.124622    217.0.17.230          192.168.5.55          SIP      864    Request: ACK sip:0351*******@93.218.174.112:5061
  86041 225.208547  217.0.17.230          192.168.5.55          SIP/SDP  1017   Request: INVITE sip:0351******@93.218.174.112:5061, with session description
  86053 225.239658  192.168.5.55          217.0.17.230          SIP      623    Status: 100 Trying
  86059 225.251805  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  86259 225.742966  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  86651 226.732674  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  87420 228.732618  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  88993 232.752860  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  90580 236.772642  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  92136 240.792527  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  93702 244.812557  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  95263 248.832212  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  96859 252.852090  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  98421 256.872138  192.168.5.55          217.0.17.230          SIP/SDP  950    Status: 200 OK, with session description
  98685 257.610132  192.168.5.55          217.0.17.230          SIP      604    Request: BYE sip:[email protected]:5060
  98699 257.645066  217.0.17.230          192.168.5.55          SIP      519    Status: 200 OK

Warum eigentlich nach immer ~220Sek. dieser Invite der dann kurze Zeit später ~ 30 Sek. danach zum Gesprächsabbruch führt.

Hat jemand eine Idee?

 

[as67]

Hallo zusammen,
seit drei Jahren habe ich dieselbe Kombination (Speedport W722V-Typ B und Gigaset C610IP) in Betrieb.
Damals die selben Probleme wie EXP1337 hier beschreibt: Eingehende Gespräche werden nach unterschiedlicher Dauer abgebrochen. Ein Analoges Telefon am Speedport angeschlossen funktioniert einwandfrei (mit der IP Konfiguration im Speedport).
In den letzten drei Jahren traten die Probleme dann nur noch selten auf. Oft hat ein Neustart des Speedports und des Gigasets weitergeholfen.

Nun treten die Probleme seit einigen Wochen aber wieder sehr häufig auf. Es gibt "gute" und "schlechte" Tage mit mehr oder weniger häufigen Unterbrechungen.

Hat jemand eine Idee, ob man durch eine geänderte Konfiguration an Speedport oder Gigaset das Problem beheben kann?
Oder sollte der Speedport durch ein neueres Gerät ersetzt werden?

Viele Grüße
Alex

 

[MuP]

Die beste Idee ist sicherlich, die Firmware manuell auf Stand 42.210 zu bringen.

 

[tom.easy]

Hallo zusammen,

auch ich möchte mich hier mal dranhängen, da die von as67 beschriebene Problematik auch bei mir aktuell auftritt.

Konfiguration:
Telekom VDSL50 IP Anschluß
Speedport W 921 V mit FW 1.36.00
C610IP mit FW 42.210
C610IP ist direkt an den Speedport angeschlossen; nicht über den Switch.

Fehlerfreie Funktion bis Ende Februar 2015, danach auftretende Abbrüche von ausschließlich ankommenden Gesprächen.
Abgehende Gespräche problemfrei. Die Abbrüche kann ich leider nicht gezielt einem bestimmten Provider zuordnen wie oben EXP1337
Zeitintervall von fast direkt nach Gesprächsannahme bis ca. 100 Sek.

Speedport, C610IP wurden mehrfach vom Strom getrennt und neu hochgefahren.

Erwähnen muss ich noch, dass Anfang Februar 2015 zwei devolo dLAN 650+ Powerline Adapter für das Dachgeschoß installiert
wurden. Durch Abklemmen der beiden Adapter über zwei Tage kann ich aber ein Einwirken der devolos ausschliessen.

Mittlerweile habe ich auch keine Idee mehr, wo das Problem liegt.

Eventuell kann das Forum hilfreiche Tipps einbringen.

Besten Dank und Grüße
Thomas.

 

[eifelman]

Kannst du mal einen anderen Router vorschalten? Im Telekom-Forum gab es auch einen Nutzer, bei dem Gesprächsabbrüche in Verbindung mit dem W 921V auftraten: https://telekomhilft.telekom.de/t5/Telefonie/Gigaset-C430-IP-hinter-Speedport-Verbindungsabbruch-nach-5-50/td-p/1275758

Wenn es aber bis vor kurzem funktionierte, könnte es auch an der Telekom liegen - dort wird wohl momentan an der IP-Plattform gearbeitet. Unter anderem gibt es seit kurzem das Problem, dass die Rufnummernanzeige eingehender Anrufe gestört ist, siehe: http://forum.gigaset.com/posts/list/20373.page

 

[EXP1337]

Also ich persönlich nutze auch seit vielen vielen Monaten die 3390. Hatte bisher nie weitere Probleme mit dem C610IP. Ich konnte damals auch nie eingrenzen mit was die Probleme zusammenhingen. Die Probleme verschwanden plötzlich einfach wieder.

Evtl. hängt es mit der zukünftigen bzw. bereits erfolgten Migration von TAS-IMS zusammen.

 

[tom.easy]

Hallo zusammen,

besten Dank für die Rückmeldungen.

Nein @eifelman, ein anderer Router steht mir aktuell nicht zur Verfügung; auch im Kollegenkreis negativ. Hat allerdings meinen Wunsch nach einer Fritzbox 7490 verstärkt.
Allerdings wünsche ich mir vorher die von @EXP1337 beschriebenen "Selbstheilungskräfte".

Was habe ich getan:
Die Telekom hat meine Leitung durchgeklingelt bis zum Speedport W 921V und mir erklärt, dass alles in Ordnung sei. Das muss ich mal so hinnehmen.

Des Weiteren habe ich einen Syslog-Server mitlaufen lassen. Der hat heute Morgen auch etwas mitprotokolliert; nur muss ich gestehen, dass ich es nicht
interpretieren kann da nicht mein Fach. Eventuell kann mir hier jemand behilflich sein.
Der erste Anruf um 06:49 Uhr verlief störungsfrei. Beim zweiten Anruf um 07:46 Uhr kam es dann zu einer Unterbrechung die sich dann aber wieder erholt hatte,
Telefonat konnte normal beendet werden.

2015-03-18 06:34:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 06:44:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 06:49:47 daemon.info 192.168.7.61 MAC:7C2F80675653 SIP account 1: incoming call session up
2015-03-18 06:51:56 daemon.info 192.168.7.61 MAC:7C2F80675653 SIP account 1: active session release
2015-03-18 06:54:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:04:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:14:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:24:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:34:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:44:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 07:46:35 daemon.info 192.168.7.61 MAC:7C2F80675653 SIP account 1: incoming call session up
2015-03-18 07:48:20 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=152 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:21 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=48 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:23 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=94 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:24 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=118 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:26 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=18 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:27 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=114 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:29 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=67 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:30 user.warning 192.168.7.61 MAC:7C2F80675653 Except=0x1=S_EXCEPTCLASS_WARN Place=0x2F=SMD_EXCEPTPLACE Code=0x27=SMD_EXC_RTP_RECEIVE_BREAK PrcNr=96 LinkAdr=0x0 File=pform_bs/sip_md/smd.exc
2015-03-18 07:48:32 daemon.info 192.168.7.61 MAC:7C2F80675653 SIP account 1: session modification (passive)
2015-03-18 07:53:36 daemon.info 192.168.7.61 MAC:7C2F80675653 SIP account 1: passive session release
2015-03-18 07:54:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2015-03-18 08:04:19 kernel.info 192.168.7.61 MAC:7C2F80675653 POOL:;MPU_LOSIP_MALLOC:102;MPU_SIPDNS:16;MPU_SIP_TPSOCRX:370;MPU_AISN:58;MPU_AIDD_MAIN:10;MPU_FFS:501;MPU_HTT_CTRL_RCV:102;MPU_HTT_CTRL_SND:34;MPU_HTT_CTRL_MSG:32;MPU_SOC_TCP_SOC:12;MPU_SOC_TCP_TCP:446;MPU_SOC_UDP_SOC:18;MPU_SOC_UDP_UDP:3;MPU_CER_FILE_MGN:30
2

 

[MuP]

Lässt sich schlecht lesen.

Besser: Kopieren und dann hier in Code-Tags einbetten.

 

[lynckmeister]

Hallo Leute,

ich habe mit meinen SNOMen ein ganz ähnliches Problem:

Und zwar habe ich hier zwei SNOM 320. SIe laufen an einem Asterisk, der für ISDN gespräch per IAX an eine Fritzbox mit Asterisk weitervermittelt.
Die SNOMe liefen die ersten Monate wunderbar, dann begann das eine mit unregelmäßigem Auflegen, insbesondere bei reinkommenden Anrufen, aber auch bei ausgehenden.
Ich habe mit SNOM Kontakt aufgenommen und die haben das Gerät getauscht. Anschliessend ging es wieder ohne Probleme. Kurze Zeit später fing das zweite Gerät an mit dem selbebn Problem. Auch das Gerät wurde getauscht und es lief wieder.
Jetzt - einige Monate später - macht das erste Gerät wieder exakt die gleichen Probleme wie früher.

Ich vermute dass die Geräte "volllaufen"... Irgendein Latenzproblem. VIelleicht werden sie langsamer über die ZEit, weil irgendwelche Daten gespeichert werden, die jeweils durchsucht werden müssen ? Dazu kommt möglicherweise eine eh schon kritsiche Latenz über die beiden VIOP Schnittstellen richtung ISDN. Jedenfalls wird dann nach einiger Zeit irgendeine Schwelle übersprungen und das Telefon bekommt nicht mehr rechtzeitig VOICE Daten und kappt die Line?!

Anbei mal das Log aus dem Telefon . Die letzten Zeilen zeigen einen solchen Crash:

[0] 24/3/2015 15:50:11: LLDP: No Voice Applcation Type TLV packet found!
[5] 24/3/2015 15:50:23: send lldp advertisment
[5] 24/3/2015 15:50:37: rtp_port::set_destination  adr=192.168.1.120:10312
[5] 24/3/2015 15:50:37: Dialog -3118/2586 going to early
[5] 24/3/2015 15:50:37: rtp_port::set_port
[2] 24/3/2015 15:50:38: start_dst(1427594400) end_dst(1445742000) offset_dst(3600) offset_utc(7200)
[2] 24/3/2015 15:50:38: start DST: 03/29/2015 02:00:00 (1427594400)
[2] 24/3/2015 15:50:38: end DST: 10/25/2015 03:00:00 (1445742000)
[5] 24/3/2015 15:50:39: set_audible: RP-3118 changed=1, update_req=1, adr=192.168.1.120:10312
[5] 24/3/2015 15:50:39: connection::start_connectivity_check ()
[5] 24/3/2015 15:50:39: Dialog -3118/2586 going to confirmed
[0] 24/3/2015 15:50:42: LLDP: No Voice Applcation Type TLV packet found!
[5] 24/3/2015 15:50:43: sip::process_auth:Match challenge for user=123, realm=asterisk
[2] 24/3/2015 15:50:43: Registered at registrar as [email protected] (Expires: 3600 secs)
[0] 24/3/2015 15:51:12: LLDP: No Voice Applcation Type TLV packet found!
[5] 24/3/2015 15:51:24: send lldp advertisment
[5] 24/3/2015 15:51:25: Dialog -3118/2586 going to terminated
[0] 24/3/2015 15:51:25: Deleting connected_call
[5] 24/3/2015 15:51:25: set_audible: RP-3118 changed=1, update_req=0, adr=192.168.1.120:10312
[5] 24/3/2015 15:51:25: set_audible: RP-3118 changed=0, update_req=0, adr=192.168.1.120:10312
[5] 24/3/2015 15:51:27: rtp_port::set_port
[5] 24/3/2015 15:51:29: Dialog 1028/2587 going to terminated
[5] 24/3/2015 15:51:33: rtp_port::set_destination  adr=192.168.1.120:15848
[5] 24/3/2015 15:51:33: Dialog -3120/2588 going to early
[5] 24/3/2015 15:51:33: rtp_port::set_port
[5] 24/3/2015 15:51:34: set_audible: RP-3120 changed=1, update_req=1, adr=192.168.1.120:15848
[5] 24/3/2015 15:51:34: connection::start_connectivity_check ()
[5] 24/3/2015 15:51:34: Dialog -3120/2588 going to confirmed
[0] 24/3/2015 15:51:43: LLDP: No Voice Applcation Type TLV packet found!
[5] 24/3/2015 15:51:52: Dialog -3120/2588 going to terminated
[0] 24/3/2015 15:51:52: Deleting connected_call
[5] 24/3/2015 15:51:52: set_audible: RP-3120 changed=1, update_req=0, adr=192.168.1.120:15848
[5] 24/3/2015 15:51:52: set_audible: RP-3120 changed=0, update_req=0, adr=192.168.1.120:15848
[5] 24/3/2015 15:51:52: rtp_port::set_port
[5] 24/3/2015 15:51:55: Dialog 1029/2589 going to terminated

Jemand dazu eine Idee???