Hallo Arne, die STARFACE TAPI basiert technologisch auf dem UCC Client und ist nicht solitär verwendbar.
Gruß Wolfgang
Hallo Arne, die STARFACE TAPI basiert technologisch auf dem UCC Client und ist nicht solitär verwendbar.
Gruß Wolfgang
In einer Terminalserver-Umgebung (RDP auf Terminalserver) verwendet der Client die Headset-APIs nicht. Der Usecase ist nicht unterstützt.
Gruß Wolfgang
Okay, uninstgs.exe wird dann aufgerufen, wenn im Rahmen des Setups eine neuere Ghostscript Variante installiert wird. Dann wird ggf. die ältere GS-Variante über dessen originalen Installer aus dem Programmverzeichnis deinstalliert. Wenn Du dies umgehen willst, kannst du die De-Installation optional ausschalten oder vorher selbst ausführen.
Gruß Wolfgang
Wir laden eDocPrintPro von unserem eigenen CDN herunter. Das eDocPrintPro Setup lädt aber seinerseits ggf. von besagtem ftp-Server die Ghostscript Installation herunter. Aus eDocPrintPro-Sicht ist dies kein fremder Server. Ich werde hierzu aber mit dem Hersteller Kontakt aufnehmen.
Gruß Wolfgang
Hierfür
- muss in der Telefonkonfiguration für das Windows Softphone SIP/xxxxs.WinClient der .h264 Codec eingetragen sein. Es gab Situationen, bei denen das nicht der Fall ist. Ggf. an das Ende des Codec Strings anfügen
- es muss sich um ein Softphone Telefonat handeln
Gruß Wolfgang
Der Hotkey wird im Client empfangen und die Rufnummer wird auch in Richtung Server gewählt. Auf dem Server wird der Call nicht ausgeführt.
Primary phone des User:
UpdatePrimaryPhonePopUpMenu | Primary phone: SIP/YL.017
Call Handling log:
[2022-11-09 07:45:13,163] [INFO ] [AMI OriginateResponseEvent] [OriginateResponseEventListener] Originate Failure SIP/YL.017 null
Der Call wird im Client ausgeführt.
z.B. dieser hier:
22-11-09 07:44:38.303 | 6 | INFO | | UccAPI.UccPhoneClien | DoPlaceCallEx |
22-11-09 07:44:38.303 | 6 | INFO | | UccAPI.UccPhoneClien | DoPlaceCallEx | HoldOrDisconnectPrimaryCall result: True
22-11-09 07:44:38.303 | 6 | INFO | | UccAPI.UccPhoneClien | DoPlaceCallEx | PlaceCallWithPhone(00xxxxxx converted to -> +49xxxxxx using phone Default)
22-11-09 07:44:38.303 | 6 | TRACE | | UccAPI.UccPhoneClien | DoPlaceCallEx | Requested call id: , result: 1e607c6c-9141-4c55-94ec-ae4cc487da49
Support log:
[2022-11-09 07:37:20,690] [ ---- ] Originate peer with desired UciCallUuid a2990f87-3a98-4d54-8455-78244e6a5fee
[2022-11-09 07:37:32,089] [ ---- ] Originate peer with desired UciCallUuid 65e634db-e2b7-410d-81dd-c3e546b55463
[2022-11-09 07:38:01,527] [ ---- ] Originate peer with desired UciCallUuid 243eb87b-efda-432d-b32c-ff34f529d9ec
[2022-11-09 07:44:38,307] [ ---- ] Originate peer with desired UciCallUuid 1e607c6c-9141-4c55-94ec-ae4cc487da49
[2022-11-09 07:45:13,161] [ ---- ] Originate peer with desired UciCallUuid 1bfd3c58-7e54-4e27-adf2-e9b4e915475c
Call Manager log:
[2022-11-09 07:37:20,688] [INFO ] [] [] placeCallWithPhone acc:3958 callId: a2990f87-3a98-4d54-8455-78244e6a5fee destinationNumber: +49xxxxx
[2022-11-09 07:37:32,088] [INFO ] [] [] placeCallWithPhone acc:3958 callId: 65e634db-e2b7-410d-81dd-c3e546b55463 destinationNumber: +49xxxxx
[2022-11-09 07:38:01,527] [INFO ] [] [] placeCallWithPhone acc:3958 callId: 243eb87b-efda-432d-b32c-ff34f529d9ec destinationNumber: +49xxxxxx
[2022-11-09 07:44:38,306] [INFO ] [] [] placeCallWithPhone acc:3958 callId: 1e607c6c-9141-4c55-94ec-ae4cc487da49 destinationNumber: +49xxxxxxx
[2022-11-09 07:45:13,161] [INFO ] [] [] placeCallWithPhone acc:3958 callId: 1bfd3c58-7e54-4e27-adf2-e9b4e915475c destinationNumber: +49xxxxxx
Full log:
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx.c: Executing [failed@dialstart:1] NoOp("OutgoingSpoolFailed", "HC 0") in new stack
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx.c: Executing [failed@dialstart:2] Goto("OutgoingSpoolFailed", "_exit_,0") in new stack
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx_builtins.c: Goto (dialstart,_exit_,0)
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx.c: Auto fallthrough, channel 'OutgoingSpoolFailed' status is 'UNKNOWN'
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx.c: Executing [h@dialstart:1] NoOp("OutgoingSpoolFailed", "HC 0") in new stack
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx.c: Executing [h@dialstart:2] Goto("OutgoingSpoolFailed", "_exit_,0") in new stack
[2022-11-09 07:45:13,162] VERBOSE[3615444][C-000096a7] pbx_builtins.c: Goto (dialstart,_exit_,0)
These: das Telefon ist nicht erreichbar / führt den Call nicht aus.
Versuch mal, das Telefon neu anzulegen.
Gruß Wolfgang
Hallo Olli, dann prüfe bitte mal das primäre Telefon. Ist das primäre Telefon angemeldet?
Gruß Wolfgang
Im Kontext Terminal-Server ist die Frage, auf welchem System der Hotkey landet - im lokalen Windows oder im RDP Fenster. Schau mal in den Einstellungen der RDP-Sitzung (bei dem betroffenen Benutzer). Unter "Local Resources", Kategorie "Keyboard" habe ich die Einstellung "Apply Windows key combinations" mit den Optionen "Only when using the full screen", "On this computer" und "On the remote computer".
"On this computer" wäre falsch, ggf. müsste die Option für full screen oder remote computer eingestellt werden.
Gruß Wolfgang
In STARFACE für Windows ist es mit 7.1 integriert, mit 7.2 wurde die Integration auf die Verwendung des Yealink SDK umgestellt.
Zur Integration bzgl. Tischtelefon kann ich nichts sagen, hier liegt die Kompatibilität in der Hand von Yealink.
Gruß Wolfgang
Hallo,
bitte überprüfen, ob in der Server Administration unter Telfone\Konfigurierte Endgeräte\xxx.WinClient\Erweiterte Einstellungen\Codecs der h264 enthalten ist.
g722,alaw,ulaw,h264
Wenn nicht, bei allen beteiligten Telefonkonfigurationen den h264 ans Ende anfügen.
Gruß Wolfgang
Hallo Jonas,
vielen Dank für die Bestätigung der Fehlersituation. Der Fehler ist dann mit 7.3 gelöst.
Viele Grüße
Wolfgang
Du kannst in den Experten-Einstellungen des Clients die Option "UseDirectXVideo" auf False stellen.
Gruß Wolfgang
Gibt es hierzu schon einen Supportfall?
Gruß Wolfgang
Wenn es nur 1 Teilnehmer ohne Telefonnummer ist, fügst Du diesen zuletzt hinzu. Ansonsten leider bis zum Update warten und bis dahin die Konferenzen über das Web Frontend zusammenstellen.
Gruß Wolfgang
Es ging früher nicht, der grüne Button in den Clients war und ist nur für Softphone Anrufe aktiviert.
Gruß Wolfgang
Der Fehler ist bekannt und ist mit der nächsten Version behoben. Der Fehler trat auf, wenn zuvor ein Teilnehmer ohne Telefonnummer hinzugefügt wurde.
Gruß Wolfgang
Sollte funktionieren. Hast Du eine Ticket ID, gibt es Logs?
Gruß Wolfgang
Für dieses Szenario müsste der Terminal Server Client (A) dem lokalen Client (B) oder ggf. auch dem Tischtelefon (C - wäre dann ja ebenso gewünscht) signalisieren können, dass dieser doch bitte einen konkreten SIP Ruf annehmen soll.
Technisch ist denkbar:
- A sagt dem Server, dass der Ruf angenommen werden soll. Der Server nimmt den Ruf weg und stellt ihn neu als "auto-answer" zu, der dann enstprechend angenommen wird. Nicht schön.
- A sagt B über z.B. XMPP, dass B den Ruf annehmen soll. Auch nicht schön. Auch klappt das nicht für A-C
- A sagt C über 3rd Party Protokoll (Web Request oder so), dass C den Ruf annehmen soll. Nicht schön, muss außerdem für jeden Telefontypen individuell implementiert werden und geht vermutlich nicht bei allen Herstelleren. Auch nicht schön.
Gefällt mir alles nicht, aber ich verstehe das Anliegen.
Beim "anderen" Hersteller in Dortmund haben wir damals das Client-Server Protokoll anders aufgezogen, da war dies einfacher umsetzbar, wir hatten da auch noch kein SIP in Verwendung.
Hier gilt es abzuwägen, wieviel schmutzige Implementierung möglich und sinnvoll ist, um Dinge umzusetzen, die vom SIP Protokoll so nicht vorgesehen sind.
Gruß Wolfgang
Hallo,
tapi4ast.tsp ist nicht von STARFACE, innerhalb der STARFACE Anwendungen spielt für die TAPI Microsoft COM auch keine Rolle. Ich gehe von einem Fehler der Dritt-Anwendung aus.
Gruß Wolfgang
Ich erwarte, dass es auch mit der neueren Version funktioniert, habe es aber noch nicht getestet.
Gruß Wolfgang