Willkommen in der Business Community

Die Telekom Community für Geschäftskunden

Aktueller Hinweis

Probleme mit Digialisierungsbox / Be.IP Plus

Hallo,

 

wir haben eine Be.IP Plus von Bintec (Baugleich mit Digitalisierungsbox) in einem kleinen Büro (5x IP630 von Bintec, 2x DECT Telefonen, 1x Fax) vor 2 Jahren an unseren 2 ISDN Anschlüssen eingesetzt und waren bisher zufrieden.

Nun wurden bei uns Anfang Oktober die ISDN Anschlüsse gegen 2x Deutschland LAN IP (2MBit) umgestellt. Seit dem haben wir nur noch Probleme:

- Mal kann man das Telefonat nicht annhmen

- Mal hören wir den Gesprächspartner nicht,

- Mal kommen Faxe nicht an

- Heute war auf einmal die Registrieung der Rufnummern nicht mehr gegeben.

 

Ich blicke einfach nicht mehr durch! Alle Fehler sind nur sporadisch!! 

Im Fehlerprotokoll (SYSLOG) kommt auch sporadisch Meldungen wie diese: 

ATM: vdsl3-0: Rx Errors last 2 seconds: 162 CRC 2 FEC: 8273 HEC 2
ATM: vdsl3-0: 139 new Rx Errors: CRC 2 FEC: 8250 HEC 2

Leitungsprüfung der Telekom sagt: Alles i.O.

 

Dann kommt heute immer wieder sowas:

11:49:57 INET: destroy session, 80.134.42.133:41584->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.125:10140->217.0.43.193:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.125:41259->217.0.43.193:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.125:53608->217.0.43.193:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.133:41382->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.133:36007->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.133:6909->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.129:25034->217.0.43.193:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.125:35578->217.0.43.193:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.133:46861->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.133:50524->217.237.150.205:53 prot: 17
11:49:57 INET: TIMEOUT Session expired: 80.134.42.133:50524->217.237.150.205:53 prot=17
11:49:57 INET: TIMEOUT Session expired: 80.134.42.133:46861->217.237.150.205:53 prot=17
11:49:57 INET: TIMEOUT Session expired: 80.134.42.125:35578->217.0.43.193:53 prot=17

Was kann ich tun? Wer hat eine Idee? Welche Konfiguration braucht ihr, um mir ggf. einen Tipp zu geben?

 

Bin am Verzweifeln!! Damals hatten wir bei der ISDN Variante 0 FEHLER!!!!

 

 

Gelöschter Nutzer

Die CRC Meldungen sind kein Problem wenn sie sporadisch auftauchen. Das kann eine zufällige STörung auf der Leitung sein.

Die anschließenden Meldungen sind einfach nur in der be.ip erkannte Verbindungen im NAT-Router, die nach einer gewissen Zeit der Inaktivität geschlossen werden: Hier alles DNS-Anfragen per UDP. Kein Grund zur Panik.

 

Wenn Du aber schreibst von 2x Internet-Anschluss: Laufen beide über die bintec-Anlage? Welche Firmwareversion läuft auf der be.ip?

Läuft das Internet rund oder hats da auch Probleme? Mir scheint, die DNS-Anfragen laufen auch immer über beide Verbindungen raus. Ist die Telefonie Standortgebunden (jeweils auf die zugehörige Leitung fixiert)?

 

Hallo,

 

ich kenne mich mit den Bintec-Routern zwar nicht allzusehr aus, aber vielleicht kann ich trotzdem ein paar Hinweise geben.

 

Vorher würde ich nun gerne wissen: Wie heißt Eurer Tarif genau (es gibt mehrere DeutschlandLAN-Varianten) und warum habt Ihr offenbar mehrere Anschlüsse mit 2 MBit/s? Ist bei Euch keine höhere Geschwindigkeit möglich oder handelt es sich hier um SDSL-Anschlüsse?

 


@Dominik_  schrieb

 

Ich blicke einfach nicht mehr durch! Alle Fehler sind nur sporadisch!! 

