Dépannage du téléphone logiciel Jabber pour VDI - Problèmes courants

Introduction

Ce document décrit les problèmes de téléphone logiciel Jabber les plus courants pour VDI et comment les corriger. 

Conditions préalables

Exigences

Cisco vous recommande de connaître Cisco Unified Communications Manager (CUCM) et Jabber Softphone pour VDI (JVDI). 

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions logicielles répertoriées :

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Problèmes courants et solutions

Erreurs CTI

Si une défaillance du téléphone logiciel JVDI est due à une connexion CTI défaillante, l'état de la connexion Jabber de la VDI affiche le canal virtuel et le SIP comme connecté mais CTI comme Non connecté. 

Échec de la connexion CTI

Lorsque la connexion SIP du client JVDI fonctionne et qu'une défaillance CTI se produit, le périphérique Jabber CSF s'affiche comme enregistré sur le site Web CUCM Administration > Device > Phone. 

CSF enregistré pendant la défaillance CTI

Délai CTI

Pour vérifier si un délai CTI a expiré, collectez les traces et les journaux répertoriés.

• Suivi CUCM CTIManager
• Rapport de problème Jabber à partir de l'infrastructure de bureau virtuel (VDI)

CUCM CTIManager SDL Trace indique que CTIManager tente une reconnexion à LDAP et définit le délai d'expiration du réseau sur 5 secondes. 

