Mitel SMBC.Controller will (teilweise) nicht

Es gibt 15 Antworten in diesem Thema, welches 3.219 mal aufgerufen wurde. Der letzte Beitrag () ist von RaSti.

  • Hallo miteinander.


    Ich sitze hier gefüllt seit 24h Arbeitszeit an einem Problem und finde die Lösung nicht...


    Ich wurde letztes Jahr hier in eine (kleine) Arztpraxis gerufen, weil der Internet-Zugang nicht mehr funktioniert. Grund war ein gekündigter Wartungsvertrag mit SecurePoint, so das die Black Dwarf G3 alle Verbindungen verweigert hat. Ich habe dann ein in meinem Fundus befindliches USG 3P anstatt der Black Dwarf installiert, an das Netz-Design angepasst und es lief erst mal alles wieder.


    Jetzt habe ich in den Osterferien den 10 Jahre alten DELL Server durch einen modernen EPYC getauscht und minimale Änderungen am Netzwerkdesign vorgenommen. PC-technisch funktioniert auch alles.


    Hier das Netzwerkdesign:


    Internet -- VIGOR 165 -- USG 3P -- USW500-48 -- Endgeräte:


    Standardnetz: 192.168.178.0/24, USG ist Gataway und DHCP mit der 192.168.178.1

    Praxisnetz: VLAN 20, USG 192.168.1.254; DHCP vom USG, DNS macht der alte Windowsserver mit 192.168.1.1 (historisch bedingt!!)


    Achja, der Controller läuft als Dockercontainer.


    Das slebe Setup hatte ich bis vor 4h auch mit pfsense so eingerichtet. VPN, Netzwerkzugriffe, WLAN. Alles fein.


    ABER!!!!!!


    Es hängt eine Mitel SMBC 400 samt zwei IP-Systemtelefonen sowie einer DECT-Basis (analog an der Mitel) mit im Netz. Da in der Vergangenheit bei Fehlern des Windowsservers (DNS-Server und DHCP) auch die Telefonie tot war, war (uns ist) mein Plan, die Telefonie in ein separates VLAN zu hängen und damit unabhängig vom Praxisnetz zu machen.

    Ergänzung 23.4.: sowohl die Mitel als auch die beiden IP-Telefone sind an dem Switch-Ports auf Praxisnetz gesetzt, um keine Probleme vit dem VLAN zu bekommen.


    Zugriff auf die TK-Anlage habe ich nicht, da muss ich mit einem Dienstleister Kontakt aufnehmen.


    PROBLEM:

    Ich kann reinwählen, es klingelt. Ich kann rauswählen, es klingelt. Die Signalisierung als solche funk Das Faxgerät (analog an der mitel) und das DECT-Telefon funktionieren problemlos. Die beiden Systemtelefone haben Kontakt zur Anlage, die richtige IP. Nur Sprachdaten scheinen nicht übertragen zu werden - sprich weder intern noch extern ist nach der Rufannahme irgendein Ton zu hören.


    Was habe ich unternommen:

    Ich habe mehrere ausführliche Dokumente des Telefondienstleisters, welche Ports die Anlage in der Firewall offen haben möchte. Da ich trotz Paketmitschnitts das Problem mit der pfSense nicht identifiezieren konnte, war mein Ansatz, wieder das USG 3P einzubinden. Mit dem hat es ja bereits über 6 Monate ohne besondere Einstellungen funktioniert. Also habe ich heute das USG wieder eingebunden, die Netzwerke wieder eingerichtet und die festen IP-Zuordnungen wieder im USG hinterlegt. Jetzt habe ich aber den selben Effekt wie mit der pfSense. Das einzige Gerät, welches ich noch ausgetauscht habe und welches ich auch nicht so einfach zurücktauschen kann, ist der 49-Port Uniti-Switch. Der alte war ein einfacher 24er, der auch nicht managbar war. Da aber der neue Server per 10Gb an dem Switch hängt, ist es nicht so einfach rückbaubar.


    Hat jemand noch einen Denkanstoß?


    Lt. Telefon-Dienstleister werden für die Anlage und die Telefone offene Ports benötigt. Ich betreue noch zwei Installationen mit USG-Pro, da hängen jeweils AGFEO-Anlagen dahinter, auch mit Systemtelefonen. Da habe ich keine Ports nach außen aufmachen müssen, die werden immer von innen nach außen geöffnet und am Ende des Gesprächs wieder geschlossen.


    Vielen Dank. Falls Info s fehlen, ich liefere die gerne nach. Jetzt setze ich mich erst mal aufs Fahrrad.... :thinking_face:


    LG

    RaSti

    Einmal editiert, zuletzt von RaSti ()

  • Da hast Du keine von außen offenen UDP-Ports für die Sprachkanäle, zumindest keine, welche auf die Mitel zeigen.

    Guten Morgen.


    Ich vermute auch die Info in dieser Richtung.

    Stolpern tue ich über die Tatsache, das ich diese vorher auch nicht explizit bgeöffnet habe und es hat funktionert.

    Tatsächlich bin ich im Bereich VoIP nicht ganz so fit. Rudmentär: Es kommt ein Anruf rein, der von der TK-anlage angenommen und an die endgeräte signalisiert wird. Das läuft über Port 5060/5061. Diese Ports sind während der Registrierung der Telefonnummern beim Provider von LAN => WAN geöffnet worden und werden offengehalten. Die TK-anlage signalisiert an die IP-Telefone, deren IPs sie ja kennt, denn kommenden Ruf. Die klingeln auch. Jetzt müssen die IP-Telefone die RTP-Ports nach außen öffnen, um die Sprachpakete zu transportieren. Das geht dann auch von LAN => WAN.

    Und an dieser Stelle hänge ich beim Verständnis. Wenn die Telefone dynamisch die Ports öffnen, dann brauche ich doch in die Frewall kein Loch bohren??


    Ich hatte in der pfSense die Ports anhand der Dokumentation von Mitel geöffnet. Das hat nicht funktioniert. Ich konnte im Mitschnitt das INVITE des Anrufs lesen, habe aber leider nicht die Stelle gefunden, an der das Problem auftritt. (WireShark ist nicht mein tägliches Arbeitsgebiet).


    Vielen Dank schon für den Denkanstoß.


    Zur Info: Ich verdiene mein Brötchen als Krankenpfleger. Das gewerblich ist der Tatsache geschuldet, das ich nebenberuflich 3 Arztpraxen und 3 kleiner Unternehmen betreue, die sich die Preise des Systemhäuser nicht leisten wollen oder können. (auch wenn ich das gerade in solchen Fällen immer empfehle)


    LG

    RaSti

  • hab ich richtig verstanden das die Mittel TK Anlage in der Praxis hängt !?

    Wie verhält es sich wenn du von Telefon A zu Telefon B "INTERN" telefonierst... das sollte ja nicht über Extern laufen... und auch mit der Sprache klappen!?


    Was du nicht geschrieben hast, wie wird die Mittel ans TK angeschlossen? Hast du einen Trank oder nimmst du einen ISDN Anschluss von der Fritzbox?

    Der Fehler liegt auf jedenfall bei den Sprachkanälen... hier muss ne richtig große Anzahl an Ports für freigeschaltet werden... Die Com-Ports laufen ja...


    Wie sind die Telefone an der Mittel verbunden? die kannst du ja via "VoIP" oder via "IP" anschließen...das ist ja ein Unterschied...

    DSL und Starlink - U-LTE-Pro | Vigor160 | UDM-Pro | UNVR | USW-Pro-Aggregation | USW-Pro-48-PoE - 5x USW-Pro-24-PoE - 5x USW-Flex - USW-Enterprice-24-PoE | 2x SmartPower RPS | 12 x UAP-U6-Lite - 8x UAP-U6-Mesh | 15x UVC-G4Pro - 20x UVC-G4-Bullet 6x UVC G4 Dome | UVC G4 Doorbell | 8x UFP-Viewport | 8x G3 Instant | 2x G4 Instant | AI-Bullet 360 - Ai-Bullet

    2x APC UPS-2200VA gekoppelt mit Dieselgenerator mit ATS

    Access: UA-G2-Pro

    Smarthome: ca. 160 Shelly´s aller Art im Einsatz

    Tel: 3CX mit Snom Telefonen

  • Vielen Dank für Deine Antwort.


    Ich merke, ich habe nicht alle Informationen angegeben.

    Ja, die Mitel hängt in der Praxis.


    Intern ist bei den beiden IP-Telefonen das selbe Problem: Klingeln (also die Signalisierung) funktioniert, Sprachdaten werden nicht übertragen.


    Die Mitel ist genau wie die beiden Telefone per IP angeschlossen. DSL-/Telefonie-Anbieter ist die Telekom. Die Mitel registriert sich ohne Problem sofort nach Neustart mit den Telekom-Servern. Wenn ich es richtig gesehen habe, ist es kein SIP-Trunk, sondern einzelne Accounts.


    Ich habe keinen Zugriff auf die Mitel-Anlage. Ich konnte dem Dienstleister nur "über die Schulter schauen", als er über Teamviewer die Einstellungen kontrolliert hat. Ansonsten kommt er auch ohne solche Software auf die Anlage. Ich vermute, die hat dafür einen Fernwartungsport oder so offen, in der FW musste ich dazu nix freigeben. In der Anleitung des Telefondienstleisters steht explizit, das von WAN => LAN nix freigegeben werden muss, sondern nur von LAN => WAN. Diese Ports habe ich freigegeben.


    (Da die Problematik trotz freigegebener FW-Ports sowohl bei dem USG als auch bei der pfSense auftritt, habe ich den Telefon-Dienstleister gebeten, die Einstellungen in der Anlage zu überprüfen. Im Gegensatz zu mir arbeitet der aber nur Mo-Fr. 8:00 - 16:30 Uhr..)


    LG

    RaSti

  • die kannst du ja via "VoIP" oder via "IP" anschließen...das ist ja ein Unterschied...

    Klär bitte mich auf siehst du den unterschied ist zwischen Voice über IP und IP ?


    Die TK-anlage signalisiert an die IP-Telefone, deren IPs sie ja kennt, denn kommenden Ruf. Die klingeln auch. Jetzt müssen die IP-Telefone die RTP-Ports nach außen öffnen, um die Sprachpakete zu transportieren. Das geht dann auch von LAN => WAN.

    Halbe Miete hast du also schon. Signaling geht...BEIDSEITIG Kein Audio ist aber selten.


    Klingt nach UDP wird geblockt. Oder Carrier versucht zu ner völlig falschen IP das Audio zu senden und gibt

    auch der TK die info an ne völlig krumme ip was zu versenden. Auf der USG hast du das Connection Tracking für SIP

    aus ?


    Sonst Trace mache:


    1.) Am Mitel Port selber

    2.) Auf der USG der kram der nach draußen geht.


    tcpdump ist überall drauf, remote Capture ist keine Raketen Wissenschaft oder ein file schreiben und runterladen

    auch kein Hexenwerk. Irgendwo muss das RTP ja hingesendet werden, bzw. der Rückstrem empfangen werden.


    Überlicherweise und im Jahre 2023. Wird im SIP Dialog genauer im SPD IP und Ports ausgetauscht.

    Die Carrier Ignoriere dabei meist die IP im SDP da steht eh nur die Interne LAN IP drinne und

    senden an die Registrierung IP und de PORT im SDP. Da brauch auch nichts weitergeleitet zu werden.

    Early Media macht das Loch schon auf im NAT und öffnet damit auch den Rückweg.

    Die Carrier können mit NAT umgehen.


    Achtung grade Telekom: für jegliche Voice Geschichten bitte die Telekom DNS Server verwenden

    die bei der PPPOE Verbindung gelernt wurden. Jeglicher andere DNS haben OFT die Falsche IP für die

    Media Server der Telekom. Da löst dann die TK was auf wo der RTP Stream nicht hinsoll

    Das hat sich zwar gebessert in den letzen Jahren ist aber immer noch ein Problem (oder Absicht,

    teilweise wurden / werde da Regionale media Server zugeteilt über die gleiche Namen, ein großer

    moloch bei den auch der secondlevel keine Ahnung von hat)

  • Klär bitte mich auf siehst du den unterschied ist zwischen Voice über IP und IP ?

    Bei einen "IP-Telefon" handelt es sich um ein Systemtelefon welches nicht per VoIP Account mit der Mittel Anlage verbunden wird, sondern von der Mittel die Konfig bekommt. Diese Telefone funktionieren im Gegensatz zu VoIP-Telefon auch NUR an der Mittel Anlage im localen Netzwerk. Vorteil sind meistens, dass mehr Funktionen zur Verfügung stehen. Die Einbindung sehr einfach und schnell läuft und gerade bei Hybrid-TK-Anlagen die im Gegensatz zu einer Asterisk oder 3CX nicht von vorneweg als vollwertige VoIP-TK-Anlage gebaut wurden... Ein "IP-Telefon" funktioniert zb. nur Local... wobei du ein VoIP-Telefon auch extern im Homeoffice aufstellen kannst... Die Einbindung ist einfach nur leichter und die Telefone sind meist auch günstiger.


    Heutzutage gibt es ja quasi nur noch VoIP Telefone… allerdings muss man wissen wo Mittel herkommt und was die alles aufgekauft haben… Opencom, DeteWe wie auch Ascotel gehören mittlerweile zu Mittel. Gerade bei Ascotel und Opencom gibt es diese Unterschiede bei den Systemtelefonen zwischen IP und VoIP ! Dies liegt daran, dass man unendliche viele IP-Systemtelefone an eine Anlage kostenfrei anschließen kann, wobei für VoIP man extra Lizenzgebühren bezahlen muss !

    DSL und Starlink - U-LTE-Pro | Vigor160 | UDM-Pro | UNVR | USW-Pro-Aggregation | USW-Pro-48-PoE - 5x USW-Pro-24-PoE - 5x USW-Flex - USW-Enterprice-24-PoE | 2x SmartPower RPS | 12 x UAP-U6-Lite - 8x UAP-U6-Mesh | 15x UVC-G4Pro - 20x UVC-G4-Bullet 6x UVC G4 Dome | UVC G4 Doorbell | 8x UFP-Viewport | 8x G3 Instant | 2x G4 Instant | AI-Bullet 360 - Ai-Bullet

    2x APC UPS-2200VA gekoppelt mit Dieselgenerator mit ATS

    Access: UA-G2-Pro

    Smarthome: ca. 160 Shelly´s aller Art im Einsatz

    Tel: 3CX mit Snom Telefonen

  • Vielen dank für deine Sicht der Dinge. Finde ich allerdings eher verwirrend.


    Also nur das VOIP vs IP-Telefon finde ich eher verstörend. Auch wenn hier und da einige

    Hersteller da was anderes drunter verstehen möchten oder wollen.


    Jedes Telefon das über IP kommuniziert ist ein IP Telefon denn es macht Sprache über IP, Englisch Voice over IP oder abgekürzt

    VOIP. Völlig egal ob das Ding nun direkt mit einem SIP Carrier kommuniziert oder ein eine TK Anlage dazwischen ist.


    Natürlich kann und man muss sogar feiner unterscheiden.

    Systemtelefone die nur an der Hersteller Anlagen Funktionieren, bringen eigne Protokolle oder

    eigne Erweiterungen der Protokolle mit und damit Dinge anzubieten die so nicht gedacht sind

    (oder weil sie einfach nicht wollen das jemand billige Telefon kauft).


    Ein "IP-Telefon" funktioniert zb. nur Local... wobei du ein VoIP-Telefon auch extern im Homeoffice aufstellen kannst...

    Sag das bitte nicht meinen h323 Systemtelefonen hier im HomeOffice... nicht das sie aufhören zu funktionieren.

    (wenn der Sarkasmus gestattet ist)





  • Also diese "IP-Telefone" können zB. kein SIP ! Du kannst hier keine VoIP Accounts hinterlegen. Das ist derUnterschied zu VoIP Telefone die offen sind...

    Du kannst natürlich mit viel Aufwand und Portweiterleitungen und so die Dinger auch von Zuhause versuchen anzuschließen... Nur kann das ein einfacher Laie nicht so einfach, wie einen SIP Account einzurichten.

    Ich habe hier noch eine Opencom X320 Anlage mit diesen Telefonen stehen... wenn interesse besteht, bitte einfach kurz melden... :winking_face:

    Dateien

    DSL und Starlink - U-LTE-Pro | Vigor160 | UDM-Pro | UNVR | USW-Pro-Aggregation | USW-Pro-48-PoE - 5x USW-Pro-24-PoE - 5x USW-Flex - USW-Enterprice-24-PoE | 2x SmartPower RPS | 12 x UAP-U6-Lite - 8x UAP-U6-Mesh | 15x UVC-G4Pro - 20x UVC-G4-Bullet 6x UVC G4 Dome | UVC G4 Doorbell | 8x UFP-Viewport | 8x G3 Instant | 2x G4 Instant | AI-Bullet 360 - Ai-Bullet

    2x APC UPS-2200VA gekoppelt mit Dieselgenerator mit ATS

    Access: UA-G2-Pro

    Smarthome: ca. 160 Shelly´s aller Art im Einsatz

    Tel: 3CX mit Snom Telefonen

  • VoIP ist VoIP ... einfach nur Voice over IP. Die Systemtelefone haben nur jede Menge Erweiterungen des "Standards".


    Und Mitel war mal DeTeWe ... und zusammengekauft wurden die ganzen Bastelbuden (der Marktanteil ist eher klein) von einem Kanadischen Groß Agra Konzern ...


    Offenbar wurde an der Netzinfrastruktur dann doch soviel geändert, dass nichts mehr geht. Einfach mal den alten Zustand mit dem neuen Vergleichen. Da muss der Hund ja begraben sein, wenn an der TK-Anlage und am Telefonieprovider nichts verändert wurde.


    Was genau sind denn die kleinen Änderungen am Netzwerk?


    Ausfall der Telefonie bei Serverausfall ... warum dieses? Nutzt die TK-Anlage und die IP Telefone etwa den Windows Server als DNS und ggf. DHCP? Hätte man auch einfach auf den Router zeigen lassen können und die zwei Telefone mit festen IPs versehen. Dann kann bis auf Router und Switch alles abgeschaltet sein und die Telefonie läuft noch.


    Habe ich das richtig verstanden, dass sowohl Fax und auch Dect (ist die Basis UP0 oder auch IP) eingehend und ausgehend einwandfrei funktionieren? Dann liegt das Problem wohl eher nicht an der Anbindung zum Provider sondern im LAN. Wenn ich mich noch ganz dunkel an einen Mitel Lehrgang (da hießen die Aastra) erinnere, hatten die damals die Möglichkeit die IP Gespräche immer über die Anlage zu führen oder alternativ war die Anlage nach Vermittlung raus. Wie ist das denn jetzt, falls es diese Einstellungen noch gibt?

  • Also diese "IP-Telefone" können zB. kein SIP ! Du kannst hier keine VoIP Accounts hinterlegen. Das ist derUnterschied zu VoIP Telefone die offen sind...

    Du kannst natürlich mit viel Aufwand und Portweiterleitungen und so die Dinger auch von Zuhause versuchen anzuschließen... Nur kann das ein einfacher Laie nicht so einfach, wie einen SIP Account einzurichten.

    Ich habe hier noch eine Opencom X320 Anlage mit diesen Telefonen stehen... wenn interesse besteht, bitte einfach kurz melden... :winking_face:

    Für sowas hat der liebe Gott VPN erfunden - gerne auch Site2Site.

  • Ich habe hier noch eine Opencom X320 Anlage mit diesen Telefonen stehen...

    Huch ne alte ISDN Schleuder aufgewertet mit IP. Da Konten je nach karte auch noch nicht IP Systemtelefone drann.

    Wieviele Gespräche gleichzeitig kann die 8 ?


    Seite 98...

    Der Begriff „Voice over IP“ bezeichnet ganz allgemein die Nutzung von IP- basierten Datennetzen für die Telefonie. Es kann zwischen zwei verschiedenen Arten von VoIP unterschieden werden


    Machen da auch kein Unterschied...ganz im Gegenteil, auf den folgenden Seiten wir VOIP und IP-telefone

    Benutzt um das gleiche zu beschrieben. IP ist halt IP wie ich oben geschrieben völlig egal was für ein Protokoll

    da im Layer 7 steckt...


    Mein Telefon kann kein SIP trotzdem ist da ein Account hinterlegt mit IP, User, Passwort

    (ok ja der user nennt sich Extension und ist die Telefonnummer).

    Ich will dich nur sagen das es keinen Unterschied gibt VOIP oder IP telefon sind das gleiche.

    Völlig egal wie das dann im einzelnen womit Kommuniziert.


    wenn interesse besteht, bitte einfach kurz melden...

    Ich biete 10 Euro :smiling_face: Nein kleiner scherz ich benötige die nicht..


    hatten die damals die Möglichkeit die IP Gespräche immer über die Anlage zu führen oder alternativ war die Anlage nach Vermittlung raus

    Keine Ahnung wie das bei Mitel heißt aber "Direct Audio IP" oder "Shuffled audio.

    Hat ein wenig an Bedeutung verloren wo auch kleine Systeme genügen Ressourcen

    haben um das Audio auch für Interne Verbindungen über die TK laufen zu lassen und es gibt weniger

    Probleme mit halte Musik und co..



  • So.


    Das Problem ist identifiziert und behoben.


    Ich konnte den Dienstleister überzeugen, die Anlage einmal neu zu starten. Und schon funktioniert wieder alles....

    Ich wollte die nicht einfach stromlos machen, ist ja im Prinzip schon ein Linuxsystem darunter. Ich habe aber jetzt für zukünftige Experimente einen Tipp, wie ich die trotzdem runterfahren kann.

    Mein Vermutung: Während des Umbaus war die Anlage mehrfach ohne LAN und hat sich da irgendwo verheddert. Oder sie war einfach bockig.


    Ich möchte mich bei allen bedanken! Ich habe wieder einiges dazugelernt.

  • OK ... da hätte ich jetzt nicht mit gerechnet, dass die Anlage noch nicht mal neu gestartet wurde :smiling_face: Reboot tut auch bei TK-Anlage gut. Kollege hat heute ne Unify kaltgestartet ... die wollte sich nach nem Internetausfall nicht mehr mit dem SIP Trunk registrieren und ein normaler Reboot hat auch nicht wirklich geholfen. Naja viel Software und Bastelei der Hersteller ... weiß der Geier was die Kisten manchmal so für Problemchen haben.


    Aber schön für die Arztpraxis ... dann kann es ja weiterklingeln und man weiß dass jemand dran wäre, wenn man denn ran gehen würde .... so meine persönliche Erfahrung mit Anruferreichbarkeit von Praxen :smiling_face:

  • Was genau sind denn die kleinen Änderungen am Netzwerk?



    Ausfall der Telefonie bei Serverausfall ... warum dieses? Nutzt die TK-Anlage und die IP Telefone etwa den Windows Server als DNS und ggf. DHCP? Hätte man auch einfach auf den Router zeigen lassen können und die zwei Telefone mit festen IPs versehen. Dann kann bis auf Router und Switch alles abgeschaltet sein und die Telefonie läuft noch.

    Ursprünglich habe ich den NoName 16-Port-Switch durch einen 48- USW-500 ersetzt, eine pfSense auf einen Black Dwarf3G gepackt und den Schrank etwas geordnet.

    Von den Vorgängern habe ich in der Tat solch ei Setup übernommen. Ein ESXi 6.5. mit 2 Windows Server 2012 Standard. Der erste Server hat DNS und DHCP gemacht. Ich wollte (und werde) die Telefonie in ein VLAN hängen und dadurch unabhängig vom neuen Server machen. DHCP macht auch die Firewall, DNS fürs Praxisnetz der Windows-Server. Ist einfacher im AD, auch wenn ich ein AD für 2 Benutzer als übertrieben erachte.


    Und das ich die Mitel nicht neu gestartet habe: Ich habe keinen Zugriff auf das Menü und kenne erst seit heute die Möglichkeit, das Teil trotzdem herunterzufahren.


    Nochmals vielen Dank für die Hilfe!


    LG

    RaSti