Mitel RFP 35 Firmware

Hallo,
ich möchte unsere Mitel RFP 35 Basen ein Firmware Update verpassen, da wir zur Zeit sehr schlechte Audioqualität bei den angerufenen Gesprächspartnern haben (Roboterstimme kurze Aussetzer im laufenden Stream) Im selben Netzwerk angeschlossene T46S haben diese Probleme nicht.
Die Option “reflektive Umgebung” ist eingeschaltet.

Über weitere Vorschläge zur Beseitigung dieser Fehler wäre ich sehr froh.

Kann mir jemand die aktuellste Mitel Firmware Freigeben bitte?

Vielen Dank

Gruß Seb!

Roboterartige Stimmen und Aussetzer sind nahezu immer auf unzureichende Qualität bei den Netzwerkverbindungen oder speziell bei DECT unzureichende Feldstärke zurück zu führen.

Sicher ist eine aktuelle Firmware immer sinnvoll, gleichwohl solte immer auch im Auge behalten werden, was sich sonst noch verändert haben könnte im Netzwerk / an den physikalischen Gegebenheiten wie Bebauung, Nutzungsänderung der Räumlichkeiten etc.

Mal ein Beispiels zum Verständnis: Stell Dir ein Materiallager vor, in dem immer nur Kartonagen gelagert wurden. Aus betrieblichen Gründen ist dieser Raum nun voll gepackt mit 1000 Liter Fässern an Flüssigkeiten. Schon hast Du komplett andere physikalische Voraussetzungen und ganz neue Herausforderungen bei der Funkversorung. Das Beispiel ist zur Veranschaulichung bewusst extrem gewählt, es reichen häufig viel kleinere Veränderungen, die einem manchmal auf den ersten Blick nicht bewusst sind.

Ein weiterer Ansatz können die verwendeten Switche sein, wo einzelne Ports vielleicht nicht (mehr) in Ordnung sind oder auch ein generelles Bandbreitenproblem in einige Netzsegmenten etc.

Die Fehlersuch kann also u.U. recht komplex werden und größeren Messaufwand erforderlich machen.

Das Argument greift zu kurz. Was bedeutet denn “im selben Netzwerk”? Gleicher IP-Kreis oder auch der selbe Switch? Nicht zu vergessen, dass bei DECT die Funkkomponente hinzu kommt, die bei kabelgebundenen Endgeräten wie dem Yealink entfallen.

Schließlich kann es auch noch eine defekte Basisstation sein. Um das zu klären, müsste man auf die (hoffentlich vorhandenen) Aufzeichnungen der DECT-Ausleuchtung zurück greifen und erneut prüfen, ob die dokuentierten Feldstärken in den einzelnen Bereichen immer noch erreicht werden.

Falls beispielsweise eine Basisstation ausgefallen ist, nutzen die Mobilteile die restlichen Basisstationen, die dann möglichweise aber zu weit weg sind und somit durch zu geringen Feldstärke zu den geschilderten Problemen führt.

Wie gesagt, alles nur gedankliche Ansätze. Ohne tiefgreifendere Kenntnisse über die vorhandenen Strukturen lässt sich das aus der Distanz kaum näher klären.

Gruß
Michael

1 Like

Hallo Noses,
wir sind Endkunde eines Pascom-Partners wir haben auf unseren Wunsch hin eine vorhandene 15 Jahre alte AAstra Anlage mit den RFP-35 Basen von Mitel ausgetauscht. Eine Dokumentation dieser DECT Anlage gab es schon damals leider nicht. Ich ging eventuell zu Naiv davon aus das im DECT Standard sich nicht so viel geändert haben kann. Aber leider haben die Mitel in unserem Einsatzfeld (612d und 622d) wirklich fürchterliche Gesprächsqalität seit dem die neuen Basen im Einsatz sind.

Zum Test habe ich alle möglichen Basen kreutzweise getauscht mit einer Basis hier in meinem Büro (etwas Abseits) um eventuell eine defekte Basis zu erkennen. Leider bisher ohne Erfolg.
Ein großen Qualitätssprung hatte das aktivieren von “reflektiver Umgebung” gebracht.

Zu meinem Netzwerk

Es gibt eine Watchguard M200 in der derzeit einfache Packetfilter den VoIP Traffic auf ein SDWAN routen. Outbound habe ich einen VDSL 100 der zur Zeit dediziert für die Telefonie genutzt wird. Ich hatte alles per VLAN über den Backbone auf den Access Switch verteilt jedoch zur Zeit läuft VoIP über physikalische Ports auf einem Cisco SG350. Der Switch ist nur zu 50% belegt.
Wir hatten noch 4 WLAN APs dran die jetzt auch schon Ihren eigenen Switch bekommen haben.

Die Watchguards machen PPPoE mit Draytec Routern.

Es gibt einen 2. Standort an dem nahezu dasselbe Setup arbeitet, die Watchgauard in Site2 ist über einen VPN Tunnel mit dem 1. Standort verbunden. Im 2. Standort hängt eine weitere DECT Basis die über den Tunnel mit dem OMM im 1. Standort verbunden ist. Diese wollte ich nun als nächsten Schritt zur eigenen OMM machen um ggf. den VPN Tunnel als Problem auszuschließen.

Vielen Dank

Gruß Seb.

Dann würde ich den Partner mit ins Boot holen. Klar wird der das nicht umsonst machen. Aber Deine eigenen Unternehmungen für eine Fehlersuche kosten auch Zeit, Nerven und letztlich Geld.

Es gibt auch noch die Möglichkeit, entsprechende Netzwerkmessungen mit professionellen Tools durchzuführen, die beziehen sich aber mehr auf die Netzwerkinfraktstruktur und nicht auf den Funkanteil.

Hier in der Community weiß ich ansonsten noch, dass @MarkusSachs recht tief im Thema Mitel steckt.

Gruß
Michael

Gruß
Michael

1 Like

Hallo Seb,

kommst du denn auf das DECT-System drauf?
Also kannst Du dich dort Anmelden dann könnte man mal schauen wie den die Verbindung zwischen den einzelnen Basen ist.

Wurden dort Mitel Kabelgebundene DECT-Sender 1 zu 1 gegen RFP35 getauscht oder hatter Ihr die RFP35 schon an der Mitel Telefonanlage?

Gruß Markus

1 Like

Moin Markus,
vielen Dank das Ihr Euch die Zeit nehmt einmal mit darüber nachzudenken.
Es gab hier im Standort 1 (3 Stk AAstra SystemBasis 4+) Bild bei EBay

Diese waren an eine AAstra 2045 ich wollte die DECT Lösung weiter betreiben da sie uns in 12 Jahren keinen Ärger machte also habe ich zusammen mit einem Pascom Partner 1:1 die Basen gegen RFP 35 getauscht.

