[Problem] Mitel RFP44 mit Signalisierungs- und Sprachproblemen

[mettwurscht]

Hallo zusammen,

ich habe hier 1x RFP44 mit SIP-DECT 9.0 als Manager und 2x RFP44 als Basisstationen. Nun ist es so, dass die Sprachqualität über die handsets zeitweise sehr schlecht ist. Die Verbindung ist stark abgehackt und klingt, als wäre die Feldstärke sehr schlecht. Die Basisstationen sollten sich jedoch von ihrerm Versorgungsbereich stark überlappen. Die Tischtelefone (Yealink) haben dieses Problem nicht.

Es sind insgesamt 17 handsets, wobei die Auslastung mit gleichzeitigen Verbindungen nicht sehr hoch ist. Lediglich viele gleichzeitige Signalisierungen kommen bei Anrufen auf einer bestimmten Durchwahl vor.

Außerdem kommt es bei Gruppenrufen vor, dass einzelne handsets nur kurz klingeln und dann bereits verstummen, obwohl der Ruf noch anliegt.

Sind die Basen möglicherweise falsch konfiguriert? Was sollte ich mir anschauen? Welche Infos benötigt ihr noch?

Nachtrag
Die Handsets setzen sich aus folgenden Geräten und Softwareständen zusammen:
612d: 7.3.3
612v2: 7.6.4
610d: 5.0.0.SP5

 

[chrsto]

Ist Wideband HQ aktiv?
Abgehackt könnte auch Packetloss der RFP sein. Das würde man im Syslog sehen (nach "packet loss" suchen)

 

[mettwurscht]

Wideband Audio war aktiviert. Das habe ich nun deaktiviert.

Im syslog finde ich tatsächlich packet loss-Meldungen:

3    1    2024/06/24 09:43:03.884    MSM : 1% (13/844) packet loss / 75ms jitter detected from 52.57.20.216 to 192.168.x.x (number: ...)
3    1    2024/06/20 12:20:56.553    MSM : 1% (2/133) packet loss / 0ms jitter detected from 52.57.20.216 to 192.168.x.x (number: ...)
3    1    2024/06/20 09:55:03.664    MSM : 2% (10/371) packet loss / 1ms jitter detected from 52.57.20.216 to 192.168.x.x (number: ...)
3    1    2024/06/20 08:18:19.244    MSM : 10% (233/2296) packet loss / 0ms jitter detected from 52.57.20.216 to 192.168.x.x (number: ...)
3    1    2024/06/20 06:02:10.469    MSM : 1% (13/1097) packet loss / 0ms jitter detected from 52.57.20.216 to 192.168.x.x (number: ...)

Ich werde versuchen herauszufinden, ob die abgehackte Übertragung mit einer der Meldungen zusammhängt.

Mit dem Signalisierungsproblem könnte das zusammenhängen? Könnte es sein, dass in dem Fall zu viele handsets auf einer Basis eingebucht sind und daher die gleichzeitige Signalisierung fehlschlägt?

3    1    2024/06/24 09:27:32.134    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 09:27:32.034    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 09:27:31.777    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 09:27:31.733    MSM : RFP(0000) setup rejected for number: $sipuser
3    1    2024/06/24 09:27:31.493    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 08:37:29.663    MSM : RFP(0000) setup rejected for number: $sipuser
3    1    2024/06/24 08:37:29.601    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 08:37:29.501    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 08:37:29.341    MSM : RFP(0001) setup rejected for number: $sipuser
3    1    2024/06/24 08:37:29.179    MSM : RFP(0001) setup rejected for number: $sipuser

 

[chrsto]

Die RFP 44 haben insgesamt 8 Kanäle. Davon 4 für Signalisierung und 4 für Signalisierung/Gespräche.

Wenn die Mobilteile keine Möglichkeit haben, auf einen anderen RFP auszuweichen, hast du ein Problem, da auch die 48er nur max. 12 Kanäle zum signalisieren haben.
Wenn die Handgeräte zu oft an einer Stelle liegen, wirst du da wohl noch einen RFP hinhängen müssen.

