Hallo steht in der Doku genau beschrieben.
Gruß Markus
Hallo zusammen,
@hazington: Wir haben das überlegt und uns aber explizit dagegen entschieden weil: Wenn man das implementiert, dann sollte der Client selbst die Einstellungen prüfen und ggf. selbst setzen. Hier steht aber Implementierungsaufwand und Nutzen in keinerlei Verhältnis, da es ja mit dem setzen der QoS Parameter in Windows nicht getan ist. Der Rest der Netzwerkinfrastruktur muss die Flags ja auch entsprechend richtig verarbeiten. Daher ist es am einfachsten, die entsprechenden Parameter zu dokumentieren. Der Admin kann dann, wie @MarkusSachs bereits sagte, die Einstellungen einfach über Gruppenrichtlinien ausrollen.
Grüße,
Jan
Hallo,
wir haben bei einem Kunden ein kleines Problem im Client gefunden (in der Beta und der Stable). Wenn man mit einem internen Mitarbeiter telefoniert und gleichzeitig eine externe Nummer aus seinem Journal in sein privates Telefonbuch im Client speichert, wird der Mitarbeiter auf der linken Seite im Client umgenannt. Der Fehler bleibt bestehen bis man den Telefonbucheintrag wieder löscht und den Client neu startet.
Gruß Jonas Plaum
Hallo @JonasPlaum,
ja, das ist reproduzierbar. Wenn man auf den kleinen runden “Aktualisieren” Pfeil oberhalb der Kontaktliste klickt, wird ebenfalls wieder der korrekte Name angezeigt. Wir werden das reparieren.
Grüße,
Jan
Tatsächlich bin ich was Windows GPO und Domänen betrifft nicht besonders fit. Ich kenne das Tool LGPO, verwende es mangels Wissen aber noch nicht. Wir arbeiten absolut plattformunabhängig. Azure wird nur für die Verwaltung der Benutzerkonten ohne Adminrechte, Office-Lizenzen und Geräte verwendet. Da neben Office und Pascom nur ein PDF-Editor als fest installierte Software benötigt wird, hält sich der Konfigurationsaufwand in Grenzen und ein zentrales Ausrollen von Software und Richtlinien wäre zu viel des Guten, einfach weil bei Windows so viel drumherum gehört, dass Aufwand den Nutzen übersteigen würde. Ich werde mir das Thema aber nochmal anschauen.
Der Rest der Infrastruktur ist tatsächlich bereits auf Priorisierung von VoIP per QoS konfiguriert. Fände ein zusätzliches Programm zum Installieren der Pascom QoS GPO halt ganz nett. Ich meine unabhängig vom Pascom Client. Würde Export und Import per Powershell vermeiden. Wobei es meine ich nicht schaden kann, wenn die Richtlinien dennoch gleich mitinstalliert werden, so könnte man das eigene Netzwerk entsprechend konfigurieren und weiß, Pascom hat sich um den Windows-Teil bereits gekümmert. Ich bin übrigens nur zufällig auf dieses Thema gestoßen und wusste bis vor kurzem gar nicht, dass auch Einstellungen in Windows getätigt werden müssen.
Das wird aber ein wenig zu Off-Topic.
Ein andere Ansatz wäre das per GPO auf einem Rechner einzustellen und dann den passenden Registry Hive zu exportieren. Den kann man dann auf jedem anderen Rechner wieder importieren und hat das wieder eingestellt.
Siehe hier https://blogs.perficient.com/2014/12/31/configuring-quality-of-service-for-lync-online/
Gruß Markus
pascom Client 67.D1402
German
- Erstellen eines Telefonbucheintrags aus dem Journal überschreibt nun nicht mehr den Namen des aktiven Gesprächs
- Es wird nun eine “RDP Modus ist aktiv”-Meldung angezeigt
- iOS/Android: Probleme mit Anrufsteuerung im Zusammenspiel mit Freisprecheinrichtungen behoben
English
- Creating a phonebook entry from the journal doesn’t override the name of a running call anymore
- A nicer message is shown if RDP mode is active
- iOS/Android: Fixed various problems with call control on handsfree modules
Fantastsich! Der Ansatz ist perfekt für meinen Anwendungsfall. Vielen Dank. 
Es wäre sehr praktisch, wenn der “Schalter” nicht per Kommandozeile oder Umgebungsvariable gesetzt werden müsste, sondern per Schiebe-Schalter in den Client Optionan an und abschaltbar wäre. Es gibt nicht bei jedem Kunden Zugriff auf das System in der Form, dass hier diese beiden Möglichkeiten ohne weiteres gesetzt werden können.
Die Einstellung darf gerne auch in den erweiterten Einstellungen untergebracht werden.
1 Like
Ich habe jetzt unseren RDS mit der Umgebungsvariable eingerichtet. Der Client nimmt das Flag auch und zeigt an … RDP mode. Lokal läuft auch der Client, welche logischerweise vor dem Client im RDS gestartet wurden
Als Gerät ist Softhone am RDS Client gewählt
Allerdings kann ich über den RDS Client kein Gespräch aufbauen, da er oben die Meldung zeigt, dass der Mikrofon zugriff blockiert ist, was im RDS ja “normal” ist, da kein Mikrophon durchgereicht wird im Standard.
Die Meldung mit dem Mikrofon ist aber an sich sehr schön, da bei Win10 Clients ja immer mal wieder das deaktivierte Mikrofon für Probleme sorgt allerdings im RDS Mode scheint diese hinderlich zu sein für den Rufaufbau.
Kann das geändert werden?
Hallo @M.Wimmer,
danke für das Feedback. Für die Idee mit dem Schalter in den erweiterten Einstellungen habe ich ein Ticket aufgenommen, wir denken darüber mal nach.
Zum Thema Mikrofon: Ich habe das gerade nochmal getestet und konnte zwei Dinge rausfinden:
- Ein Forwarding der Audiogeräte in die RDP-Sitzung ist nicht erforderlich
- In den Datenschutzeinstellungen muss der Zugriff auf das Mikrofon (obwohl im System gar keins vorhanden ist…) erlaubt sein, damit das Wählen funktioniert - das werden wir noch ändern. Als Workaround derweil einfach den Zugriff erlauben, dann klappts.
Grüße,
Jan
1 Like
pascom Client 67.D1406
German
- Windows Mikrofon-Privatsphäreneinstellung wird im RDP Modus nicht mehr geprüft
- Übersetzungen vervollständigt
English
- Do not check microphone privacy settings are not checked anymore in RDP Mode
- Translations are finished
@M.Wimmer: Das wählen aus dem RDP-Modus bei deaktiviertem Mikrofonzugriff in den Windows-Datenschutzeinstellungen sollte jetzt problemfrei klappen. Magst mal testen?
besser als der Schalter wäre noch eine automatische Erkennung, dass der Client auf einem RDS läuft 
sollte ja vermutlich möglich sein auf eine Installation der RDS zu prüfen. Hilft natürlich nicht bei Win10 Clients…
mit der D1406 und deaktiviertem Mikrofon schauts jetzt richtig gut aus! Danke für die schnelle Umsetzung!
Die Telefon-Funktion grundsätzlich, nur aufgrund der Tatsache, dass man sich auf einem RDS befindet, zu sperren halte ich persönlich für problematisch.
Die Optionen per Umgebungsvariable/Startparameter (und eventuellem Schiebeschalter) halte ich für vollkommen ausreichend.
1 Like
Ich versuche gerade meine ersten Test mit den Softphone unter Linux zu machen. Dazu habe ich ein Jabra Evolve 75 per Bluetooth gekoppelt. Linuxseitig funktioniert das komplett (Kopfhörer und Mikrophon). Der Linux Client erkennt es und der Kopfhörer funktioniert auch. Dort kann ich auch Bluetooth auswählen (zwar PulseAudio aber eben “bluez_sink”):
Beim Mikrofon kann ich nur “Pulse” auswählen. Allerdings funktioniert es nicht:
Vielen Dank für den Link zur GPO.
Dachte das ich schon viel unterwegs war in den Handbüchern und hab
auch schon div. Sachen ausprobiert und auch schon öfters QOS Beiträge im Forum gelesen, aber den Eintrag im Handbuch hab ich noch nie gesehen.
Vielleicht hilft uns das wieder ein Stück weiter.
Gruß
Sebastian
Hallo zusammen,
seit dem letzten Update am Freitag friert der Softclient (Windows) ein sobald ein Anruf gestartet werden soll. Nach etwa 30 Sekunden ist der Client wieder bedienbar, der Ruf wurde aber nicht gewählt bzw. angenommen.
Folgendes zeigt sich im Log (mit SIP Debug):
[2020-11-23 12:03:26.653] [T6056] [Debug] [service.ConnectionService] will block ui for request with id: "qxmpp31"
[2020-11-23 12:03:26.762] [T6056] [Debug] [service.MdSoftphone] Add outbound call id -1, now 1 calls
[2020-11-23 12:03:26.762] [T6056] [Debug] [service.MdSoftphone] Thread id mdsoftphone: threadID= QThread(0x1da2a18)
[2020-11-23 12:03:56.959] [T6056] [Warning] [proto.sip] 12:03:56.959 pjsua_aud.c ..Unable to open sound device: Undefined external error. [status=452000]
[2020-11-23 12:03:56.959] [T6056] [Warning] [proto.sip] 12:03:56.959 call.cpp pjsua_call_make_call(acc.getId(), &pj_dst_uri, param.p_opt, this, param.p_msg_data, &id) error: Undefined external error. (status=452000) [c:\users\administrator\jenkins\workspace\client\client\deps-win-release\src\pjproject\pjsip\src\pjsua2\call.cpp:658]
[2020-11-23 12:03:56.959] [T6056] [Critical] [service.MdSoftphone] Exception on dial: "Undefined external error."
[2020-11-23 12:03:56.959] [T6056] [Debug] [util.MdCall] Destruct Call
Habe auch schon den Jabra-Support deaktiviert, die Meldung bleibt aber gleich.
Wenn nach einem Fehlversuch (Client friert ein) der Klingelton abgespielt werden soll [Headset und Audio] friert der Client ebenfalls ein und der Klingelton wird nicht abgespielt.
Edit: Mit dem letzten Release v66 tritt das Problem auch auf, scheint also eher nicht am Client zu liegen. Werde einen neuen Thread starten.
Gruß,
Rapha
Hallo @rapha,
Aus irgendeinem Grund schlägt der Zugriff auf die Audio-Hardware nach einem Delay von 30 Sekunden fehl. Sicher dass nichts anderes an dem System aktualisiert bzw. verändert wurde? Ist es nach einem Windows-Neustart reproduzierbar? Bleibt das Verhalten gleich wenn ein anderer Lautsprecher und/oder anderes Mikrofon ausgewählt wird?
Grüße,
Jan
Es wurde nichts am Windows-Client verändert, auch mit “wave mapper” friert der pascom-Client ein.
Nach einem Neustart vom Windows (und pascom-Client) lässt sich der Klingelton auch abspielen. Sobald aber eine Rufnummer gewählt werden soll bricht der Client ab.
Im xmpp-Log ist nichts außer dem Dial-Request zu finden.
Hint: Habe am Wochenende eine 3. Schnittstelle zur pascom hinzugefügt (Zugriff Türsprechanlage, nicht TLS-fähig).
Unsere “normalen” Telefone funktionieren, sowie der Android-Client (selber User-Account).
Edit: Ein anderes Headset funktioniert(e) einmal, danach ist der Thin-Client mit einem Core-Dump abgestürzt…
Thin-Client getauscht und siehe da, das alte Headset funktioniert nun auch wieder
Gruß,
Rapha
Das Problem mit dem Jabra Evolve 75 ist gelöst. Der kann zwar Bluetooth aber irgend wie nicht so richtig. Verbinde ich das Headset über einen “generischen” Bluetoothanschluss geht es nur halb, wie beschrieben. Nehme ich den mitgelieferten USB-Bluetooth-Dongel geht es. Damit wird das Headset dann auch vom System anders erkannt. Drauf gekommen bin ich, dass das Mikrofon auch in Jitsi nicht funktioniert hat und es im Jitsi-Forum einen entsprechenden Eintrag gab. Interessanter Weis funktionier bei der “falschen” Anschlussart das Mikrofon mit anderen Programmen, wie z.B. Audacity … warum auch immer …
Jetzt sieht das im übrigen so aus:
