Hallo zusammen,
wir haben hier unter anderem Mitel RFP 44 (1x controller, 1x “repeater”) an Pascom angebunden und das Problem, dass die Sprachqualität zeitweise schlecht ist. Die Sprachverbindung ist einseitig abgehackt.
Das kommt jedoch nicht immer vor. Ich konnte bisher auch noch nicht eingrenzen, ob es damit zusammenhängt, über welche der beiden Basen die Verbindung abgewickelt wird.
Hat dazu jemand eine Idee?
Hört sich für mich nach Netzwerkproblemen an.
Hast denn die 2 Basen schonmal neu gestartet?
Was heißt Repeater?
Was zeigt den das Log der Basisstation an?
Gruß Markus
Das Netzwerk habe ich auch im Verdacht, tu mich jedoch damit schwer, das einzugrenzen. Neu gestartet hatte ich die Basen schon.
Mit “repeater” meine ich nicht-manager-Basen. 
Sorry. Du hast recht. Ein DECT-Repeater ist ja etwas anderes.
Im Log finde ich unterschiedliche Meldungen. Einmal packet loss:
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: ...)
Und andererseits setup rejected. Die Darstellung hier ist nicht vollständig.
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
Das könnte ggf. mit dem Problem zusammenhängen, dass gleichzeitige Rufe auf mehrere handsets nach dem ersten Klingeln abbrechen.
Ich habe die DECT-Basen nun auf ein eigenes Netz gehängt. Also eigene Switches und einen eigenen Uplink über den VDSL-Anschluss, den es noch gibt.Bisher fehlen mir urlaubsbedingt noch Rückmeldungen. Aber ich halte euch auf dem Laufenden.
Wir haben das gleiche Problem, allerdings wird die Firmware 8.3SP5-IC31 verwendet.
Hatte das Tauschen des Switch bzw. das eigene Netz bei dir was gebracht?
Sorry für die späte Rückmeldung. Es hat nichts gebracht.
Es hat sich herausgestellt, dass diese Störungen überwiegend bei internen Gesprächen auftreten. Da hätte mich interessiert, ob bei diesen Gesprächen auch der Transportstream über Pascom läuft oder im lokalen Netz bleibt. Das habe ich noch nicht getraced, aber das weiß auch sicher jemand spontan.
Was ich jetzt noch gemacht habe:
Ich habe ein DECT handset gegen ein fabrikneues Modell getauscht (HW und SW identisch) UND die Basen wieder in die reguläre Infrastruktur reintegriert, wobei DECT in einem eigenem VLAN läuft. Die Tischtelefone liegen noch in einem anderen VLAN. Das muss ich mal nachziehen.
Jedenfalls scheint es nach dem Wechsel des handsets besser zu funktionieren. NIcht, dass es an einem schrottigen handset gelegen hat… 
Hi @Mett ,
wir lassen hier keinen re-invite zwischen den Geräten zu, d.h. beide Streams laufen über die pascom. Für Mitel kann ich das nicht aus dem FF beantworten, aber ein weiterer Unterschied könnte hier der ausgehandelte Codec (opus u.U.) sein. Hier kann man aber zur Not auch mal alaw erzwingen und testen, ob dies für Besserung sorgt.
Grüße,
Steve
Danke für die Rückmeldung @Steve,
alaw war zumindest bereits auf Prio 1. Die anderen Codecs habe ich im OMM entfernt.
Zwischenstand: Das Problem besteht bei uns weiterhin und ich bin weiterhin komplett ratlos. Ich weiß auch nicht, was ich am Netzwerk noch debuggen könnte. Gerade der temporäre Umzug auf eine eigene, frisch aufgesetzte physische Infrastruktur hätte doch zumindest eine Änderung bringen müssen.
Ich habe einen OMM DECTNetMonitor im Netz laufen, tu mich mit der Interpretation der Daten jedoch schwer. Ich finde in der Statistik der entsprechenden DECT-Basis jedoch einen recht hohen counter für “loss of connection”. Die counter hab ich nun mal zurückgesetzt und ein Gespräch geführt, dass qualitativ ok war. Danach sah die Statistik so aus:
Hallo zusammen,
hier nochmal ein Zwischenstand:
Ich hatte die Telefonie (DECT-Basen sowie IP-Telefone) ja auch mal testweise auf ein eigenes Layer 1-Netz geschaltet, also eigener Switch, eigener Router, eigener Uplink (Telekom VDSL) und hierüber die selben Probleme gehabt.
Als Router kommt ein Lancom-Router (ohne IP-Teil) zum Einsatz. Der Testrouter war ein Lancom-Router mit IP-Teil, ich denke ein 884.
In meiner Verzweiflung habe ich der Telefonie nochmal einen eigenen Router über den VDSL-Anschluss verpasst. Diesmal jedoch eine Fritzbox 7490 verwendet. Diese habe ich default gesetzt, das Subnetz angepasst und die Telekom-Zugangsdaten eingetragen.
Über diese Fritzbox laufen nun die DECT-Basen sowie die IP-Telefone. Was soll ich sagen: Seither hat sich die Qualität erheblich verbessert. Über DECT keine Probleme mehr, die IP-Telefone haben auch keine Probleme.
Der Pascom-Client läuft über das produktive Netz und hat weiterhin Probleme. Laut Pascom-Support Jitter und Paketverlust.
Ist das wohl ein Lancom-Problem?
Hast du evtl. Router-Kaskaden im Produktivnetz. So oder so würde ich die MTU Size prüfen
Keine Kaskade, nein. MTU schau ich mir an!
wir versuchen, sofern eine Fritz!Box vor Ort ist, immer alle VoIP Geräte direkt an die Fritz Box zu stecken oder dann halt mitteles Switch anbinden…somit bin ich immer vorm IT LAN und erspar mir diese Fehlerquellen schon mal
Das ist nachvollziehbar, aber mich persönlich befriedigt mein provisorischer Lösungsansatz im Moment nicht, da ja auch noch die Pascom Clients auf den Rechnern eine stabile Verbindung benötigten.
Nachtrag der Vollständigkeit halber: Das Produktivnetz hängt an einer symmetrischen Gf (100 Mbit). Der VDSL-Anschluss (DTAG, 50/20-Profil) ist historisch bedingt noch da und durch unterschiedliche Leitungsführung und unterschiedliche Leitungsbetreiber ein bisschen mehr als nice to have. 
Wir haben bei allen (pascom) Kunden keine FritzBox und trotzdem bei keinem Kunden Probleme mit der Telefonie (egal ob Telefone / Dect / Client).
Ich vermute Firewall / Routing oder ähnliches? Evtl QoS?