Ich kann auf das OMM (ist auf einer der Basen installiert. Und ich erhalte dort folgende Übersicht:

Der Dect Cluster 2 und die Basis im Standort 2 hat keine eigene OMM und ist über ein VPN mit dem Standort 1 und dem OMM dort verbunden. Dort sind nur 3 Dect Telefone daher habe ich die zusätliche Belastung im Tunnel für Gering gehalten.

Alle RFPs sind Anpingbar und QoS ist aktiv (DSCP Level 5)

Gruß Seb.

Hallo Sep,

also gut. Dan versuche ich das mal zu erklären.
Die Systembasen von Mitel sind ja Kabelgebunden das heißt wenn man für die eine ausmessung macht dann kann man die so auslegen das sich die Sendebereiche grade überschneiden. Das Handover von einer zu anderen Basis während des Gespräches passiert über die Telefonanlage.

Die RFP35 sind SIP-DECT Basen bei denen passiert das Handover overtheAir, was zur Folge hat das Sie Basen nicht ganz so eine hohe Reichweite haben (DECT darf inzwischen auch nicht mehr mit so hoher Leistung senden wie früher).
Das heißt das die Basen sich einfach mehr überlappen müssen. Siehe dem Screenshot (sind zwar Snom DECT-Sender aber ist ja nur fürs verstehen)

image

Mach mal folgendes wenn Du dich auf dem OMM angemeldet hast.

Lade die die Java Anwendung OMP runter siehe Screenshot und melde dich dort am DECT-System an

Dann wechselst du dort auf die Lupe und wählst die Sync Ansicht aus und positioniert dort deine DECT-Sender vom ersten Cluster

Jetzt kannst du das Feld RFP-Positionierung wieder abhacken und mit einem Rechstklick auf jeden Sender das Monitoring anschalten.

Dort sollten jetzt im Idealfall keine Werte unter -80dBm stehen auf jedenfall keine roten Linien zu sehen sein. Also auf jedenfall sollte jeder Sender mindestens eine Sender mit gutem Empfang sehen.
Wenn das gegeben ist dann kann man sagen das die DECT-Sender untereinander schon mal gut Positioniert sind.

Dann sollte man als nächste mal mit einem Handset im Messmodus durch die Bude laufen und schauen wie dort dr Empfang ist.
Ein Handset kann man folgendermaße in den Messmodus versetzen.

Gehe ins Menü und tippe dort ***67# ein dann erscheinen neue Menüpunkte.
Du wählst dann Test/Trace und dort Site-Survey, jetzt kannst du auf dem Display die Empfangsstärke zu den Sender auf denen das Telefon eingebucht ist sehen (das sind die orangen Zahlen im Display)

image

Oben steht da immer der RPN (DECT-Sender ID) unten darunter die dBm Zahl, auch dort sollte überall wo Ihr telefonieren müßt nicht weniger als -80 dBm auf mindestens einer Zelle sein.
Um den Messmodus wieder zu verlassen einfach das Telefon ausschalten und neu starten

Hier noch ein Link zum Thema ist zwar Snom aber gillt genauso für Mitel https://service.snom.com/display/wiki/DECT+-+1.+Multicell+Deployment+Guide

Meine Vermutung ist halt das du noch mehr DECT-Basen brauchst und dann wenn ich den Screenshot richtig deute (du hast 5 Basen?) auch noch eine Lizenz da die freie Lizenz nur bis 5 Basen geht.

Gruß Markus

1 Like

Hallo Markus,
nochmals vielen Dank für Deine Ausführlichen Hinweise und Tipps.
Ich habe folgende RFP Schematik (alles ebenerdig 70x50m )


Die zusätzliche Lizenz für das System wollte ich eigentlich einsparen.
in diesem Zusammenhang führe ich Zitate meiner Kollegen an:
“Früher hat es doch auch wunderbar funktioniert”
oder “Ich konnte vor der VoIP umstellung vom Nachbarn aus telefonieren”

Wenn ich an meinem 612d v2 im Menu “***67#” eingebe erhalte ich keine weiteren Einträge im Menue
mitel_1
Die Telefone haben alle das 7.0.SP10 drauf.

Die Reichweite ist eine Schwäche uns geht es vorrangig darum, dass es sporadisch zu solchen Gesprächen kommt, wirklich unschön wenn man Kunden so anzerrt.

Der Kollege ist in seinem Büro etwa 6-7m von der nächsten Basis entfernt wenn es zu solchen Gesprächen kommt.
Die Basis sowie das Telefon habe ich inzwischen getauscht. Solche Effekte treten meistens Outbound auf also “Mitel -> Anrufer”
In dem aufgezeichneten Fall habe ich die entsprechende Basis über PoE neu gestartet wonach alles wieder in Ordnung schien.

Sonnigen Gruß Seb. :sunny:

Hallo Seb,

ja du hast recht es sollte auch ***76# sein kleiner Schreibfehler

1 Like

Ah vielen Dank,
jetzt erhalte ich wenn ich mir dieses Menue aufrufe bis zu 6 RFPs angezeigt. Das verstehe ich so, dass unsere Nachbarschaft ebenfalls DECT einsetzt und diese werden hier auch mit gelistet habe ich das richtig verstanden?


oder sind dies Pings?

Ein weitere Frage ist am Telefon wird während eines Gesprächs Codec G.726 angezeigt aber die Basis soll G.722 verwenden. Ich gehe davon aus, das die Basis das Gespräch recodiert.

Einige meiner Telefone weisen eine ältere Firmware (7.0 SP5) auf diese würde ich gerne aktualisieren, kann ich das Update der Mobilteile erzwingen?

Sorry für die vielen Fragen und nochmals Danke für die aufschlussreichen Auskünfte.

Gruß Seb.

Hallo Seb,

also die Aussage mit früher hat das auch funktioniert habe ich ja oben schon erklärt.
Die IP-DECT Sender dürfen nicht mehr mit der Leitung strahlen wie das früher erlaubt waren.

Wegen dem Update der Telefone 612d lassen sich meines Wissens nur über die Basis Updaten ab den 622d kann man das per USB machen.

Was ist denn unter SIP als Codec Eingestellt?

Was kannst du denn jetzt sehen wenn du die Site-Survey anmachst? die andere Anzeige kenne ich nicht.

Du sagts das ein Neustart der Zellen das Problem mit der Sprache behebt? Welche Switche setzt ihr denn ein? Wie sind dies Konfiguriert?

Gruß Markus

Hallo Markus,
wir setzen dedizierte Cisco SG300 Switche im L2 Modus einigen VLAN Einstellungen und die Energiesparmodi sind aus.
Ich habe auf diesen Switchen an diesem WE die aktuelle Firmware installiert.
QoS ist nicht noch zusätzlich aktiv.

Die SIP RTP Parameter sind so eingestellt wie in Deinem Bild.

Das Telefon zeigt dieses Bild im Site Survey Modus -

Gruß Seb.

Hallo Seb,

Jetzt kannst du Mal rumlaufen dorthin wo du Telefonierst und Mal schauen wie der Empfang ist. Auf dem Bild siehst du ja das das Telefon zwei Sender sieht aber nur mit einem Verbunden ist.

Wegen den Switchen ihr habt dementsprechend eigene Switchen für das Telefonienetz?

Gruß Markus

1 Like

Moin Markus,
ja dediziertes Telefon VLAN auf dem Switch -
daran hängen sonst noch 2 WLAN APs diese habe ich zur Zeit dieser Tests an einen anderen PoE Switch gehangen. Zur Zeit betreiben wir 22 T46 und 4 Mitel Basen an einem Cisco SG300

Gruß Seb.

Moin,
nach einigen Tests in zusammenarbeit mit dem Pascom Support.
Hat sich herauskristallisiert, dass vermutlich eines unserer RFP35 ein technisches Problem hat.
Dieses RFP wird nun getauscht.

Danke für Eure Hilfe.