Fehlerbehebung bei Jabber Softphone für VDI - Häufige Probleme

Einleitung

In diesem Dokument werden die häufigsten Probleme mit Jabber Softphone bei VDI sowie deren Behebung beschrieben. 

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse von Cisco Unified Communications Manager (CUCM) und Jabber Softphone für VDI (JVDI) verfügen. 

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

• Cisco Unified Communications Manager 14.0.1 SU2
• Cisco Jabber 14.1.3
• JVDI-Agent 14.1.3
• JVDI-Client 14.1.3

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Häufige Probleme und Lösungen

CTI-Fehler

Wenn ein JVDI-Softphone-Fehler auf eine fehlgeschlagene CTI-Verbindung zurückzuführen ist, zeigt der Jabber-Verbindungsstatus aus der VDI den virtuellen Kanal und das SIP als verbunden an, CTI jedoch als nicht verbunden. 

CTI-Verbindungsfehler

Wenn die SIP-Verbindung vom JVDI-Client funktioniert und ein CTI-Fehler auftritt, wird das Jabber CSF-Gerät auf der CUCM-Website Administration > Device > Phone (Verwaltung > Gerät > Telefon) als registriert angezeigt. 

CSF bei CTI-Ausfall registriert

CTI-Zeitüberschreitung

Sammeln Sie die aufgelisteten Ablaufverfolgungen und Protokolle, um zu überprüfen, ob ein CTI-Timeout aufgetreten ist.

• CUCM CTIManager-Ablaufverfolgungen
• Jabber-Problembericht zur virtuellen Desktop-Infrastruktur (VDI)

CUCM CTIManager SDL Trace zeigt an, dass CTIManager eine Neubindung an LDAP versucht und den Netzwerk-Timeout auf 5 Sekunden festlegt. 

33538217.033 | 07:32:28.921 |AppInfo |authenticationDB::login (Authentifizierung über LDAP)
33538217.038 | 07:32:28.921 |AppInfo |LDAP nicht initialisiert...wird verbunden...
33538217.042 | 07:32:28.921 |AppInfo |Authentifizierung mit SSL nicht aktiviert (0)-(ldap://ldap.domain.local:389)
33538217.046 | 07:32:28.924 |AppInfo |LDAP setzt die Option LDAP_OPT_NETWORK_TIMEOUT auf 5 Sekunden

CUCM CTIManager SDL Trace gibt an, dass CTIManager die Zeitüberschreitung überprüft hat und sendet ein vollständiges Anbieterereignis mit einem Zeitüberschreitungsfehler an Jabber. 

33538233.000 | 07:32:38.644 |SdlSigns |CtiLoginCheckTimeout |Authentifizierung |CTIHandler(1,200,12,212) |SdlTimerService(1,200,3,1) |1.200.21.215,3^*^* |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] mSequenceNumber=2
33538233.003 | 07:32:38.647 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777428 CM Version=14.0.1 error code=2362179701 description=Directory login failed - timeout enableIPv6=0 NoOfDaysPwdToExp=4294967295
33538233.004 | 07:32:38.651 |AppInfo |CtiProviderOpenFailure - CTI-Anwendung konnte Anbieter nicht öffnen; Anwendungsstart fehlgeschlagen CTIconnectionId:212 Ursachencode.:-1932787595 IPAddress: xxx.xxx.xxx.xxx IPv6Address: App ID:Cisco CTIManager Cluster ID:StandAloneCluster Node ID:cucmpub.domain.local

Das Jabber-Protokoll zeigt, dass Jabber den PROVIDER_OPEN_COMPLETED_EVENT vom CTIManager erhalten hat und die CTI-Verbindung aufgrund des erhaltenen Timeout-Fehlers beendet wird.  

24.01.2023 07:32:38,598 DEBUG [0x000026e0] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
24.01.2023 07:32:38,598 WARN [0x000026e0] [rc\deskphoneprovider\DPProvider.cpp(598)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - Anbieter Öffnen fehlgeschlagen: Grund: 0x8ccc0075, Verzeichnisanmeldung fehlgeschlagen - Timeout
2023-01-24 07:32:38,598 FEHLER [0x000026e0] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection: Socket-Trennung fehlgeschlagen!

CTI-Zeitüberschreitungslösungen

1.  Überprüfen Sie den verwendeten CUCM-LDAP-Authentifizierungsport. Das Ändern des Authentifizierungsports in einen Port des globalen Katalogs (3268\3269) kann die Verzögerung für Authentifizierungsanforderungen verringern.
2.  Überprüfen Sie, ob die LDAP-Authentifizierungsserver als vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) konfiguriert sind. Wenn dies der Fall ist, stellen Sie sicher, dass alle Server-FQDN über DNS vom CUCM auflösbar sind.

Hinweis: Der Cisco CTIManager muss nicht neu gestartet werden, wenn der Authentifizierungsport geändert wird. 

CTI-Berechtigungen

Um zu überprüfen, ob CTI-Berechtigungen die Ursache eines CTI-Fehlers sind, sammeln Sie die aufgeführten Ablaufverfolgungen und Protokolle.

• CUCM CTIManager-Ablaufverfolgungen
• Jabber-Problembericht von VDI

CUCM CTIManager SDL Traces zeigt, wie CTIManager die Benutzereinstellungen überprüft. Während der Einstellungsüberprüfung sendet CTIManager ein ProviderOpenCompletedEvent, das Jabber benachrichtigt, dass der Benutzer nicht über die erforderlichen Berechtigungen zum Ausführen der CTI-Steuerung verfügt.  

33401907.000 | 07:49:58.670 |SdlSigns |CtiUserSettingsRes |Verifizieren |CTIHandler(1,200,12,150) |CTIDbAccess(1,200,8,1) |1.200.21.153,3^*^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] SuperProvider = Disabled CallParkRetrievalAllowed = Disabled ModifyCallingNumber = Disabled CTI Enabled = Disabled CallMonitor=Disabled CallRecord=Disabled UserID = jking result=0
33401907.005 | 07:49:58.670 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777366 CM Version=14.0.1 error code=2362179679 description=Directory login failed - User not present in Standard CTI Users group. enableIpv6=0 NoOfDaysPwdToExp=4294967295
33401907.006 | 07:49:58.673 |AppInfo |CtiProviderOpenFailure - CTI-Anwendung konnte Anbieter nicht öffnen; Anwendungsstart fehlgeschlagen CTIconnectionId:150 Ursachencode:-1932787617 IPAddress:xxx.xxx.xxx.xxx IPv6Address: App ID:Cisco CTIManager Cluster ID:StandAloneCluster Node ID:cucmpub.domain.local

Jabber-Protokolle weisen darauf hin, dass Jabber PROVIDER_OPEN_COMPLETED_EVENT vom CTIManager empfängt, jedoch aufgrund falscher Berechtigungen fehlschlägt. 