Mit deinem zweiten Zitat kann ich nichts anfangen.

Wie ist denn dein Netzwerk (Hardware) insgesamt aufgebaut/strukturiert?

 

[mettwurscht]

Der Hinweis auf die Signalisierungskanäle ist vermutlich hilfreich. Es ist denkbar, dass sich die meisten handsets auf den Bereich einer RFP konzentrieren und daher in diese eingebucht sind. Ich werde eine der anderen in diesen Bereich verlegen und testen, ob das etwas bringt.

Bei einem Ruf auf eine bestimmte Durchwahl klingeln 10 handsets. Wenn die alle auf einer Basis hängen, wird es natürlich eng.

Die VoIP-Geräte sind in einem eigenen Netzsegment untergebracht und haben im Uplink eine gewisse Geschwindigkeit fest reserviert.

 

[chrsto]

Ich meinte eher, ob die RFP alle auf einem Switch enden (inkl. ggf. PBX, aber ihr nutzt wohl eine Cloud Lösung?), der direkt zum Router geht und nicht noch eine Unterverteilung mit weiteren Switchen existiert?

Das oben ist natürlich nur eine Momentaufnahme, aber 10% Packetloss? Eieiei. Es wäre natürlich auch zu klären ob der Uplink bis in die Cloud inkl. Peerings eures Providers ausreicht. Da könnt ihr dann allerdings wohl kaum gegensteuern.

 

[mettwurscht]

Die hängen alle an einem Switch, der über einen "Coreswitch" an den Router geht. Der Uplink ist ein symmetrischer Glasfaseruplink mit 100 Mbit/s. Als PBX nutzen wird Pascom (in der "Cloud"), die wir via DECIX auf recht direktem Weg erreichen.

Es ist sicher denkbar, dass es da mal knirscht, aber so recht vorstellen kann ich es mir im Moment nicht.

 

[chrsto]

War nur eine Idee. Es wird ja nur die gesamte Strecke betrachtet.
Die Empfangssituation musst du auch berücksichtigen, allerdings selbst bewerten. Das hast du im Eingangspost ja auch schon.
Du könntest ggf. noch mit der Einstellung für reflektierende Umgebungen "spielen".

Hier enden dann meine Ideen.

 

[mettwurscht]

Es scheint sich herauszukristallisieren, dass die abgehackten Sprachfetzen nur zustande kommen, wenn über eine bestimmte Basis telefoniert wird. Das Installationskabel von der Dose bis zum Patchfeld scheint auch einen Macken zu haben. Daher habe ich die Dose auch noch gewechselt. Jedoch ohne Erfolg. Ich sehe weder im Switch Rx/Tx-Error, noch im Log des Managers Paketverlust.

Die betreffenden handsets befinden sich sozusagen direkt neben der Basis (ca. 3 Meter).

 

[chrsto]

RFP mal untereinander tauschen
reflektierende Umgebung im RFP aktivieren

 

[mettwurscht]

Ich hab die DECT-Basen nun mal in ein eigenes Netz mit eigenen Switches, eigenem Router und eigenem Uplink verlegt und warte noch auf Rückmeldung, ob es sich damit verbessert hat. Vermutlich liegt die Ursache in einer verkorksten Switch- und/oder Routerkonfiguration.

 

[mettwurscht]

Es hat sich mit dem eigenen Netz und Uplink nicht verbessert. Den Standort einer Basis hatte ich außerdem auch noch verändert, jedoch ohne Besserung.

Bin ziemlich ratlos, was ich noch versuchen könnte. Ich vermute das Problem eher auf der Luftschnittstelle, da wir mit den Yealink-Telefonen und den Windows-Clients keinerlei Probleme haben.

 

[chrsto]

Hast du nicht betroffene Basen mal mit einer betroffenen Basis ausgetauscht?

 

[mettwurscht]

Eben nicht. Das will bzw. muss ich jetzt noch machen.

 

[Rangierdraht]

Hast du einen Dectnet IP Monitor?
Da würdest du die Sync Werte der Sender sehen, evtl sind die schlecht und du hast Handover Probleme

 

[mettwurscht]

Leider nicht.