Im Fehlerprotokoll (SYSLOG) kommt auch sporadisch Meldungen wie diese: 

 

ATM: vdsl3-0: Rx Errors last 2 seconds: 162 CRC 2 FEC: 8273 HEC 2
ATM: vdsl3-0: 139 new Rx Errors: CRC 2 FEC: 8250 HEC 2

Leitungsprüfung der Telekom sagt: Alles i.O.

Die von Dir zitierte Meldung zeigt die Fehler auf der DSL-Strecke an, also wie "gut" die Verbindung zwischen Router und Gegenstelle ist. Die FEC-Fehler kann der Router vereinfacht gesagt selbst korrigieren, die CRC-Fehler jedoch nicht. Falls hier Experten für Bintec-Router da sind: Diese Meldungen zeigen vermutlich neue Fehler auf und sind kein Gesamtzähler aller bisher aufgelaufenen Fehler? Falls alle paar Sekunden zwei neue CRC-Fehler auftreten, wäre das meiner Meinung nach relativ viel - aber da können andere Nutzer vielleicht mehr dazu sagen.

 

Wenn die CRC-Fehler das Problem sind, würde ich aber eher mit Abbrüchen bestehender Telefonate oder einer schwankenden Sprachqualität innerhalb von Gesprächen rechnen, das scheint aber offenbar nicht der Fall zu sein? Offenbar funktioniert die Telefonie manchmal und manchmal nicht? Gibt es im oben erwähnten Fehler-Login in Zeiten von fehlerhaften Telefonaten mehr FEC- bzw. CRC-Fehler als zu Zeiten, bei denen die Telefonie funktioniert?

 


Dann kommt heute immer wieder sowas:

 

11:49:57 INET: destroy session, 80.134.42.133:41584->217.237.150.205:53 prot: 17
11:49:57 INET: destroy session, 80.134.42.125:10140->217.0.43.193:53 prot: 17
[...]
11:49:57 INET: destroy session, 80.134.42.129:25034->217.0.43.193:53 prot: 17
[...]
11:49:57 INET: TIMEOUT Session expired: 80.134.42.133:46861->217.237.150.205:53 prot=17 11:49:57 INET: TIMEOUT Session expired: 80.134.42.125:35578->217.0.43.193:53 prot=17

Die links genannte IP (80.134.42.1xx) soll wohl die IP-Adresse des betroffenen Anschlußes sein - aber warum tauchen drei verschiedene IP-Adressen (x.x.x.125, x.x.x.129 und x.x.x.133) zur gleichen Zeit auf, wenn Du weiter oben von zwei DeutschlandLAN-Anschlüssen sprichst? Habt Ihr ein Netz mit z.B. 8 oder 16 statischen IP-Adressen von der Telekom bekommen? Die einfachen DeutschlandLAN-Tarife haben meines Wissens gar keine oder max. eine feste IP-Adresse...(?)

 

Die rechts genannten IP-Adressen (217.0.43.193 und 217.237.150.205) scheinen mir zu DNS-Servern der Telekom zu gehören (die für die Übersetzung von Domainadressen wie telekom.de in IP-Adressen zuständig sind). Diese Meldungen besagen also wohl, daß nach erfolgten DNS-Abfragen die TCP-Verbindungen zu den DNS-Servern abgebaut werden.

 

Was kann ich tun? Wer hat eine Idee? Welche Konfiguration braucht ihr, um mir ggf. einen Tipp zu geben?

 

Bin am Verzweifeln!! Damals hatten wir bei der ISDN Variante 0 FEHLER!!!

Gibt es in den Logs keine Angaben zu speziellen VoIP-Fehlern? Siehe z.B. https://telekomhilft.telekom.de/t5/All-IP-das-digitale-Netz/Bintec-be-ip-SIP-Trunk-Fehler-480-ausgeh... für ein Beispiel, wie solche Einträge aussehen könnten (ja, es geht dort um ein anderes Thema, das ist ja nur ein Beispiel für entsprechende Log-Einträge).

 

