[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.

 

[mettwurscht]

So, den DECT Monitor habe ich laufen, tu mich jedoch mit der Interpretation der Daten schwer. Ich muss mich aber auch noch durch die Doku kämpfen.

Ich hatte den RFP statistic counter vorhin zurückgesetzt und ein Gespräch geführt, dass in Ordnung war. Danach sahen die Werte so aus:



Bevor ich die counter zurückgesetzt habe, lag der Wert bei "loss of connection" bei Mitte 30. Die Werte unter "Sync problems" standen jedoch auf 0.

 

[chrsto]

Ich muss zu meiner Schande gestehen, dass ich diese Software nicht kenne. Ich hätte jetzt auch mit einem Screenshot aus dem Monitorring des OMP gerechnet.

 

[Rangierdraht]

Interessant wären die Sync Werte zwischen den Sendern, die sollten maximal 70 db betragen.
Besser wären 60

 

[mettwurscht]

Hallo zusammen,

nach einem weiteren Test hier nochmal eine Rückmeldung:

Wir verwenden als Router einen Lancom 1781EF+, also ohne SIP-Gedöns (Edit: SIP-ALG deaktiviert). Der Test mit eigenem Layer 1-Netz und eigenem VDSL-Uplink wurde mit einem Lancom 884 durchgeführt, also ein Router mit SIP-Gedöns (Edit: SIP-ALG ebenfalls deaktiviert).

Der weitere Test wurde mit einer Fritzbox 7490 über den VDSL-Uplink durchgeführt. Diese wurde zurückgesetzt, die WAN-Zugangsdaten eingetragen, das Subnetz angepasst und fertig. Über diese Fritzbox gehen die DECT-Basen sowie die IP-Telefone online und so treten keinerlei Probleme mehr auf.

Ich gehe jetzt daher davon aus, dass das Problem mit den Lancom-Routern zusammenhängt.

Als CloudPBX wird Pascom eingesetzt. Deren Client läuft auf ein paar Rechnern. Diese Rechnern gehen weiterhin über das Produktivnetz ins Internet, entsprechend treten an den Pascom-Clients auch weiterhin Paketverlust und Jitter auf.

Ich glaub, ich geh mal ins Lancom-Unterforum.

(Habe hier das Thema weitergeführt: https://www.ip-phone-forum.de/threads/sip-problemem-an-lancom-routern.320435/)