23.01.2023 07:49:58,561 DEBUG [0x000026a8] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
23.01.2023 07:49:58,561 WARN [0x000026a8] [rc\deskphoneprovider\DPProvider.cpp(598)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - Anbieter Öffnen fehlgeschlagen: Grund: 0x8ccc005f, Verzeichnisanmeldung fehlgeschlagen - Benutzer ist in der Standard-CTI-Benutzergruppe nicht vorhanden.
23.01.2023 07:49:35,561 FEHLER [0x000026a8] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection: Socket-Trennung fehlgeschlagen!

CTI-Berechtigungslösung

1. Dieses Problem kann durch Hinzufügen der Standard-CTI-Rolle Enabled (Aktiviert) zur CUCM-Endbenutzerkonfiguration (CUCM-Verwaltung > Benutzerverwaltung > Endbenutzer) behoben werden.

Standard-CTI - CUCM-Endbenutzerrolle aktivieren

CTI-Leitungssteuerung deaktiviert

Sammeln Sie die aufgeführten Ablaufverfolgungen und Protokolle, um zu überprüfen, ob CTI-Leitungssteuerungsfehler vorliegen.

• CUCM CTIManager-Ablaufverfolgungen
• Jabber-Problembericht von VDI

CUCM CTIManager SDL Trace zeigt, dass der CTI Manager eine LineOpen-Anforderung von Jabber erhalten hat. CTIManager kann die offene Leitung nicht ausführen und sendet ein "Line Open"-Fehlerereignis an Jabber.

33407677.002 | 08:35:28.159 |AppInfo |[CTI-APP] [CTIHandler::processIncomingMessage] CTI LineOpenRequest ( seq#=5 AutoAccept=0 Partition=Internal_PT)
33407688.000 | 08:35:28.162 |SdlSig-I |CtiLineOpenLineRes |Bereit |CTIDeviceLineMgr(1,200,9,1) |CTIRegistrar(3,100,26,1) |1,200,21,167.6^xxx.xxx.xxx.xxx^CSFJKING |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] AsyncResponse=624 Name=CSFJKING LH=1|145 Result=0x8ccc00d3 Auto Accept Status=0
33407688.001 | 08:35:28.162 |AppInfo |[CTI-APP] [Line(145)::openLineResponse] (Signal=CtiLineOpenLineRes State=lineState_Opening LineNumber=1151026, LineHandle: CtiID=1:LineID=145, LineRequestTimeout=5)
33407688.002 | 08:35:28.162 |AppInfo |CtiLineOpenFailure - Die CTI-Verbindungs-ID konnte nicht geöffnet werden:1 Gerätename:CSFJKING Verzeichnisnummer:1151026 Partition:Internal_PT UNKNOWN_PARAMTYPE:Grund:-1932787501 Anwendungs-ID:Cisco CTIManager Cluster-ID:StandAloneCluster Node-ID:cucmpub.domain.local

33407688.008 | 08:35:28.162 |AppError |LineOpen fehlgeschlagen. Leitung wird entfernt. Gerät=CSFJKING Lokal LH=1|145
33407689.003 | 08:35:28.176 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI LineClosedEvent ( LH=1|144 reason=8 )

Jabber.log zeigt, dass Jabber LINE_CLOSED_EVENT vom CTI-Manager erhalten hat und die Leitung außer Betrieb setzt. Sobald Jabber den Out-of-Service-Status erreicht hat, wird ein Close-Ereignis für Gerät und Anbieter an den CTI-Manager gesendet, und die CTI-Verbindung wird getrennt. 

23.01.2023 08:35:28,471 DEBUG [0x00001e6c] [c\deskphoneprovider\DPProvider.cpp(1405)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=id 0] Empfangen: , pdunames[nPduNum]=LINE_CLOSED_EVENT
23.01.2023 08:35:28,471 DEBUG [0x00001e6c] [cc\src\deskphoneprovider\DPLine.cpp(711)] [csf.ecc] [CDPLine::HandleEvent_LineClosed] - CDPLine::HandleEvent_LineClosed
23.01.2023 08:35:28,471 DEBUG [0x00001e6c] [c\src\deskphoneprovider\DPLine.cpp(1078)] [csf.ecc] [CDPLine::OutOfService] - CDPLine::OutOfService, bClose=1
23.01.2023 08:35:28,486 DEBUG [0x00002818] [c\deskphoneprovider\DPProvider.cpp(1086)] [csf.ecc] [CDPProvider::SendRequest] - [id=0] SendRequest Succeed ed., pdunames[msg.msgID]=DEVICE_CLOSE_REQUEST, msg.sequenceNumber=6
23.01.2023 08:35:28,486 DEBUG [0x00002818] [c\deskphoneprovider\DPProvider.cpp(1086)] [csf.ecc] [CDPProvider::SendRequest] - [id=0] SendRequest Succeed ed., pdunames[msg.msgID]=PROVIDER_CLOSE_REQUEST, msg.sequenceNumber=7
23.01.2023 08:35:28,486 FEHLER [0x00001e6c] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection: Socketdiskette Verbindung fehlgeschlagen!

Lösung zum Schließen von Posten

Überprüfen Sie, ob die Einstellung Allow Control of Device from CTI (Kontrolle des Geräts von CTI zulassen) in der CSF-Leitungskonfiguration aktiviert ist (CUCM-Verwaltung > Gerät > Telefon). 

Verzeichnisnummer CTI-Berechtigungen

Hinweis: Wenn "Kontrolle des Geräts von CTI zulassen" auf der Leitung aktiviert ist, die CTI-Fehler jedoch weiterhin angezeigt werden, schalten Sie die Einstellung aus und beim Speichern zwischen den Änderungen um.

CTI-Gerätezuweisung

Um zu überprüfen, ob CTI-Gerätezuordnungsfehler vorliegen, sammeln Sie die aufgeführten Ablaufverfolgungen und Protokolle.

• CUCM CTIManager-Ablaufverfolgungen
• Jabber-Problembericht von VDI

CUCM CTIManager SDL Trace zeigt an, dass der CTI-Manager den PROVIDER_OPEN_REQUEST empfängt und eine Anbieterantwort mit erfolgreicher Benutzerauthentifizierung sendet.

33301558.002 | 13:27:34.924 |AppInfo |CTIManager::CtiManager::providerOpenRequest(): PROVIDER_OPEN_REQUEST empfangen — Verbindungs-ID=2 TcpHandle=[1:200:21:139] PeerIPAddr=xxx.xxx.xxx PeerPort=50155 Benutzername= CtiHandler= [1:200:12:136]
33301560.004 | 13:27:34.925 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenResponse (seq#=2) provider id=16777352 FIPSMode = 0
33301565.090 | 13:27:35.271 |AppInfo |AuthenticationImpl:: Authentifizierung erfolgreich für Benutzer-ID: jking

Anschließend führt der CTI Manager eine Suche nach den vom CUCM-Endbenutzer gesteuerten Geräten durch, und es wurden keine Geräte gefunden. Ein ProviderOpenCompleteEvent wird dann an Jabber gesendet, wobei TotalControllableDevices auf 0 festgelegt ist. 

33301572.000 | 13:27:35.271 |SdlSigns |CtiDeviceListWithDPFetchRes |Bereit |CTIDeviceRegManager(1,200,10,1) |CTIDbAccess(1,200,8,1) |1.200.21.139,3^*^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] EnumHandle=89 NumDevices=0 Total=0 mbMore=0
33301572.001 | 13:27:35.271 |AppError |ready_ctiDeviceListWithDPFetchRes EnumHandle=89 numDevices=0 TotalDevices=0 More=0 Result=0
33301577.004 | 13:27:35.272 |AppInfo |[CTI-INFO] [CTIHandler::GenerateQBEProviderOpenSuccess] totalControllableDevices = 0
33301577.007 | 13:27:35.272 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777352 dscpForCTI2Apps =96 EnableIPv6 =0 autoCallPickupEnabled =0 LoginUserID = NoOfDaysPwdToP Exp =4294967295 TotalControllableDevices =0 ClusterId =StandaloneCluster

Jabber.log zeigt, dass Jabber das ProviderOpenCompleteEvent vom CTI-Manager erhalten hat. Zeitüberschreitung bei der Anforderung zum Abrufen von Geräten und Fehler 8 beim HandleOpenFailed.  

22.01.2023 13:26:13,888 DEBUG [0x000025a4] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
22.01.2023 13:26:13,888 DEBUG [0x000025a4] [c\deskphoneprovider\DPProvider.cpp(1423)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] PDUTYPE_ProviderEvent oder PDUTYPE_Heartbeat, nPduNum=126, pdunames[nPduNum]=PROVIDER_OPEN_COMPLETED_EVENT
22.01.2023 13:26:13,888 DEBUG [0x000025a4] [rc\deskphoneprovider\DPProvider.cpp(577)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - [id=0] CDProvider::HandleEvent_ProviderOpenCompleted

22.01.2023 13:26:32,868 DEBUG [0x00002404] [per\DeskPhoneConnectionContext.cpp(1068)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::GetDevicesTimeout WorkItem::run] - [id=1] DeskPhoneConnectionContext::GetDevicesTimeoutWorkItem::run()
22.01.2023 13:26:32,868 DEBUG [0x00002404] [per\DeskPhoneConnectionContext.cpp(1071)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::GetDevicesTimeout WorkItem::run] - [id=1] Zeitüberschreitung für Geräte
22.01.2023 13:26:32,868 FEHLER [0x00002404] [pper\DeskPhoneConnectionContext.cpp(509)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::handleOpenFailed] - [id=1] Zustand:2Anmeldezustand:3Fehler:8

Jabber schließt dann die CTI-Verbindung mit dem CUCM und setzt den Telefoniedienst auf "Disconnected" (Verbindung getrennt), weil kein Gerät gefunden wurde. 

22.01.2023 13:26:32,868 DEBUG [0x00002040] [c\deskphoneprovider\DPProvider.cpp(1070)] [csf.ecc] [CDPProvider::SendRequest] - [id=1] CDPProvider der::SendRequest, msg.sequenceNumber=4, pObject=1758DB6C, pdunames[msg.msgID]=PROVIDER_CLOSE_REQUEST
22.01.2023 13:26:32,868 INFO [0x00002040] [\deskphoneprovider\CtiConnection.cpp(60)] [csf.ecc] [CtiConnection::stop] - CtiConnection::stop
22.01.2023 13:26:32,868 FEHLER [0x00001e10] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection: Socket Fehler beim Trennen der Verbindung.

2023-01-22 13:26:32,868 DEBUG [0x000024fc] [ntrol\TelefonyCallControlImpl.cpp(1022)] [jcf.tel.callcontrol] [CSFUnified::TelefonyCallControlImpl::onServiceStartResult] - Service Start Result: [eDeskPhone], Connection Failure code: [eDeviceRegSelectedDeviceNotFound]
2023-01-22 13:26:32,868 INFO [0x00002434] [ices\impl\TelefonyServiceImpl.cpp(3998)] [jcf.tel.service] [CSFUnified::TelefonyServiceImpl::OnTelefony ServiceConnectionStatusChanged] - Verbindungsstatus des Telefoniedienstgeräts geändert von [Verbindung hergestellt] zu [Verbindung getrennt]
2023-01-22 13:26:32,868 DEBUG [0x00002434] [\impl\TelefonyServerHealthImpl.cpp(477)] [jcf.tel.health] [CSFUnified::TelefonyServerHealthImpl::commitIf NotAlreadyCommitted] - Der Zustand des Desktop-Videoservers wurde nicht bestätigt, da noch kein Desktop-Telefon in der Geräteliste gefunden wurde.

CTI Device Association-Lösung

1. Diese Fehler treten auf, wenn die JVDI-CSF-Geräte nicht auf den vom CUCM-Endbenutzer gesteuerten Geräten vorhanden sind. Hinzufügen des CSF-Geräts zu den gesteuerten Geräten, um dieses Problem zu beheben (CUCM-Verwaltung > Benutzerverwaltung > Endbenutzer).

CUCM-gesteuerte Geräte

CTI-Gerätesteuerung deaktiviert

Überprüft, ob die CTI-Gerätesteuerung deaktiviert ist.sammelt die aufgelisteten Ablaufverfolgungen und Protokolle.

• CUCM CTIManager-Ablaufverfolgungen
• Jabber-Problembericht von VDI

Im Jabber-Protokoll ist angegeben, dass Jabber eine DEVICE_OPEN_REQUEST an den CUCM CTI Manager gesendet hat. 

23.01.2023 08:14:26,674 DEBUG [0x00002578] [c\deskphoneprovider\DPProvider.cpp(1086)] [csf.ecc] [CDPProvider::SendRequest] - [id=0] SendRequest Succeed ed., pdunames[msg.msgID]=DEVICE_OPEN_REQUEST, msg.sequenceNumber=4

CUCM CTIManager SDL Trace zeigt, dass der CTI Manager die Anforderung zum Öffnen des Geräts erhalten hat, und antwortet mit einem "CtiDeviceOpenFailure" auf Jabber. 

33404809.002 | 08:14:27.899 |AppInfo |[CTI-APP] [CTIHandler::processIncomingMessage] CTI DeviceOpenRequest ( seq#=4 device name=CSFJKING softkeys AppID=1234)
33404811.009 | 08:14:27.899 |AppError |DeviceThirdParty::isDeviceOpenValid deviceName=CSFJKING Sending CtiDeviceOpenDeviceRes (Seq#=4 error=0x8ccc00d2)
33404812.003 | 08:14:27.899 |AppInfo |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI FailureResponse ( seq#=4 result=2362179794 description=)
33404812.004 | 08:14:27.900 |AppInfo |CtiDeviceOpenFailure - Device Open failed CTI Connection ID:154 Gerätename:CSFJKING UNKNOWN_PARAMTYPE:ReasonCode:-1932787502 App-ID:Cisco CTIManager Cluster-ID:StandAloneCluster Node-ID:cucmpub.domain.local Prozess-ID:jking-xxx.xxx.xxx.xxx-51126 Prozess ID:29347 Prozessname:CTIhandler

Jabber.log zeigt, dass Jabber die Fehlerantwort vom CTI-Manager erhalten hat und die CTI-Sitzung getrennt wurde.

23.01.2023 08:14:27,674 FEHLER [0x00002578] [c\deskphoneprovider\DPProvider.cpp(1287)] [csf.ecc] [CDPProvider::DispatchTheMessage] - Failureure Antwort, Ergebnis=0x8ccc00d2, (CTIERR_DEVICE_RESTRICTED)
23.01.2023 08:14:27,674 DEBUG [0x00002578] [c\deskphoneprovider\DPProvider.cpp(1333)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] Empfangen, pdunames[nPduNum]=FAILURE_RESPONSE, seqNum=4
23.01.2023 08:14:27,686 FEHLER [0x00002578] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection: Socketdiskette Verbindung fehlgeschlagen!

CTI Device Control-Lösung deaktiviert

1. Überprüfen Sie, ob die Einstellung Allow Control of Device from CTI (Kontrolle des Geräts von CTI zulassen) in der CSF-Gerätekonfiguration aktiviert ist (CUCM-Verwaltung > Gerät > Telefon). 

CTI des CSF-Geräts ermöglicht Kontrolle

SIP-Fehler

Wenn ein JVDI-Softphone-Fehler auf eine fehlgeschlagene SIP-Verbindung zurückzuführen ist, zeigt der Jabber-Verbindungsstatus aus der VDI den virtuellen Kanal als verbunden an, während der SIP- und der CTI-Status als nicht verbunden angezeigt werden. 

JVDI-SIP-Fehler

Wenn die SIP-Verbindung vom JVDI-Client fehlschlägt, wird das Jabber CSF-Gerät auf der Website CUCM Administration > Device > Phone (CUCM-Verwaltung > Gerät > Telefon) als nicht registriert angezeigt. 

CUCM-CSF nicht registriert

SIP-Socket-Ausfall

Bei JVDI stammt der gesamte SIP-Datenverkehr vom JVDI-Client auf dem Thin Client-System. Sammeln Sie zur Fehlerbehebung die aufgeführten Ablaufverfolgungen und Protokolle.

• CUCM-CallManager-Ablaufverfolgungen
• Jabber-Problembericht von VDI

Das JVDI-Client-vxc-Protokoll zeigt, dass die primären und sekundären CUCM-Server für die SIP 5060-Signalisierung verwendet werden. Der primäre Server ist auf den aktiven Server eingestellt. 

2020-01-23 08:58:44,623 DEBUG [0x00000000000036a0] [ore\sipstack\sip_common_transport.c(866)] [csf.sip-call-control] [sipTransportCfgTableInit] - [SIP][TRANS S][1] PRIMARY_CCM: IPv4-Adresse: cucmsub.domain.local:5060 IPv6-Adresse: :5060 Transportadresse: 4
2020-01-23 08:58:44,623 DEBUG [0x00000000000036a0] [ore\sipstack\sip_common_transport.c(866)] [csf.sip-call-control] [sipTransportCfgTableInit] - [SIP][TRANS S][2] SECONDARY_CCM: IPv4-Adresse: cucmpub.domain.local:5060 IPv6-Adresse: :5060 Transport: 4
2020-01-23 08:58:44,633 FEHLER [0x00000000000036a0] [re\sipstack\sip_common_transport.c(1075)] [csf.sip-call-control] [sip_transport_get_ti_addr] - [SIP][TRANS S] Nein, aktiv 1: PRIMARY_CCM wurde mit primärem CUCM gefunden.

Der JVDI-Client meldet eine fehlgeschlagene Socket-Verbindung, wenn versucht wird, eine Verbindung zum primären Server an Port 5060 herzustellen. Die Sitzung wird anschließend gelöscht. 

2020-01-23 08:58:44,656 DEBUG [0x00000000000036a0] [\core\sipstack\ccsip_platform_tcp.c(910)] [csf.sip-call-control] [sip_tcp_set_reason_for_active_confailed] - SIPCC-SIP_TCP_MSG: sip_tcp_set_reason_for_active_connfailed: Keine Verbindung mit Active Server (). unRegReason:12 Fehler:0, Ursache:1, Grund:[SOCKET_REMOTE_CLOSURE / CC_UNREG_REASON_CM_RESET_TCP]
2020-01-23 08:58:44,656 INFO [0x00000000000036a0] [tiveapp\sipcc\core\ccapp\cc_alarm.c(816)] [csf.sip-call-control] [setUnregReason] - SIPCC-PLAT_API: setUnregReason: setting unreg reason to=12
2020-01-23 08:58:44,656 DEBUG [0x00000000000036a0] [sipstack\sip_transport_connection.c(282)] [csf.sip-call-control] [sip_transport_connection_on_socket_error] - [SIP][CONN][] socket(3912) error:-1
2020-01-23 08:58:44,656 DEBUG [0x00000000000036a0] [\core\sipstack\ccsip_platform_tcp.c(634)] [csf.sip-call-control] [sip_tcp_destroy_connection] - SIPCC-SIP_SOCK: sip_tcp_destroy_connection: purp GE-Eintrag, Socket ist 3912, connid ist 0
2020-01-23 08:58:44,656 INFO [0x00000000000036a0] [\core\sipstack\ccsip_platform_tcp.c(384)] [csf.sip-call-control] [sip_tcp_purge_entry] - SIPCC-SIP_TCP_MSG: sip_tcp_purge_purge Eintrag: Socket Fd: 3912 geschlossen für connid 0 mit Adresse: xxx.xxx.xxx.xxx, Remote-Port: 5060
2020-01-23 08:58:44,656 DEBUG [0x00000000000036a0] [e\sipstack\sip_transport_session.c(1055)] [csf.sip-call-control] [sip_transport_session_disconnect] - [SIP][SESS] [0] Verbindung zerstören.
2020-01-23 08:58:44,656 INFO [0x00000000000036a0] [re\sipstack\sip_common_transport.c(1666)] [csf.sip-call-control] [sip_transport_on_session_create_failed] - [SIP][TRANS S][1] Transportkiste fehlgeschlagen.

Der JVDI-Client setzt dann die SIP-Verbindung auf "Fail" (Fehlgeschlagen) und die SIP-Route wird als "Destroyed" (Zerstört) markiert. 

2020-01-23 08:58:44,656 DEBUG [0x00000000000036a0] [\core\sipstack\sip_common_regmgr.c(3713)] [csf.sip-call-control] [sip_regmgr_on_transport_cucm_connection_failed] - SIPCC-SIP_REG: sip_regmgr_on_transport_cucm_connection_failed: [1] Fehler beim Herstellen der CUCM-Verbindung.
2020-01-23 08:58:44,656 INFO [0x00000000000036a0] [\core\sipstack\sip_common_regmgr.c(2242)] [csf.sip-call-control] [sip_regmgr_cc_create_failed] - SIPCC-SIP_CC_CONN: sip_regmgr gr_cc_create_failed: CUCM 1 verloren
2020-01-23 08:58:44,657 DEBUG [0x00000000000036a0] [ore\sipstack\sip_common_transport.c(306)] [csf.sip-call-control] [sip_transport_destroy_cc_conn] - [SIP][TRANS][1] Transportsitzung zerstören: Jabber <-..-> cucm-1 (PRIMARY_CCM)

Gängige Lösungen für SIP-Socket-Ausfälle:

1. Überprüfen Sie, ob Sie versuchen, JVDI über VPN zu verwenden, oder ob Sie die Verbindung mit der VDI über Citrix Access Gateway oder VMware Access Gateway herstellen.
   • Wenn ein VPN verwendet wird, stellen Sie sicher, dass die erforderlichen JVDI-Ports auf allen entsprechenden Sicherheits-Appliances zugelassen sind. Weitere Informationen finden Sie im Abschnitt zu den Port-Anforderungen im Jabber Softphone für VDI - Bereitstellungs- und Installationshandbuch. 
   • Wenn Sie Citrix Access Gateway oder VMware Access Gateway verwenden, muss Cisco JVDI MRA verwenden. Die Unterstützung von JVDI über MRA beginnt mit JVDI und Jabber, Version 12.6.
2. Wenn dieses Problem auf dem JVDI-Client in einem internen Netzwerk auftritt, überprüfen Sie:
   • Routing zwischen dem Thin Client-VLAN und dem CUCM-VLAN  
   • Stellen Sie sicher, dass alle für JVDI erforderlichen Ports erreichbar sind. Weitere Informationen finden Sie im Abschnitt zu den Port-Anforderungen im Jabber Softphone für VDI - Bereitstellungs- und Installationshandbuch. 
   • Erfassen Sie Pakete vom Thin Client und vom CUCM.
     • Überprüfen Sie, ob das TCP-Syn auf den CUCM gelangt. 
     • Überprüfen Sie, ob der Thin Client oder Server die TCP-Sitzung zurücksetzt.