Servus zusammen,
ich habe seit einigen Tagen ALL-IP Anchluss, auf dem 1906VA normal mit Setup-Assistenten den VCM konfiguriert.
Wenn der ADSL Anschluss unterbrochen wird (Zwandstrennung, schlichte Ziehen des Verbindungskabels) wird nach kurzer Zeit die Internetverbindung wieder sauber aufgebaut, der VCM verbleibt allerdings dauerhaft im Fehlerzustand, Telefone funktionieren nicht mehr
Im Log stehen schlicht folgene drei Einträge:
Fehler [VCM] SIP-Line xxxx switched to status 'generic failure'
Fehler [VCM] SIP-Line xxxx switched to status 'un-registered'
Fehler [VCM] SIP-Line xxxx switched to status 'generic failure'
Überwachung steht auf automatisch/60sec
aktuelle Firmware 10.70.0181RU2 / 25.10.2022
Es hilft nur irgendeine manuelle Konfigurationsänderung, ist natürlich keine Dauerlösung
Das kannst Du auf Automatisch lassen. Options und Deaktiviert wäre jedenfalls hier eindeutig falsch.
Mal anders gefragt: Ist denn der ADSL-Anschluss die einzige Internetverbindung am LANCOM?
Eine (klassische 24-h-)Zwangstrennung gibt es übrigens nicht mehr, jedenfalls nicht bei der Telekom (bei 1&1 hingegen z. B. noch ja).
ja, nur eine vdsl-Internetanbindung
habe heute auf LCOS 10.72.0015 (Rel) aktualisiert, hat alles hervorragend geklappt
weiterhin allerdings der reproduzierbare Fehler dsl-stecker raus - dsl-stecker wieder rein -> kurz drauf Internetverbindung steht, vcm Leitung 1 steht auf Fehler
Wenn da alle 60sec geprüft wird müsste das doch neu aufgebaut werden ich verstehe das nicht, ist doch jetzt nicht so einesoterischer usecase
kann es daran liegen, dass ich den isdn-port abgeschaltet habe? ich nutze nur die analog-Leitungen...
stimmt, Zwangstrennung kommt nicht vor, das entschärft das Problem etwas...
das war dann vor ein paar Tagen Zufall, dass nachts um 3 die Verbindung kurz unterbrochen war (dadurch bin ich auf dieses Problem gestossen), ich schau die syslogs laufend durch wg des Fehlers
Die SIP Leitung wird erst wieder aufgebaut, wenn man irgendetwas am vcm umkonfiguriert (z.B. das Überwachungsintervall von 60s auf 59s), dann ist kurz darauf der Fehler weg.
Aber mal ehrlich, das kann doch nicht normal sein Ist doch kein billig-Plunder
tbachert hat geschrieben: 21 Dez 2022, 20:31
kann es daran liegen, dass ich den isdn-port abgeschaltet habe? ich nutze nur die analog-Leitungen...
Nein.
tbachert hat geschrieben: 21 Dez 2022, 20:42
Aber mal ehrlich, das kann doch nicht normal sein
In einem älteren Firmwarestand kann ich Dir da auf alle Fälle zustimmen, bei der 10.7x weiß ich es nicht mit Sicherheit.
Irgendwas scheint dann nicht mehr anzulaufen. Entweder man fängt mit Traces an (Callmanager, SIP-Packet) oder man schaut noch mal die Konfig durch, insbesondere auf mögliche Fehler im Bereich DNS oder IP, mitunter finden sich dann Sachen wie sowas hier: fragen-zur-lancom-systems-routern-und-g ... ml#p110141
danke für den Hinweis, schau ich mal durch
ich nutze nur IPv4 (hoffe ich zumindest, IPv6 nicht aktiviert), aber vlt ist da doch irgendein Eintrag in den Untermenu
Beim normalen reboot/starten klappt ja auch alles, ist wirklich nur der Fall der Unterbrechung der VDSL-Verbindung....
Ich hab alles durchgeschaut, tatsächlich war unt IPv6, obwohl deaktiviert, ein Profil vorhanden, habe ich entfernt.
Bei der WAN-Verbindung ist auch keines drin.
Trotz allem: gleiches Verhalten
Unter Kommunikation/Allgemein in der Aktionstabelle ist bei mir kein Eintrag. Könnte man da etwas hinzufügen, das nach Aufbau der WAN-Verbinung eine Re-Registrierung der SIP-Leitung anstupst?
Beim normalen Reboot brauchts das nicht, bei Leitungsunterbrechungen hilft es vielleicht...
Wie kann man das machen, finde keine Beispiele, suche vermutlich nicht richtig
exec: set /Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/LEITUNGSNAME {active} no ; sleep 5s ; set /Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/LEITUNGSNAME {active} yes
hi,
super, vielen Dank, bau ich heute Abend rein und teste das
Klar, workaround, aber unmotiviert abgeschaltete Telefonleitung finde ich nicht so toll, mit workaround ist mir wohler
zur Fehlersuche:
erste Erkenntnis: telekom setzt das re-registerintervall auf 8 Minuten
ich habe den trace callmanager aktiviert und dann stecker raus-stecker rein :
[Callmanager] 2022/12/22 11:36:00,897 [WIZ_T-12345678 Registrar Transport]: IP transport failed
[Callmanager] 2022/12/22 11:36:00,897 [SIP-Provider] : WIZ_T-12345678: connection down
[Callmanager] 2022/12/22 11:36:00,915 [SIP-Provider] : WIZ_T-12345678: stopRegistration: this:0ccccccc, caller:0aaaaaaa, registration:enabled, register_info:active
[Callmanager] 2022/12/22 11:36:00,921 [SIP-Provider] : Line 'WIZ_T-12345678' changed status to 'NOT operable'
[Callmanager] 2022/12/22 11:36:00,928 [WIZ_T-12345678 Registrar Transport]: New restart backoff is 1 seconds
[Callmanager] 2022/12/22 11:36:00,928 [WIZ_T-12345678 Registrar Transport]: Restarting in 1 seconds
[Callmanager] 2022/12/22 11:36:00,928 [WIZ_T-12345678 Registrar Transport]: Transport failed
[Callmanager] 2022/12/22 11:36:00,928 [SIP-Provider] : WIZ_T-12345678: registrar transport failed
[Callmanager] 2022/12/22 11:36:00,928 [SIP-Provider] : WIZ_T-12345678: Tear down registrar transport for SipLineTransport 0x0eeeeeee
[Callmanager] 2022/12/22 11:36:00,928 [SIP-Provider] : WIZ_T-12345678: Line's own SipLineTransport
[Callmanager] 2022/12/22 11:36:00,934 [SIP-Provider] : WIZ_T-12345678: stopRegistration: this:0ccccccc, caller:0aaaaaaa, registration:enabled, register_info:NOT active
[Callmanager] 2022/12/22 11:36:01,928 [WIZ_T-12345678 Registrar Transport]: (Re)Starting with domain name "tel.t-online.de"
[Callmanager] 2022/12/22 11:36:01,928 [WIZ_T-12345678 Registrar Transport]: cSipLineTransport::Start - m_DnsKey: <tel.t-online.de, Tag 0>
[Callmanager] 2022/12/22 11:36:01,928 [WIZ_T-12345678 Registrar Transport]: cSipLineTransport::Start 1 - DnsName: tel.t-online.de, m_DnsKey: tel.t-online.de
[Callmanager] 2022/12/22 11:36:01,928 [WIZ_T-12345678 Registrar Transport]: cSipLineTransport::Start 2
danach passiert gar nichts mehr. Zu der Zeit, zu der obige Logausgaben gemacht wurden, war die VDSL-Leitung noch nicht wieder da, braucht mit training ca 1 min
Hallo zusammen,
noch kurz zu obigen trace: sip-Aktivitäten gibt es da überhaupt nicht, habe gestern extra nochmal trace sip-packet aktiviert als ich den workaround getestet hatte.
es scheint, als ob der callmanager da viel zu früh seinen restart probiert und dann zu schnell aufgibt oder irgendwie hängen bleibt. kann man da irgendwelche retry-parameter konfigurieren? ich habe nichts gefunden. gibts irgendwo noch log-Möglichkeiten? Wenn das Kasterl nicht verrät, was ihm fehlt, kann man schlecht helfen
anyway, mit dem workaround kann ich derweil gut leben