Moin zusammen,
ich habe ein Problem, bei dem ich nach tagelanger eigener Fehlersuche nicht weiterkomme, und hoffe, dass mir hier jemand mit mehr Erfahrung an dieser Anlage helfen kann. Ich versuche, die Situation möglichst vollständig zu beschreiben, damit ihr nicht erst alles aus mir herausfragen müsst – falls trotzdem was fehlt, einfach melden, ich liefere gerne weitere Traces oder Screenshots nach.
Anlage: Aastra/Mitel OpenCom X320, Firmware R 1.379.19.3, Release 9.12Anschluss: Telekom CompanyFlex SIP-Trunk → Digitalisierungsbox Premium 2 → 2x S0 (ISDN1+ISDN2, beide Anlagenanschluss/Punkt-zu-Punkt) → OpenComVorher: Klassischer Vodafone-Anlagenanschluss, jahrelang ohne Probleme. Die Umstellung war der einzige Auslöser.
Egal welche externe Durchwahl gewählt wird (z. B. 51, 56, 60, 66, 73 – Durchwahlbereich 50–79), die Anlage klingelt nicht bei der Zielnebenstelle, sondern immer beim Sammelruf/Zentrale (Nebenstelle 50). Eine direkte Wahl der 50 von außen funktioniert dagegen einwandfrei und sofort.
Im D-Kanal-Trace (Diagnose → Trace) ist die Called Party Number im SETUP korrekt zu sehen (z. B. "51"). Im CONNECT, das die OpenCom zurückschickt, steht aber immer als Connected Number die Stammnummer + "50" – unabhängig davon, welche Durchwahl tatsächlich gewählt wurde. Die Fehlzuordnung passiert also nachweislich innerhalb der OpenCom, nicht beim Provider/Gateway.
Manchmal (nicht immer, vermutlich abhängig von Timing) zeigt das Telefon nach Annahme "Protokollfehler", es ist keine Sprachverbindung möglich. Im Trace zeigt sich dabei ein klares Muster:
Vermutung: Beide Symptome haben dieselbe Ursache. Der unnötige interne Umleitungsschritt (Durchwahl → Zentrale) braucht variabel lange, und wenn er die 4-Sekunden-Schwelle überschreitet, kollidiert das mit T313.
Wo wird bei einem Anlagenanschluss mit Durchwahlblock (hier 50–79) tatsächlich festgelegt, welche Nebenstelle eine eingehende Durchwahl erreicht, wenn weder die Kommend-DDI-Tabelle noch die Zentrale-Zuordnung das gewünschte Verhalten zeigen? Gibt es eine weitere, möglicherweise versteckte Einstellung, die das Zusammenspiel zwischen "Zentrale" und "Kommend DDI" steuert (z. B. ein Schalter, der die DDI-Tabelle überhaupt erst "aktiviert")?
Hat jemand dieses Verhalten schon mal konkret im Zusammenspiel OpenCom X320 + Telekom Digitalisierungsbox Premium 2 + CompanyFlex gesehen und lösen können? Für jeden Hinweis wäre ich sehr dankbar – bin auch gerne bereit, weitere Traces oder Screenshots nachzuliefern.
Danke schon mal fürs Lesen und für jede Idee!
Viele Grüße
ich habe ein Problem, bei dem ich nach tagelanger eigener Fehlersuche nicht weiterkomme, und hoffe, dass mir hier jemand mit mehr Erfahrung an dieser Anlage helfen kann. Ich versuche, die Situation möglichst vollständig zu beschreiben, damit ihr nicht erst alles aus mir herausfragen müsst – falls trotzdem was fehlt, einfach melden, ich liefere gerne weitere Traces oder Screenshots nach.
Anlage: Aastra/Mitel OpenCom X320, Firmware R 1.379.19.3, Release 9.12Anschluss: Telekom CompanyFlex SIP-Trunk → Digitalisierungsbox Premium 2 → 2x S0 (ISDN1+ISDN2, beide Anlagenanschluss/Punkt-zu-Punkt) → OpenComVorher: Klassischer Vodafone-Anlagenanschluss, jahrelang ohne Probleme. Die Umstellung war der einzige Auslöser.
Symptom 1: Durchwahlen landen immer auf der Zentrale
Egal welche externe Durchwahl gewählt wird (z. B. 51, 56, 60, 66, 73 – Durchwahlbereich 50–79), die Anlage klingelt nicht bei der Zielnebenstelle, sondern immer beim Sammelruf/Zentrale (Nebenstelle 50). Eine direkte Wahl der 50 von außen funktioniert dagegen einwandfrei und sofort.
Im D-Kanal-Trace (Diagnose → Trace) ist die Called Party Number im SETUP korrekt zu sehen (z. B. "51"). Im CONNECT, das die OpenCom zurückschickt, steht aber immer als Connected Number die Stammnummer + "50" – unabhängig davon, welche Durchwahl tatsächlich gewählt wurde. Die Fehlzuordnung passiert also nachweislich innerhalb der OpenCom, nicht beim Provider/Gateway.
Symptom 2: Sporadischer "Protokollfehler", kein Ton
Manchmal (nicht immer, vermutlich abhängig von Timing) zeigt das Telefon nach Annahme "Protokollfehler", es ist keine Sprachverbindung möglich. Im Trace zeigt sich dabei ein klares Muster:
- Bei direkter Anwahl der 50: CONNECT → CONNECT_ACK kommt in ~40–100 ms zurück. Funktioniert immer.
- Bei einer Durchwahl (die ja intern auf 50 "umgeleitet" wird): CONNECT_ACK kommt mal in ~2 Sek. (Gespräch geht), mal erst nach >4 Sek. zurück → T313-Timer läuft ab, OpenCom wirft die Verbindung selbst mit Cause 102 ("Recovery on timer expiry") weg → Protokollfehler.
Vermutung: Beide Symptome haben dieselbe Ursache. Der unnötige interne Umleitungsschritt (Durchwahl → Zentrale) braucht variabel lange, und wenn er die 4-Sekunden-Schwelle überschreitet, kollidiert das mit T313.
Was bereits geprüft/ausgeschlossen wurde
- Persönliche Rufumleitungen an den Geräten (Telefonie → Geräte → Funktionen): keine aktiven Sofort-Umleitungen auf 51/73.
- Sammelruf-Mitgliedschaft: betroffene Nebenstellen sind kein Mitglied von Sammelruf 50.
- Anrufverteilung → Kommend: komplett leer.
- Anrufverteilung → Kommend DDI: war ursprünglich komplett leer ("Kein Eintrag"). Habe testweise Einzeleinträge angelegt (z. B. Durchwahl 51 → Tag 51 / Nacht 51, ebenso für 56/60/66/73), inkl. Neustart der Anlage. Einträge waren nachweislich gespeichert und persistent (auch nach Neustart vollständig vorhanden) – am Routing-Verhalten hat sich aber nichts geändert, Connected Number bleibt "...50".
- Wildcard-Versuche in Kommend DDI (z. B. "5*" / "6*" / "7*" oder reines "*"): werden von der Eingabevalidierung als "ungültige Rufnummer" bzw. mit "unbekanntem Fehler" abgelehnt.
- Telefonie → Zentrale: Hier liegt offensichtlich der entscheidende Hebel – die "Rufnummer" der Zeitgruppe steht auf Tag=50/Nacht=99. Testweise auf 51 geändert: alle externen Anrufe landeten daraufhin auf 51 statt 50. Zurück auf 50: wieder alles auf 50. Das bestätigt, dass dieses Feld aktuell unconditional als Ziel für jeden externen Anruf verwendet wird – unabhängig von der gewählten Durchwahl und unabhängig vom Inhalt der Kommend-DDI-Tabelle.
- ISDN-Port-Konfiguration (Telefonie → Anschlüsse → S0): beide Ports identisch auf Anlagenanschluss/Punkt-zu-Punkt, Bus-Abschluss aktiv, MSN-Felder leer (wie für Anlagenanschluss erwartet).
- Physische Verkabelung zwischen Digitalisierungsbox und OpenCom getauscht (neues Patchkabel): hat einen separaten, sporadisch auftretenden Layer-2-Framing-Fehler ("Invalid Adressfield Extension Bit") im Kernel-Log offenbar behoben, aber am Routing-Problem nichts geändert.
Die eigentliche Frage
Wo wird bei einem Anlagenanschluss mit Durchwahlblock (hier 50–79) tatsächlich festgelegt, welche Nebenstelle eine eingehende Durchwahl erreicht, wenn weder die Kommend-DDI-Tabelle noch die Zentrale-Zuordnung das gewünschte Verhalten zeigen? Gibt es eine weitere, möglicherweise versteckte Einstellung, die das Zusammenspiel zwischen "Zentrale" und "Kommend DDI" steuert (z. B. ein Schalter, der die DDI-Tabelle überhaupt erst "aktiviert")?
Hat jemand dieses Verhalten schon mal konkret im Zusammenspiel OpenCom X320 + Telekom Digitalisierungsbox Premium 2 + CompanyFlex gesehen und lösen können? Für jeden Hinweis wäre ich sehr dankbar – bin auch gerne bereit, weitere Traces oder Screenshots nachzuliefern.
Danke schon mal fürs Lesen und für jede Idee!
Viele Grüße