33538217.033 |07:32:28.921 |InfoApp |authenticationDB::login (authentification à l'aide de LDAP)
33538217.038 |07:32:28.921 |InfoApp |LDAP non initialisé...connexion...
33538217.042 |07:32:28.921 |InfoApp |Authentification avec SSL non activée (0)-(ldap://ldap.domain.local:389)
33538217.046 |07:32:28.924 |InfoApp |LDAP a défini l'option LDAP_OPT_NETWORK_TIMEOUT sur 5 secondes

CUCM CTIManager SDL Trace indique que CTIManager a vérifié que le délai d'attente a expiré et envoie à Jabber un événement Provider Complete contenant une erreur de délai d'attente. 

33538233.000 |07:32:38.644 |SdlSig |CtiLoginCheckTimeout |authentification |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] NuméroSéquence=2
33538233.003 |07:32:38.647 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777428 CM Version=14.0.1 error code=2362179701 description=Échec de la connexion au répertoire - timeout enableIpv6=0 NoOfDaysPwdToExp=4294967295
33538233.004 |07:32:38.651 |InfoApp |CtiProviderOpenFailure - Échec de l'ouverture du fournisseur par l'application CTI ; échec du démarrage de l'application CTIconnectionId : 212 Code de raison : -1932787595 IPAddress : xxx.xxx.xxx.xxx IPv6 Adresse : ID de l'application : ID du cluster Cisco CTIManager : ID du noeud StandAloneCluster : cucmpub.domain.local

Le journal Jabber indique que Jabber a reçu l'événement PROVIDER_OPEN_COMPLETED_EVENT de CTIManager et ferme la connexion CTI en raison de l'erreur de délai d'attente reçue.  

2023-01-24 07:32:38,598 DEBUG [0x000026e0] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDPProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
2023-01-24 07:32:38,598 WARN [0x000026e0] [rc\deskphoneprovider\DPProvider.cpp(598)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - Échec de ProviderOpen : raison : 0x8ccc0075, échec de la connexion au répertoire - délai d'attente
2023-01-24 07:32:38,598 ERREUR [0x000026e0] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection : échec de la déconnexion du socket !

Solutions CTI Timeout

1.  Vérifiez le port d'authentification LDAP CUCM utilisé. Le remplacement du port d'authentification par un port de catalogue global (3268\3269) peut réduire le délai des demandes d'authentification.
2.  Vérifiez si les serveurs d'authentification LDAP sont configurés en tant que nom de domaine complet (FQDN). Si c'est le cas, assurez-vous que tous les FQDN de serveur peuvent être résolus via DNS à partir de CUCM.

Remarque : Cisco TIManager ne doit pas être redémarré chaque fois que le port d'authentification est modifié. 

Autorisations CTI

Pour vérifier si les autorisations CTI sont la cause d'une défaillance CTI, collectez les traces et les journaux répertoriés.

• Suivi CUCM CTIManager
• Rapport de problème Jabber de VDI

Les traces SDL de CUCM CTIManager indiquent que CTIManager vérifie les paramètres utilisateur. Lors de la vérification des paramètres, CTIManager envoie un ProviderOpenCompletedEvent pour signaler à Jabber que l'utilisateur ne dispose pas des autorisations appropriées pour effectuer le contrôle CTI.  

33401907.000 |07:49:58.670 |SdlSig |CtiUserSettingsRes |vérification |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 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777366 CM Version=14.0.1 error code=2362179679 description=Échec de la connexion au répertoire - Utilisateur absent du groupe Utilisateurs CTI standard. enableIpv6=0 NoOfDaysPwdToExp=4294967295
33401907.006 |07:49:58.673 |InfoApp |CtiProviderOpenFailure - Échec de l'ouverture du fournisseur par l'application CTI ; échec du démarrage de l'application CTIconnectionId : 150 Code de raison : -1932787617 IPAddress : xxx.xxx.xxx.xxx IPv6 Adresse : ID de l'application : ID du cluster Cisco CTIManager : ID du noeud StandAloneCluster : cucmpub.domain.local

Les journaux Jabber indiquent que Jabber reçoit l'événement PROVIDER_OPEN_COMPLETED_EVENT de CTIManager, mais qu'il échoue en raison d'autorisations incorrectes. 

2023-01-23 07:49:58,561 DEBUG [0x000026a8] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDPProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
2023-01-23 07:49:58,561 WARN [0x000026a8] [rc\deskphoneprovider\DPProvider.cpp(598)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - Échec de ProviderOpen : raison : 0x8ccc005f, échec de connexion au répertoire - Utilisateur absent du groupe Utilisateurs CTI standard.
2023-01-23 07:49:35,561 ERREUR [0x000026a8] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection : échec de la déconnexion du socket !

Solution d'autorisations CTI

1. Ce problème peut être résolu en ajoutant le rôle CTI activé standard à la configuration des utilisateurs finaux de CUCM (CUCM Administration > User Management > End User).

Rôle d'utilisateur final CUCM actif CTI standard

Contrôle de ligne CTI désactivé

Pour vérifier s'il existe des erreurs de contrôle de ligne CTI, collectez les traces et les journaux répertoriés.

• Suivi CUCM CTIManager
• Rapport de problème Jabber de VDI

CUCM CTIManager SDL Trace show CTI Manager a reçu une demande LineOpenRequest de Jabber. CTIManager ne parvient pas à ouvrir la ligne et envoie un événement d'échec d'ouverture de ligne à Jabber.

33407677.002 |08:35:28.159 |InfoApp |[CTI-APP] [CTIHandler::processIncomingMessage] CTI LineOpenRequest ( seq#=5 AutoAccept=0 Partition=Internal_PT)
33407688.000 |08:35:28.162 |SdlSig-I |CtiLineOpenLineRes |prêt |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 |InfoApp |[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 |InfoApp |CtiLineOpenFailure - Impossible d'ouvrir la ligne ID de connexion CTI : 1 Nom du périphérique : Numéro de répertoire CSFJKING : 1151026 Partition : Internal_PT UNKNOWN_PARAMTYPE : Reason : -1932787501 ID d'application : ID de cluster Cisco CTIManager : StandAloneCluster ID de noeud : cucmpub.domain.local

33407688.008 |08:35:28.162 |AppError Échec de |LineOpen. Suppression de la ligne. Device=CSFJKING Local LH=1|145
33407689.003 |08:35:28.176 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI LineClosedEvent ( LH=1|144 raison=8 )

Jabber.log indique que Jabber a reçu l'événement LINE_CLOSED_EVENT du gestionnaire CTI et définit la ligne sur hors service. Une fois mis hors service, Jabber envoie un événement de fermeture de périphérique et de fournisseur à CTI Manager et la connexion CTI est interrompue. 

2023-01-23 08:35:28,471 DEBUG [0x00001e6c] [c\deskphoneprovider\DPProvider.cpp(1405)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] Reçu : , pdunames[nPduNum]=LINE_CLOSED_EVENT
2023-01-23 08:35:28,471 DEBUG [0x00001e6c] [cc\src\deskphoneprovider\DPLine.cpp(711)] [csf.ecc] [CDPLine::HandleEvent_LineClosed] - CDPLine::HandleEvent_LineClosed
2023-01-23 08:35:28,471 DEBUG [0x00001e6c] [c\src\deskphoneprovider\DPLine.cpp(1078)] [csf.ecc] [CDPLine::OutOfService] - CDPLine::OutOfService, bClose=1
2023-01-23 08:35:28,486 DEBUG [0x00002818] [c\deskphoneprovider\DPProvider.cpp(1086)] [csf.ecc] [CDPProvider::SendRequest] - [id=0] SendRequest Succeed., pdunames[msg.msgID]=DEVICE_CLOSE_REQUEST, msg.sequenceNumber=6
2023-01-23 08:35:28,486 DEBUG [0x00002818] [c\deskphoneprovider\DPProvider.cpp(1086)] [csf.ecc] [CDPProvider::SendRequest] - [id=0] SendRequest Succeed., pdunames[msg.msgID]=PROVIDER_CLOSE_REQUEST, msg.sequenceNumber=7
2023-01-23 08:35:28,486 ERREUR [0x00001e6c] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection : échec de la déconnexion du socket !

Solution de fermeture de ligne

Vérifiez que le paramètre Allow Control of Device from CTI est activé sur la configuration de ligne CSF (CUCM Administration > Device > Phone). 

Autorisations CTI du numéro de répertoire

Remarque : si l'option « Autoriser le contrôle du périphérique à partir de CTI » est activée sur la ligne, mais que les erreurs CTI sont toujours visibles, désactivez le paramètre et lors de l'enregistrement entre les modifications.

Association de périphériques CTI

Pour vérifier s'il existe des erreurs d'association de périphériques CTI, collectez les traces et les journaux répertoriés.

• Suivi CUCM CTIManager
• Rapport de problème Jabber de VDI

CUCM CTIManager SDL Trace revele CTI Manager reçoit la requête PROVIDER_OPEN_REQUEST et envoie une réponse du fournisseur avec l'authentification de l'utilisateur réussie.

33301558.002 |13:27:34.924 |InfoApp |CTIManager::CtiManager::providerOpenRequest(): PROVIDER_OPEN_REQUEST reçu — ID de connexion=2 TcpHandle=[1:200:21:139] PeerIPAddr=xxx.xxx.xxx.xxx PeerPort=50155 Nom d'utilisateur= CtiHandler=[1:200:12:136]
33301560.004 |13:27:34.925 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenResponse (seq#=2) provider id=16777352 FIPSMode = 0
33301565.090 |13:27:35.271 |InfoApp |AuthenticationImpl:: Authentification réussie pour l'ID utilisateur : plaisanterie

Ensuite, CTI Manager effectue une recherche des périphériques contrôlés par les utilisateurs finaux CUCM et aucun périphérique n'est trouvé. Un ProviderOpenCompleteEvent est ensuite envoyé à Jabber avec TotalControllableDevices défini sur 0. 

33301572.000 |13:27:35.271 |SdlSig |CtiDeviceListWithDPFetchRes |prêt |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 Autres=0 Résultat=0
33301577.004 |13:27:35.272 |InfoApp |[CTI-INFO] [CTIHandler::GenerateQBEProviderOpenSuccess] totalControllableDevices = 0
33301577.007 |13:27:35.272 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] CTI ProviderOpenCompletedEvent (seq#=2) provider id=16777352 dscpForCTI2Apps =96 EnableIpv6 =0 autoCallPickupEnabled =0 LoginUserID = NoOfDaysPwdToExp =4294967295 TotalControllableDevices =0 ClusterId =StandAloneCluster

Jabber.log indique que Jabber a reçu ProviderOpenCompleteEvent du gestionnaire CTI. La demande get devices a expiré et handleOpenFailed a généré une erreur 8.  

2023-01-22 13:26:13,888 DEBUG [0x000025a4] [c\deskphoneprovider\DPProvider.cpp(1274)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] CDPProvider::DispatchTheMessage, nPduNum=126, pduName=PROVIDER_OPEN_COMPLETED_EVENT
2023-01-22 13:26:13,888 DEBUG [0x000025a4] [c\deskphoneprovider\DPProvider.cpp(1423)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] PDUTYPE_ProviderEvent ou PDUTYPE_Heartbeat, nPduNum=126, pdunames[nPduNum]=PROVIDER ÉVÉNEMENT_OUVERTURE_TERMINÉE
2023-01-22 13:26:13,888 DEBUG [0x000025a4] [rc\deskphoneprovider\DPProvider.cpp(577)] [csf.ecc] [CDPProvider::HandleEvent_ProviderOpenCompleted] - [id=0] CDPProvider::HandleEvent_ProviderOpenCompleted

2023-01-22 13:26:32,868 DEBUG [0x00002404] [per\DeskPhoneConnectionContext.cpp(1068)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::GetDevicesTimeoutWorkItem::run] - [id=1] DeskPhoneConnectionContext::GetDevicesTimeoutWorkItem::run()
2023-01-22 13:26:32,868 DEBUG [0x00002404] [per\DeskPhoneConnectionContext.cpp(1071)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::GetDevicesTimeoutWorkItem::run] - [id=1] Temporisation des périphériques
2023-01-22 13:26:32,868 ERREUR [0x00002404] [pper\DeskPhoneConnectionContext.cpp(509)] [csf.ecc] [csf::ecc::DeskPhoneConnectionContext::handleOpenFailed] - [id=1] état:2login état:3error:8

Jabber ferme ensuite la connexion CTI à CUCM et définit le service de téléphonie sur déconnecté en raison de l'absence de périphérique. 

2023-01-22 13:26:32,868 DEBUG [0x00002040] [c\deskphoneprovider\DPProvider.cpp(1070)] [csf.ecc] [CDPProvider::SendRequest] - [id=1] CDPProvider::SendRequest, msg.sequenceNumber=4, pObject=1758DB6C, pdunames[msg.msgID]=4 VIDER_CLOSE_REQUEST
2023-01-22 13:26:32,868 INFO [0x00002040] [\deskphoneprovider\CtiConnection.cpp(60)] [csf.ecc] [CtiConnection::stop] - CtiConnection::stop
2023-01-22 13:26:32,868 ERREUR [0x00001e10] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection : échec de la déconnexion du socket !

2023-01-22 13:26:32,868 DEBUG [0x000024fc] [ntrol\TelephonyCallControlImpl.cpp(1022)] [jcf.tel.callcontrol] [CSFUnified::TelephonyCallControlImpl::onServiceStartResult] - Résultat de démarrage du service : [eDeskPhone], code d'échec de connexion : [eDeviceRegSelectedDeviceNotFound]
2023-01-22 13:26:32,868 INFO [0x00002434] [ices\impl\TelephonyServiceImpl.cpp(3998)] [jcf.tel.service] [CSFUnified::TelephonyServiceImpl::OnTelephonyServiceConnectionStatusChanged] - L'état de la connexion de l'unité de service de téléphonie est passé de [Connecting] à [Disconnected]
2023-01-22 13:26:32,868 DEBUG [0x00002434] [\impl\TelephonyServerHealthImpl.cpp(477)] [jcf.tel.health] [CSFUnified::TelephonyServerHealthImpl::commitIfNotAlreadyCommitted] - L'état du serveur vidéo du téléphone de bureau n'a pas été validé, car aucun téléphone de bureau n'a encore été trouvé dans la liste des périphériques

Solution d'association de périphériques CTI

1. Ces erreurs se produisent lorsque les périphériques CSF JVDI ne sont pas présents dans les périphériques contrôlés par l'utilisateur final CUCM. Ajout du périphérique CSF aux périphériques contrôlés pour corriger ce problème (CUCM Administration > User Management > End User).

Périphériques contrôlés par CUCM

Contrôle de périphérique CTI désactivé

Pour vérifier si le contrôle des périphériques CTI est désactivé.collectez les traces et les journaux répertoriés.

• Suivi CUCM CTIManager
• Rapport de problème Jabber de VDI

Le journal Jabber indique que Jabber a envoyé une requête DEVICE_OPEN_REQUEST au gestionnaire CTI CUCM. 

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

CUCM CTIManager SDL Trace révèle que CTI Manager a reçu la demande d'ouverture de périphérique et répond à Jabber avec un CtiDeviceOpenFailure. 

33404809.002 |08:14:27.899 |InfoApp |[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 Envoi de CtiDeviceOpenDeviceRes (Seq#=4 error=0x8ccc00d2)
33404812.003 |08:14:27.899 |InfoApp |[CTI-APP] [CTIHandler::OutputCtiMessage ] ÉchecRéponse CTI ( seq#=4 result=2362179794 description=)
33404812.004 |08:14:27.900 |InfoApp |CtiDeviceOpenFailure - Échec de l'ouverture du périphérique ID de connexion CTI : 154 Nom du périphérique : CSFJKING UNKNOWN_PARAMTYPE : ReasonCode : -1932787502 ID d'application : ID de cluster Cisco CTIManager : StandAloneCluster ID de noeud : cucmpub.domain.local ID de processus : jking-xxx.xxx.xxx-51126 ID de processus : 29347 Nom de processus : CtiHandler

Jabber.log indique que Jabber a reçu la réponse d'échec du gestionnaire CTI et que la session CTI est déconnectée.

2023-01-23 08:14:27,674 ERREUR [0x00002578] [c\deskphoneprovider\DPProvider.cpp(1287)] [csf.ecc] [CDPProvider::DispatchTheMessage] - FailureResponse, result=0x8ccc00d2, (CTIERR_DEVICE_RESTRICTED)
2023-01-23 08:14:27,674 DEBUG [0x00002578] [c\deskphoneprovider\DPProvider.cpp(1333)] [csf.ecc] [CDPProvider::DispatchTheMessage] - [id=0] Received, pdunames[nPduNum]=FAILURE_RESPONSE, seqNum=4
2023-01-23 08:14:27,686 ERREUR [0x00002578] [deskphoneprovider\CtiConnection.cpp(260)] [csf.ecc] [CtiConnection::SocketWorkItem::run] - CtiConnection : échec de la déconnexion du socket !

Solution CTI Device Control Disabled

1. Vérifiez que le paramètre Allow Control of Device from CTI est activé sur la configuration du périphérique CSF (CUCM Administration > Device > Phone). 

Contrôle autorisé CTI du périphérique CSF

Erreurs SIP

Lorsqu'une panne de téléphone logiciel JVDI est due à une connexion SIP défaillante, l'état de la connexion Jabber de la VDI affiche le canal virtuel comme connecté, mais l'état SIP et CTI indique Non connecté. 

Erreur JVDI SIP

Lorsque la connexion SIP du client JVDI échoue, le périphérique Jabber CSF apparaît comme non enregistré sur le site Web CUCM Administration > Device > Phone. 

CUCM CSF non enregistré

Défaillance du socket SIP

Avec JVDI, tout le trafic SIP provient du client JVDI sur la machine client léger. Pour résoudre les problèmes, collectez les traces et les journaux répertoriés.

• Suivi de CUCM CallManager
• Rapport de problème Jabber de VDI

Le journal vxc du client JVDI indique que les serveurs CUCM principal et secondaire sont utilisés pour la signalisation SIP 5060. Le serveur principal est défini sur le serveur actif. 

2020-01-23 08:58:44,623 DEBUG [0x00000000000036a0] [ore\sipstack\sip_common_transport.c(866)] [csf.sip-call-control] [sipTransportCfgTableInit] - [SIP][TRANS][1] PRIMARY_CCM : adresse IPv4 : cucmsub.domain.local:5060 Adresse IPv6 : :5060 transport : 4
2020-01-23 08:58:44,623 DEBUG [0x00000000000036a0] [ore\sipstack\sip_common_transport.c(866)] [csf.sip-call-control] [sipTransportCfgTableInit] - [SIP][TRANS][2] SECONDARY_CCM : adresse IPv4 : cucmpub.domain.local:5060 Adresse IPv6 : 506 0 transport : 4
2020-01-23 08:58:44,633 ERREUR [0x00000000000036a0] [re\sipstack\sip_common_transport.c(1075)] [csf.sip-call-control] [sip_transport_get_ti_addr] - [SIP][TRANS] Pas d'actif 1 : PRIMARY_CCM trouvé en utilisant le CUCM principal

Le client JVDI signale un échec de connexion de socket lors de la tentative de connexion au serveur principal sur le port 5060. La session est alors purgée. 

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_connfailed] - SIPC-SIP_TCP_MSG: sip_tcp_set_reason_for_active_connfailed: Disconnected from Active Server (). UnRegReason : 12 Error : 0, Cause : 1, Reason : [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 : définition de unreg reason sur=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][] erreur socket(3912) : -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] - SIPC-SIP_SOCK : sip_tcp_destroy_connection : purge entry, socket is 3912, connid is 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] - SIPC-SIP_TCP_MSG: sip_tcp_purge_entry: Socket fd: 3912 fermé pour connid 0 avec adresse : xxx.xxx.xxx.xxx, port distant : 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] détruisez la connexion.
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][1] échec de la création de transport !

Le client JVDI définit ensuite la connexion SIP sur échec et la route SIP est marquée comme détruite. 

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_connecting_failed] - SIPC-SIP_REG : sip_regmgr_on_transport_cucm_connecting_failed : [1] cucm connection failed !
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] - SIPC-SIP_CC_CONN : sip_regmgr_cc_create_failed : cucm 1 lost
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] delete transport session : jabber <-...-> cucm-1 (PRIMARY_CCM)

Solutions courantes aux pannes de sockets SIP :

1. Vérifiez si vous essayez d'utiliser JVDI sur VPN ou si vous vous connectez à VDI à l'aide de Citrix Access Gateway ou de VMware Access Gateway.
   • Si un VPN est utilisé, vérifiez que les ports JVDI requis sont autorisés sur tous les appareils de sécurité appropriés. Reportez-vous à la section Port Requirement du Guide d'installation et de déploiement du téléphone logiciel Jabber pour VDI. 
   • Si vous utilisez Citrix Access Gateway ou VMware Access Gateway, Cisco JVDI nécessite l'utilisation de MRA. La prise en charge de JVDI sur MRA commence dans JVDI et Jabber version 12.6.
2. Si le client JVDI rencontre ce problème sur un réseau interne, vérifiez les points suivants :
   • Routage entre le VLAN client léger et le VLAN CUCM.  
   • Vérifiez que tous les ports requis pour JVDI sont accessibles. Reportez-vous à la section Port Requirement du Guide d'installation et de déploiement du téléphone logiciel Jabber pour VDI. 
   • Collecter une capture de paquets à partir du client léger et du CUCM
     • Vérifiez si la connexion TCP Syn parvient au CUCM 
     • Vérifiez si le client léger ou le serveur réinitialise la session TCP.