Wenn Ihr mehrere IP-Adressen nutzt (jetzt mal egal ob absichtlich oder unabsichtlich) könnte ich mir evtl. vorstellen, daß der Router sich bei den SIP-Servern wechselweise mit den verschiedenen IP-Adressen anmeldet und die Telefonie-Plattform der Telekom dadurch irgendwie durcheinander kommt und nicht mehr weiß, an welche IP sie denn nun die Verbindungen zustellen soll.

 

cu talk

Hallo,

schon einmal vielen Dank für die Antwort!

 - Beide Internet-Verbindungen laufen über die Be.IP Plus. Einmal das interne DSL Modem und einmal ein externes D-Link DSL-321B Modem.

- Ob das Internet Rund läuft ?! Kann ich schwer sagen, da wir über LTE noch extra versorgt sind, da 2x 2MBit Leitung recht schwach ist und somit sind wir zum surfen auf LTE gegangen. Aber laut dem Dashoboard von der Be.IP sind die DSL Verbindungen schon mehrere Tage aktiv.

- Ja, ich habe die Telefonie Standort gebunden, also Rufnummern zum DSL 1 auf einene Standort und die Rufnummern zu DSL 2 über den zweiten Standort.

- Firmware Be.IP: Release 10.2.  Rev.4 

 

 

Gruß Dominik

Leider ist der Log Bereich von der Be.IP sehr klein, sodass ich den Fehler noch nicht mitgeloggt habe.

Ich habe seit heute einen SYSLOG Server laufen um so zu hoffen, mehr informationenn zu bekommen.

Beim nächsten Fehler (wird erst ab Montag kommen in den Geschäftszeiten), werde ich die LOGs hier einstellen.

 

Unsere Tarife sind 2x DeutschlandLAN IP Start

Warum 2x Anschlüsse? Da wir leider nur 2x 2MBit DSL RAM in unserem kleinen Dorf erhalten.

Eine LTE Anbindung mittels Telekom Netz geht leider nicht, da bei uns ein Funkloch von Telekom ist und somit wir LTE von der Konkurrenz beziehen.

Telekom hilft Team
Hallo @Dominik_,

herzlich willkommen in unserer Community. Schön, dass Sie mit Ihrem Anliegen den Weg zu uns gefunden haben.

Vielen Dank für Ihren Beitrag.
Leider kann ich Ihnen zu diesem Router von keine Unterstützung anbieten.
Da die Leitung auch bereits gemessen und in Ordnung ist, liegt es wahrscheinlich am Router.

Ich hoffe, Sie erhalten dazu hilfreiche Beiträge aus der Community.

Lieben Gruß Melanie B.

Hallo,

 

meines Wissens steht bei DeutschlandLAN IP Start nur eine dynamische IP-Adresse pro Anschluß zur Verfügung, also kein statisches Netz mit mehreren IP-Adressen. Das würde auch zu dem aufgeführten IP-Pool passen.

 

Bei zwei Anschlüssen dürften dann aber auch nur zwei IP-Adressen auftauchen, das von mir bereits angesprochene Log zeigt aber mindestens drei verschiedene IP-Adressen (x.x.x.125, x.x.x.129 und x.x.x.133). Du solltest mal genau überprüfen, wieviele (PPPoE-)Einwahlen bestehen (drei oder vielleicht gar noch mehr?). Ich tippe darauf, daß sich mindestens einer der beiden DeutschlandLAN-Anschlüsse mehrfach einwählt (was meiner Meinung nach ein Fehler wäre).

 

Sind denn Telefonnummern von beiden DeutschlandLAN-Anschlüssen von den geschilderten Problemen betroffen und gilt das nur für die Nummern eines Anschlußes?

 

cu talk

Hallo,
also das mit den drei IP Adressen war mein Fehler!!! es sind nur 2 Stück! 

Im Moment treten die Probleme nur bei einem Anschluss auf.

 

Heute war es wieder soweit:

Gegen 10:07 Uhr kam ein Anruf rein und das Gespräch konnte nicht angenommen werden, so die Mitarbeiterin.

Ich habe mal versucht so grob das Protokoll zusammen zukürzen auf dne besagten Zeitraum!

 

Zur Info:

IP vom betoffenen Telefon:  192.168.100.51 
IP von der BE IP 192.168.100.40

Im Moment sind auch noch die normalen PCs im gleichen SUB Netz ohne VLAN, ist dass vll auch ein Problem.

Wir haben nur 5 PCs, ein paar Drucker und einen Server am laufen.

 

Mon Oct 29 10:14:17 2018 INET: sending SNTP response to 192.168.100.53
Mon Oct 29 10:14:16 2018 INET: destroy session, 80.134.42.129:7182->217.0.43.193:53 prot: 17
Mon Oct 29 10:14:16 2018 INET: destroy session, 80.134.42.129:48850->217.0.43.193:53 prot: 17
Mon Oct 29 10:14:16 2018 INET: destroy session, 80.134.42.129:9499->217.0.43.193:53 prot: 17
Mon Oct 29 10:14:16 2018 INET: destroy session, 80.134.42.129:36627->217.0.43.193:53 prot: 17
Mon Oct 29 10:14:16 2018 INET: TIMEOUT Session expired: 80.134.42.129:36627->217.0.43.193:53 prot=17
Mon Oct 29 10:14:16 2018 INET: TIMEOUT Session expired: 80.134.42.129:9499->217.0.43.193:53 prot=17
Mon Oct 29 10:14:16 2018 INET: TIMEOUT Session expired: 80.134.42.129:48850->217.0.43.193:53 prot=17
Mon Oct 29 10:14:16 2018 INET: TIMEOUT Session expired: 80.134.42.129:7182->217.0.43.193:53 prot=17
Mon Oct 29 10:14:09 2018 INET: new session, 192.168.100.40:10201->192.168.100.53:10001 prot: 17 parent: false
Mon Oct 29 10:14:06 2018 INET: SIF: Accept [30010001:217.0.6.21:43343] -> [1:80.134.42.129:13169] :17
Mon Oct 29 10:14:06 2018 INET: new session, 217.0.6.21:43343->80.134.42.129:13169 prot: 17 parent: false
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_license_free(call=8242)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_call_delete(call=8242)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8242): idle
Mon Oct 29 10:14:05 2018 VOIP: IWU: sip_call_state(call=8242, state=idle)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_license_free(call=8241)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_call_delete(call=8241)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8241): idle
Mon Oct 29 10:14:05 2018 VOIP: IWU: sip_call_state(call=8241, state=idle)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_license_free(call=8240)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_call_delete(call=8240)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8240): idle
Mon Oct 29 10:14:05 2018 VOIP: IWU: sip_call_state(call=8240, state=idle)
Mon Oct 29 10:14:05 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000000)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=8242, number=, number_peer=, direction_is_initiator=0, state=idle)
Mon Oct 29 10:14:05 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000100)
Mon Oct 29 10:14:05 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000000)
Mon Oct 29 10:14:05 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=8241, number=, number_peer=, direction_is_initiator=0, state=idle)
Mon Oct 29 10:14:05 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000100)
Mon Oct 29 10:14:04 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000000)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=8240, number=, number_peer=, direction_is_initiator=0, state=idle)
Mon Oct 29 10:14:04 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000100)
Mon Oct 29 10:14:04 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000000)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=530, number=, number_peer=, direction_is_initiator=0, state=idle)
Mon Oct 29 10:14:04 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000100)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=8242, number=23, number_peer=, direction_is_initiator=0, state=terminated)
Mon Oct 29 10:14:04 2018 VOIP: IWU: trap_handler_call_transaction(ev=0x00000100)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_mps_call_state(call=8242): idle
Mon Oct 29 10:14:04 2018 VOIP: IWU: mps_call_state(call=8242, new_state=idle, old_state=terminated)
Mon Oct 29 10:14:04 2018 VOIP: IWU: msg_send(call=8242, msg=LOG_ID_CLEARED) IWU_LINE->MPS for device=line
Mon Oct 29 10:14:04 2018 VOIP: IWU: call terminated(8242): mps_cause=complete elsewhere, sip_cause=none
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_media_call_state(call=8242): idle
Mon Oct 29 10:14:04 2018 VOIP: IWU: media_call_state(call=8242, new_state=idle, old_state=terminate)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_media_call_state(call=8242): terminate
Mon Oct 29 10:14:04 2018 VOIP: IWU: media_call_state(call=8242, new_state=terminate, old_state=initiate)
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_dsp(call=18242): fd=48
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_udp(call=18242): fd=47
Mon Oct 29 10:14:04 2018 VOIP: IWU: nat_session_close(call=18242)
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_link(call=18242): link=541
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_dsp(call=8242): fd=46
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_udp(call=8242): fd=45
Mon Oct 29 10:14:04 2018 VOIP: IWU: nat_session_close(call=8242)
Mon Oct 29 10:14:04 2018 VOIP: IWU: dsp_session_close_link(call=8242): link=561
Mon Oct 29 10:14:04 2018 VOIP: IWU: media_call_terminate(call=8242)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8242): terminate
Mon Oct 29 10:14:04 2018 VOIP: IWU: sip_call_state(call=8242, state=terminate)
Mon Oct 29 10:14:04 2018 VOIP: IWU: sip_call_terminate(call=8242)
Mon Oct 29 10:14:04 2018 VOIP: IWU: mps_call_terminate(call=8242)
Mon Oct 29 10:14:04 2018 VOIP: IWU: iwu_cb_mps_call_state(call=8242): terminated
Mon Oct 29 10:14:04 2018 VOIP: IWU: mps_call_state(call=8242, new_state=terminated, old_state=ring)
Mon Oct 29 10:14:04 2018 VOIP: IWU: msg_recv(call=8242, msg=CC_CALL_RELEASED) MPS->IWU_LINE for device=line
Mon Oct 29 10:14:04 2018 VOIP: IWU: media_call_state(call=8241, new_state=idle, old_state=terminate)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8242): ring
Mon Oct 29 10:14:02 2018 LDAP: SearchRequest - baseObject:'sn=*' filter:'(telephoneNumber==Anonymous)' results:0
Mon Oct 29 10:14:02 2018 LDAP: uid not found or empty in searchrequest. scope==2, baseObject:sn=*
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_subscr_blf_notify(subscr=65731)
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_subscr_blf_notify(subscr=65787)
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_subscr_blf_notify(subscr=84771)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=8243, number=43, number_peer=, direction_is_initiator=0, state=ring)
Mon Oct 29 10:14:02 2018 VOIP: IWU: trap_handler_call_transaction(ev=0xFFFFFFFF)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_mps_call_state(call=8243): ring
Mon Oct 29 10:14:02 2018 VOIP: IWU: mps_call_state(call=8243, new_state=ring, old_state=initiate)
Mon Oct 29 10:14:02 2018 VOIP: IWU: msg_send(call=8243, msg=CC_CALL_DELIVERED) IWU_LINE->MPS for device=line
Mon Oct 29 10:14:02 2018 VOIP: IWU: mps_call_ring(call=8243)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8243): ring
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_call_state(call=8243, state=ring)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8243): initiate
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_call_state(call=8243, state=initiate)
Mon Oct 29 10:14:02 2018 VOIP: IWU: sip_call_initiate(call=8243, number=43)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_media_call_state(call=8243): initiate
Mon Oct 29 10:14:02 2018 VOIP: IWU: media_call_state(call=8243, new_state=initiate, old_state=idle)
Mon Oct 29 10:14:02 2018 VOIP: IWU: dsp_session_msg_send(call=18243, type=net[local_port=10201, remote=192.168.100.53:0])
Mon Oct 29 10:14:02 2018 VOIP: IWU: dsp_session_msg_send(call=8243, type=net[local_port=10200, remote=192.168.100.53:0])
Mon Oct 29 10:14:02 2018 VOIP: IWU: dsp_session_msg_send(call=18243, type=mux)
Mon Oct 29 10:14:02 2018 VOIP: IWU: audio_session_prepare(call=8243):     order codecs = default
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_call_create(mps_call=0x032657A8, sip_call=0x00000000)
Mon Oct 29 10:14:02 2018 VOIP: IWU: msg_recv(call=8243, msg=CC_CALL_EST_REQ) MPS->IWU_LINE for device=line
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_mib_call_state(call_id=530, number=22, number_peer=, direction_is_initiator=0, state=ring)
Mon Oct 29 10:14:02 2018 VOIP: IWU: trap_handler_call_transaction(ev=0xFFFFFFFF)
Mon Oct 29 10:14:02 2018 VOIP: IWU: iwu_cb_sip_call_state(call=8985): ring
Mon Oct 29 10:14:01 2018 VOIP: IWU: iwu_cb_media_call_state(call=8985): initiate
Mon Oct 29 10:14:01 2018 VOIP: IWU: get_codec_audio_mask(call=8985) configured codec mask = ulaw|alaw|g729|dtmf|g722
Mon Oct 29 10:14:01 2018 VOIP: IWU: iwu_call_create(mps_call=0x00000000, sip_call=0x02FCE7E0)
Mon Oct 29 10:14:01 2018 INET: sending SNTP response to 192.168.100.51
Mon Oct 29 10:14:00 2018 INET: sending SNTP response to 192.168.100.52
Mon Oct 29 10:13:59 2018 INET: destroy session, 192.168.100.162:138->255.255.255.255:138 prot: 17
Mon Oct 29 10:13:59 2018 INET: TIMEOUT Session expired: 192.168.100.162:138->255.255.255.255:138 prot=17
Mon Oct 29 10:13:57 2018 INET: destroy session, 192.168.100.11:138->192.168.100.255:138 prot: 17
Mon Oct 29 10:13:57 2018 INET: TIMEOUT Session expired: 192.168.100.11:138->192.168.100.255:138 prot=17
Mon Oct 29 10:13:48 2018 INET: sending SNTP response to 192.168.100.50
Mon Oct 29 10:13:43 2018 INET: destroy session, 192.168.100.111:138->255.255.255.255:138 prot: 17
Mon Oct 29 10:13:43 2018 INET: destroy session, 192.168.100.51:10000->192.168.100.40:10184 prot: 17
Mon Oct 29 10:13:43 2018 INET: TIMEOUT Session expired: 192.168.100.51:10000->192.168.100.40:10184 prot=17
Mon Oct 29 10:13:43 2018 INET: TIMEOUT Session expired: 192.168.100.111:138->255.255.255.255:138 prot=17
Mon Oct 29 10:13:39 2018 INET: destroy session, 192.168.100.51:10000->192.168.100.40:10180 prot: 17
Mon Oct 29 10:13:39 2018 INET: TIMEOUT Session expired: 192.168.100.51:10000->192.168.100.40:10180 prot=17
Mon Oct 29 10:13:37 2018 INET: SIF: Accept [39000000:192.168.100.114:138] -> [1:255.255.255.255:138] :17
Mon Oct 29 10:13:37 2018 INET: new session, 192.168.100.114:138->255.255.255.255:138 prot: 17 parent: false
Mon Oct 29 10:13:35 2018 INET: new session, 80.134.42.131:5060->217.0.25.32:5060 prot: 17 parent: false
Mon Oct 29 10:13:32 2018 INET: new session, 80.134.42.129:5060->217.0.25.32:5060 prot: 17 parent: false
Mon Oct 29 10:13:25 2018 ATM: vdsl3-0: Rx Errors last 2 seconds: 139 CRC 40 FEC: 460744 HEC 98
Mon Oct 29 10:13:24 2018 ATM: vdsl3-0: 139 new Rx Errors: CRC 40 FEC: 460744 HEC 98
Das hier ist nicht gut: "configured codec mask = ulaw|alaw|g729|dtmf|g722", denn mit ulaw gibt es in Deutschland oft Probleme.

Hallo,
danke für die Antwort.
Also ulaw deaktivieren?
----

Habe ich jetzt deaktiviert!

Hallo,

 


@Dominik_  schrieb:


also das mit den drei IP Adressen war mein Fehler!!! es sind nur 2 Stück! 

Dann müßte Dir beim Kopieren des Logs ein Fehler unterlaufen sein? Dort waren ja drei IPs zu sehen. In Deinem neuen Log tauchen zwei IP-Adressen auf (xxx.129 und xxx.131), wobei erstgenannte genau einmal schon im ersten Log auftauchte...

 

Ist der Bintec-Router für beide DeutschlandLAN-Anschlüsse auf eine Verbindungstrennung alle 24 Stunden eingestellt?

 

Heute war es wieder soweit:

Gegen 10:07 Uhr kam ein Anruf rein und das Gespräch konnte nicht angenommen werden, so die Mitarbeiterin.

Ich habe mal versucht so grob das Protokoll zusammen zukürzen auf dne besagten Zeitraum!

Das Protokoll gibt Einträge von 10:14 Uhr wieder, der von Dir geschilderte Anruf war aber um 10:07 Uhr?

 

Für 10:14 Uhr steht im Log ein (anderer?) Anruf drin, der - wenn ich das richtig verstehe - mit der Meldung "complete elsewhere" endete. Eine solche Meldung wird ja eigentlich dann signalisiert, wenn mehrere Endgeräte klingeln, eines davon abgenommen hat und die anderen darüber informiert werden sollen (damit sie den Anruf nicht als Anruf in Abwesenheit anzeigen).

 

Ansonsten scheint mir das  Log leider nicht allzu ergiebig zu sein (zumindest für mich). Ich würde evtl. versuchen, einen Paketmitschnitt zu erstellen und den dann mit Wireshark versuchen zu analysieren. Einen solchen Mitschnitt aber längere Zeit einfach auf Verdacht mitlaufen zu lassen, dürfte aber eine Menge an Daten zusammentragen (alle Gespräche + Internet-Verkehr), sodaß auch nicht unbedingt eine Lösung ist. Man könnte höchstens dann mitschneiden, wenn man dann auch extra Testanrufe o.ä. macht.

 

Du scheinst mir nicht der einzige Nutzer mit einem solchen Problem zu sein, auch hier im Forum gab es bereits ähnliche Diskussionen, die so aber nicht unbedingt 1:1 übertragbar sind:

 

https://telekomhilft.telekom.de/t5/Festnetz-Internet/Digitalisierungsbox-keine-eingehenden-Anrufe/td...

https://telekomhilft.telekom.de/t5/All-IP-das-digitale-Netz/Probleme-mit-Digitalisierungsbox-Premium...

 

Kann es sein, daß das Problem vor allem dann auftritt, wenn eine Weile nicht telefoniert wurde? Funktioniert direkt nach einem vorangegangenen Anruf alles reibungslos?

 

Vielleicht hat kalle2014 noch eine Idee, der kennt sich mit den Bintec-/Digitalisierungsboxen ja ganz gut aus. Fröhlich Ansonsten kannst Du auch mal versuchen, beim Bintec-Support anzufragen.

 

cu talk

Telekom hilft Team
Moin @Dominik_,

ich sehe, dass die anderen User hier schon ganz fleißig waren. Haben Dir die Hinweise geholfen? Übe eine kurze Rückmeldung freue ich mich.

Viele Grüße,
Lin J.

 

Hallo,

 

bei den IP Adressen ist mir tatsälcihc ein Fehler beim Kopieren passiert.

 

Der Hinweis mit dem ULAW und ALAW war sehr gut und hat tatsächlich eine Verbesserung gebracht.

 

Leider ging es nur eine Woche "gut", dann ging es wieder schief. Nun ist es relatvi ruhig. 

Interessanter Weise habe 2 Bekannte (Entffernung 10-15 km) mit einer einfachen FritzBox und einem FritzFon, genau die selben Fehler.
Mal geht es auch bei denen gut und dann wieder Probleme.

 

Denke, dass da bei der Telekom auch noch der Wurm drinne steckt.