Dépannage du téléphone MPP dans WxC pour l'approvisionnement et l'enregistrement

Mis à jour:18 avril 2024
ID du document:221021

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit comment dépanner des téléphones MPP dans WxC pour des problèmes de provisionnement et d'enregistrement lorsque le périphérique est ajouté par adresse MAC.

    Exigences

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • Connaissances de base du réseau
    • Téléphones MPP

    Composants utilisés

    Les informations contenues dans ce document sont basées uniquement sur les téléphones MPP tels que 78XX, 88XX.

    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.

    Ajout du périphérique dans le Control Hub

    Étape 1. Accédez à admin.webex.com et utilisez les informations d'identification de l'administrateur. Dans l'organisation, accédez à Périphériques > Ajouter un périphérique :

    Onglet PériphériquesOnglet Périphériques

    Étape 2. Sélectionnez Utilisation personnelle à affecter à un utilisateur ou Utilisation partagée à affecter à un espace de travail. (Dans ce scénario, un utilisateur est utilisé.)

    Ajouter un périphériqueAjouter un périphérique

    Étape 3. Recherchez et sélectionnez l'utilisateur que vous souhaitez attribuer à ce périphérique et cliquez sur Next :

    Rechercher un utilisateurRechercher un utilisateur

    Étape 4. Sélectionnez Cisco IP Phone et recherchez votre modèle de périphérique :

    Sélectionner le modèle de périphériqueSélectionner le modèle de périphérique

    Étape 5. Une fois que le périphérique est sélectionné, sélectionnez l'option By MAC Address et entrez l'adresse MAC du périphérique et cliquez sur Save:

    Ajouter une adresse MACAjouter une adresse MAC

    Étape 6. Une fois que le périphérique est dans le Control Hub, vous pouvez vérifier qu'il a été ajouté correctement lorsque vous recherchez l'adresse MAC dans la barre de recherche :

    Vérification du dispositifVérification du dispositif

    L'état indique « Non disponible », car le périphérique n'est toujours pas provisionné. Une fois que le périphérique est dans le Control Hub, l'étape suivante consiste à le réinitialiser en usine. Après la réinitialisation en usine, le périphérique doit demander aux serveurs WxC d'obtenir les fichiers de configuration. (Il s'agit du processus de provisionnement.) Le périphérique est correctement configuré lorsque le périphérique affiche le numéro de téléphone et/ou le poste à l'écran.

    Si vous constatez que le périphérique n'affiche pas la configuration appropriée, le processus de mise en service du périphérique a échoué.

    Bref résumé du processus de provisionnement d'un périphérique dans WxC

    Diagramme de provisionnementDiagramme de provisionnement

    Dépanner le processus de provisionnement d'un périphérique dans WxC

    Le périphérique MPP ne peut pas être configuré avec WxC s'il est configuré avec :

    • Un serveur TFTP configuré dans le serveur DHCP
    • Si Option (OPT66, OPT160, OPT159 ou OPT150) est configuré et fourni par le serveur DHCP

    Pour voir si le téléphone a pris une configuration TFTP à partir d'un serveur DHCP, les journaux PRT sont nécessaires.

    Générer les journaux PRT à partir d'un périphérique MPP

    Envoyer à partir des journaux PRT à partir du téléphone. La procédure suivante indique comment générer les journaux PRT.

    Générer le PRT à partir du périphérique

    Étape 1.Sur le périphérique, appuyez sur le bouton Applications Bouton Paramètresbouton Paramètres .

    Étape 2.Accédez à Status > Report Problem.

    Étape 3.Entrez la date et l’heure du problème.

    Étape 4. Sélectionnez une description dans la liste.

    Étape 5.Appuyez sur Envoyer. 

    Une fois les journaux envoyés, reportez-vous aux étapes suivantes pour télécharger les journaux PRT :

    Étape 1. Connectez-vous à https://IP_ADDRESS_PHONE/

    note-icon

    Remarque : si l'adresse IP est inconnue, vous pouvez l'obtenir à partir de Paramètres > État > État du réseau > État IPv4

    Étape 2. Accédez à Info > Debug Info > Download the PRT log (Cliquez avec le bouton droit sur le lien et sélectionnez Save As...)

    GUI WebGUI Web

    Journaux PRT

    Lorsque vous ouvrez les journaux, vous pouvez voir une vue comme celle-ci :
    note-icon

    Remarque : vous pouvez ouvrir les journaux avec un programme comme WinRAR puisque les journaux sont compressés.

    Vue Journal PRTVue Journal PRT
    Afin d'analyser le processus de provisionnement du périphérique, le journal appelé logcat doit être ouvert. Il peut être ouvert avec un éditeur de texte comme Notepad ou Notepad++.
    La fonction "Rechercher" de l'éditeur de texte peut être utilisée afin de déterminer si le téléphone a un serveur TFTP configuré. Utilisez DHCP-tftpsvr1 ou DHCP-tftpsvr2 pour rechercher la ligne spécifique pour ce journal. Si vous regardez les autres lignes des journaux, vous trouverez plus d'informations sur la configuration DHCP : 
    2154 NOT Aug 10 16:58:12.226653 (689-695) DHCP-IP Address: 192.168.238.1
2155 NOT Aug 10 16:58:12.226688 (689-695) DHCP-Subnet Mask: 255.255.255.0
2156 NOT Aug 10 16:58:12.226702 (689-695) DHCP-Default Gwy: 192.168.238.240
2157 NOT Aug 10 16:58:12.226734 (689-695) DHCP- ******** dhcpConvConfToExtOptionFile(): Usin
2158 NOT Aug 10 16:58:12.226790 (689-695) DHCP-hostname:SEP14A2A0E0837A
2159 NOT Aug 10 16:58:12.226835 (689-695) DHCP-ipaddr:192.168.238.1
2160 NOT Aug 10 16:58:12.226858 (689-695) DHCP-netmask:255.255.255.0
2161 NOT Aug 10 16:58:12.226878 (689-695) DHCP-router1:192.168.238.240
2162 NOT Aug 10 16:58:12.226894 (689-695) DHCP-domain:
2163 NOT Aug 10 16:58:12.226911 (689-695) DHCP-ntpsvr1:0.0.0.0
2164 NOT Aug 10 16:58:12.226929 (689-695) DHCP-ntpsvr2:0.0.0.0
2165 NOT Aug 10 16:58:12.226947 (689-695) DHCP-tftpsvr1:192.168.150.20
2166 NOT Aug 10 16:58:12.226966 (689-695) DHCP-tftpsvr2:0.0.0.0
2167 NOT Aug 10 16:58:12.226983 (689-695) DHCP-dns1:172.25.6.14
2168 NOT Aug 10 16:58:12.227001 (689-695) DHCP-dns2:172.25.10.31
2169 NOT Aug 10 16:58:12.227017 (689-695) DHCP-option160:
2170 NOT Aug 10 16:58:12.227032 (689-695) DHCP-option159:
2171 NOT Aug 10 16:58:12.227047 (689-695) DHCP-option125:
2172 NOT Aug 10 16:58:12.227061 (689-695) DHCP-option66:
    Comme vous pouvez le voir dans le journal, une adresse IP TFTP est configurée dans le serveur DHCP. Le téléphone a donc tenté de mettre en service ce serveur TFTP au lieu des serveurs Webex Calling. 
    3677 NOT Aug 10 16:58:50.718451 (823-940) voice-fapp-Provisioning using DHCP..
    3678 NOT Aug 10 16:58:50.718479 (823-940) voice-FUNCTION:fprv_update, proxy_Config:0
    3679 NOT Aug 10 16:58:50.718507 (823-940) voice-fprv_eval_profile_rule assemble url=tftp://192.168.150.20/$PSN.xml ,curState.profile_rule=/$PSN.xml
    3680 NOT Aug 10 16:58:50.718521 (823-940) voice-DHCP pending acquired=1 
    3681 NOT Aug 10 16:58:50.718772 (823-940) voice-fapp-[resync] fprv_eval_profile_rule - must resync
    3682 NOT Aug 10 16:58:50.721954 (823-940) voice-fapp-CP-8851-3PCC 14:a2:a0:e0:83:7a -- Requesting resync tftp://192.168.150.20:69/8851-3PCC.xml.
    Après avoir supprimé une configuration TFTP et une configuration OPT du serveur DHCP, vous devez réinitialiser le périphérique en usine afin de lancer le processus de réapprovisionnement du périphérique avec WxC.
    La première tentative que le téléphone fait avec le processus de provisioning du périphérique est d'effectuer une requête à l'URL activate.cisco.com. Le téléphone envoie une requête au serveur DNS afin de résoudre le domaine. Si la résolution DNS échoue, elle peut ressembler à ceci : 
    1753 NOT Aug 10 16:56:46.129550 (975-1286) voice-reqByCurlInternal sending http request out..., url: https://activate.cisco.x:443/software/edos/callhome/rc?id=<MAC_ADDRESS>:FCH2305DMH0:CP-8865-3PCC&sw=sip8845_
    1754 INF Aug 10 16:56:46.142687 dnsmasq[564]: query[A] activate.cisco.com from 127.0.0.1
    1755 INF Aug 10 16:56:46.142742 dnsmasq[564]: forwarded activate.cisco.com to 192.168.100.3
    1774 NOT Aug 10 16:56:54.146585 Couldn't resolve host 'activate.cisco.x'
    1777 NOT Aug 10 16:56:54.146325 (975-1286) voice-reqByCurlInternal return from http request, [res] = 6 Error
    1780 NOT Aug 10 16:56:54.147416 (975-1286) voice-fapp-CP-8865-3PCC <MAC_ADDRESS> -- Resync failed: Download failed
    1781 ERR Aug 10 16:56:54.148845 (975-1286) voice-fapp-fprv_eval_profile_rule return status=FPRV_ERR_SERVER_CONNECTION_FAILED err_count:0, retry_delay:60
    Si le téléphone peut résoudre le domaine, il peut se présenter comme suit : 
    1664 NOT Aug 10 16:56:35.440901 (968-1290) voice-reqByCurlInternal sending http request out..., url: https://activate.cisco.x:443/software/edos/callhome/1665 INF May 10 16:56:35.454477 dnsmasq[560]: query[A] activate.cisco.x from 127.0.0.1
    1666 INF Aug 10 16:56:35.454585 dnsmasq[560]: forwarded activate.cisco.x to 192.168.100.1
    1669 INF Aug 10 16:56:35.488147 dnsmasq[560]: reply activate.cisco.x is <CNAME>
    1670 INF Aug 10 16:56:35.488194 dnsmasq[560]: [cache_insert] activate.cisco.x[4008]: Wed May 10 17:21:46 2023
    1671 INF Aug 10 16:56:35.488219 dnsmasq[560]: reply activate.xglb.cisco.com is 173.36.XXX.XXX
    1683 NOT Aug 10 16:56:36.018143 GET /software/edos/callhome/rc?id=<MAC_ADDRESS>:FCH2305DMH0:CP-8865-3PCC&sw=sip8845_65.12-0-2MPP0001-20230510-156252b771&orig=orig_mpp&authstatus=none HTTP/1.1^M
     User-Agent: Cisco-CP-8865-3PCC/12.0.2 (MAC_ADDRESS)^M
     Host: activate.cisco.x^M
     Accept-Encoding: deflate, gzip^M
     Accept: */*^M
     Accept-Language: en^M
     Accept-Charset: iso-8859-1^M
     ^M
    1684 NOT May 10 16:56:36.137337 <
    1685 NOT May 10 16:56:36.137446 HTTP/1.1 200 ^M
    1760 NOT Sep 04 22:49:25.017943 (968-1290) voice-fapp-pal data updated for property name: Profile Rule to https://cisco.sipflash.x/ from /$PSN.xml
    Après avoir reçu le 200 OK de la requête GET à activate.cisco.com, le téléphone envoie une requête à cisco.siplash.com. Il s'agit du même processus, le téléphone tente de résoudre le domaine et s'il échoue, il peut se présenter comme suit : 
    2460 NOT May 10 17:03:14.644821 (975-975) voice-QPE:RESYNC profile=[https://cisco.sipflash.x/ ]
    2487 NOT May 10 17:03:14.924347 (975-1286) voice-reqByCurlInternal sending http request out..., url: https://cisco.sipflash.x:443/ 
    2488 INF May 10 17:03:14.925286 dnsmasq[564]: query[A] cisco.sipflash.x from 127.0.0.1
    2489 INF May 10 17:03:14.925318 dnsmasq[564]: forwarded cisco.sipflash.x to 192.168.100.3
    2503 NOT May 10 17:03:22.926249 "Couldn't resolve host 'cisco.sipflash.x"

    Si le téléphone peut résoudre le domaine, il peut se présenter comme suit :

    1980 NOT Sep 04 22:49:28.832733 (968-1290) voice-reqByCurlInternal sending http request out..., url: https://cisco.sipflash.x:443/ 
    1981 INF Sep 04 22:49:28.833577 dnsmasq[560]: query[A] cisco.sipflash.x from 127.0.0.1
    1982 INF Sep 04 22:49:28.833628 dnsmasq[560]: forwarded cisco.sipflash.x to 192.168.100.1
    1985 INF Sep 04 22:49:28.844068 dnsmasq[560]: reply cisco.sipflash.x is 199.59.XXX.XXX
    1993 NOT Sep 04 22:49:29.189918 (968-1290) voice-sec_set_min_TLS_version: min_TLS_verson is TLS 1.1,ret is 1 ...
    1994 NOT Sep 04 22:49:29.428716 > 
    1995 NOT Sep 04 22:49:29.428776 GET / HTTP/1.1^M
    User-Agent: Cisco-CP-8865-3PCC/12.0.2 (MAC_ADDRESS)^M
    Host: cisco.sipflash.x^M
    Accept-Encoding: deflate, gzip^M
    Accept: */*^M
    Accept-Language: en^M
    Accept-Charset: iso-8859-1^M
    ^M
    1996 NOT Sep 04 22:49:29.506969 < 
    1997 NOT Sep 04 22:49:29.507037 HTTP/1.1 200 OK^M

    Dépannage de DNS (provisionnement des URL)

    Si vous êtes sur le même réseau où les périphériques ont des problèmes avec la résolution DNS, une commande nslookup peut être utilisée pour vérifier si le serveur DNS est capable de résoudre le domaine. Ouvrez l'interface de ligne de commande et procédez comme suit :

    • nslookup -> Entrée
    • set type=A -> Entrée
    • activate.cisco.com

    Si le PC peut résoudre le domaine, il peut se présenter comme suit :

    nslookup activate.cisconslookup activate.cisco

    Le même processus peut être effectué pour que cisco.sipflash.x résolve le domaine :

    nslookup cisco sipflashnslookup cisco sipflash

    Si le PC ne parvient pas à résoudre les domaines, consultez votre serveur DNS.

    Dépannage de l'enregistrement d'un périphérique MPP dans WxC

    Dans cet exemple, le proxy sortant est da02.hosted-us10.bcld.webex.com. Le téléphone tente de résoudre le domaine SRV :

    1721 NOT Sep 04 22:50:32.068857 (2059-2271) voice-[SIP_resolveHostName] host=da02.hosted-us10.bcld.webex.com port=0
    1722 NOT Sep 04 22:50:32.068912 (2059-2271) voice-RSE_DEBUG: rse_unref context: 0x5213bab8
    1723 NOT Sep 04 22:50:32.068933 (2059-2271) voice-RSE_DEBUG: rse_unref ref_cnt:0
    1724 NOT Sep 04 22:50:32.068950 (2059-2271) voice-RSE_DEBUG: rse_get_server_addr, name: _sips._tcp.da02.hosted-us10.bcld.webex.com type 1 port 0 rse_index 0 first:1 fallback 0
    1725 NOT Sep 04 22:50:32.068975 (2059-2271) voice-RSE_DEBUG: rse_refresh_addr_list target:_sips._tcp.da02.hosted-us10.bcld.webex.com, rse_type:1
    1726 NOT Sep 04 22:50:32.069001 (2059-2271) voice-RSE_DEBUG: RR[0], name:_sips._tcp.da02.hosted-us10.bcld.webex.com tranport:2 type:1 status:0
    1727 INF Sep 04 22:50:32.069517 dnsmasq[560]: query[SRV] _sips._tcp.da02.hosted-us10.bcld.webex.com from 127.0.0.1
    1728 INF Sep 04 22:50:32.069549 dnsmasq[560]: forwarded _sips._tcp.da02.hosted-us10.bcld.webex.com to 192.168.100.1
    1729 INF Sep 04 22:50:32.082459 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted02aj-us10.bcld.webex.com, port=8934, prio=10, wt=50]
    1730 INF Sep 04 22:50:32.082512 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted02aj-us10.bcld.webex.com
    1731 INF Sep 04 22:50:32.082661 dnsmasq[560]: [cache_insert] _sips._tcp.da02.hosted-us10.bcld.webex.com[10208]: Mon Sep 4 22:53:52 2023
    1732 INF Sep 04 22:50:32.082689 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted02as-us10.bcld.webex.com, port=8934, prio=10, wt=50]
    1733 INF Sep 04 22:50:32.082714 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted02as-us10.bcld.webex.com
    1734 INF Sep 04 22:50:32.082738 dnsmasq[560]: [cache_insert] _sips._tcp.da02.hosted-us10.bcld.webex.com[10208]: Mon Sep 4 22:53:52 2023
    1735 INF Sep 04 22:50:32.082762 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted01as-us10.bcld.webex.com, port=8934, prio=5, wt=50]
    1736 INF Sep 04 22:50:32.082786 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted01as-us10.bcld.webex.com
    1737 INF Sep 04 22:50:32.082810 dnsmasq[560]: [cache_insert] _sips._tcp.da02.hosted-us10.bcld.webex.com[10208]: Mon Sep 4 22:53:52 2023
    1738 INF Sep 04 22:50:32.082838 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted01aj-us10.bcld.webex.com, port=8934, prio=5, wt=50]
    1739 INF Sep 04 22:50:32.082864 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted01aj-us10.bcld.webex.com
    1740 INF Sep 04 22:50:32.082888 dnsmasq[560]: [cache_insert] _sips._tcp.da02.hosted-us10.bcld.webex.com[10208]: Mon Sep 4 22:53:52 2023
    1741 INF Sep 04 22:50:32.082911 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted01ai-us10.bcld.webex.com, port=8934, prio=5, wt=50]
    1742 INF Sep 04 22:50:32.082936 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted01ai-us10.bcld.webex.com
    1743 INF Sep 04 22:50:32.082958 dnsmasq[560]: [cache_insert] _sips._tcp.da02.hosted-us10.bcld.webex.com[10208]: Mon Sep 4 22:53:52 2023
    1744 INF Sep 04 22:50:32.082981 dnsmasq[560]: caching SRV record=_sips._tcp.da02.hosted-us10.bcld.webex.com with ttl=200 [target=hosted02ai-us10.bcld.webex.com, port=8934, prio=10, wt=50]
    1745 INF Sep 04 22:50:32.083006 dnsmasq[560]: reply _sips._tcp.da02.hosted-us10.bcld.webex.com is hosted02ai-us10.bcld.webex.com

    Si le téléphone peut résoudre le domaine SRV, il obtient les noms d'hôte :

    1746 NOT Sep 04 22:50:32.082468 (2059-2271) voice-RSE_DEBUG: getting SRV:_sips._tcp.da02.hosted-us10.bcld.webex.com
    1747 NOT Sep 04 22:50:32.082525 (2059-2271) voice-RSE_DEBUG: new priority:a by host: hosted02aj-us10.bcld.webex.com
    1748 NOT Sep 04 22:50:32.082548 (2059-2271) voice-RSE_DEBUG: old priority:a by host: hosted02as-us10.bcld.webex.com
    1749 NOT Sep 04 22:50:32.082565 (2059-2271) voice-RSE_DEBUG: new priority:5 by host: hosted01as-us10.bcld.webex.com
    1750 NOT Sep 04 22:50:32.082581 (2059-2271) voice-RSE_DEBUG: old priority:5 by host: hosted01aj-us10.bcld.webex.com
    1751 NOT Sep 04 22:50:32.082598 (2059-2271) voice-RSE_DEBUG: old priority:5 by host: hosted01ai-us10.bcld.webex.com
    1752 NOT Sep 04 22:50:32.082613 (2059-2271) voice-RSE_DEBUG: old priority:a by host: hosted02ai-us10.bcld.webex.com

    À partir de l'un de ces noms d'hôte, le téléphone prend l'un d'eux pour enregistrer le périphérique sur le WxC SBC :

    1774 NOT Sep 04 22:50:32.083015 (2059-2271) voice-RSE_DEBUG: Refreshing host[3]:hosted01aj-us10.bcld.webex.com
    1775 INF Sep 04 22:50:32.083539 dnsmasq[560]: query[A] hosted01aj-us10.bcld.webex.com from 127.0.0.1
    1776 INF Sep 04 22:50:32.083567 dnsmasq[560]: found A record=hosted01aj-us10.bcld.webex.com with TTL=814
    1777 INF Sep 04 22:50:32.083590 dnsmasq[560]: cached hosted01aj-us10.bcld.webex.com is 139.177.XXX.XXX
    1778 INF Sep 04 22:50:32.083668 dnsmasq[560]: query[AAAA] hosted01aj-us10.bcld.webex.com from 127.0.0.1
    1779 INF Sep 04 22:50:32.083698 dnsmasq[560]: found A record=hosted01aj-us10.bcld.webex.com with TTL=2620
    1780 INF Sep 04 22:50:32.083723 dnsmasq[560]: cached hosted01aj-us10.bcld.webex.com is 2607:fcf0:9000:X::X
    1781 NOT Sep 04 22:50:32.084094 (2059-2271) voice-RSE_DEBUG: Refresh host:hosted01aj-us10.bcld.webex.com finished
    1782 NOT Sep 04 22:50:32.084133 (2059-2271) voice-RSE_DEBUG: rse_save_addr_list res = 0x43227cc8 af = 2
    1783 NOT Sep 04 22:50:32.084152 (2059-2271) voice-RSE_DEBUG: skip AF_INET6 addr
    1784 NOT Sep 04 22:50:32.084185 (2059-2271) voice-RSE_DEBUG: Found one old entry<4320b538> [139.177.XXX.XXX]:8934 with status:up, ttl: -1, sttl: -1, cttl:3549
    3673 NOT Sep 04 22:51:08.127871 (2656-2764) voice- =====> Send (TLS) [139.177.XXX.XXX]:8934 SIP MSG::  REGISTER sip:XXXXX.example.com SIP/2.0^M
     Via: SIP/2.0/TLS 192.168.100.6:5072;branch=z9hG4bK-c77bd320^M
     From: <sip:w3nca1a025@XXXXX.example.com>;tag=fcd8304d2abdd95co0^M
     To: <sip:w3nca1a025@XXXXX.example.com>^M
     Call-ID: 98126dba-9df06bd9@192.168.100.6^M
     CSeq: 6367 REGISTER^M
     Max-Forwards: 70^M
     Contact: <sip:w3nca1a025@192.168.100.6:5072;transport=tls>;expires=3600^M
     User-Agent: Cisco-CP-8865-3PCC/12.0.2_<MAC_ADDRESS>_47cff26a-4713-41a1-8d75-28d7b638ffe8_2c01b5e7-53d5-41a1-8d75-28d7b638ffe8^M
     Peripheral-Data: none^M
     Session-ID: 300e21a200105000a0002c01b5e753d5;remote=00000000000000000000000000000000^M
     Content-Length: 0^M
     Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE^M
     Allow-Events: hold,talk,conference^M
     Supported: replaces, sec-agree, record-aware^M
     Accept-Language: en^M
    Le périphérique doit recevoir un message 401 Unauthorized du côté WxC : 
    3857 NOT Sep 04 22:51:08.176087 (2656-2764) voice- <===== Recv (TCP) [139.177.XXX.XXX]:8934 SIP MSG:: SIP/2.0 401 Unauthorized^M
    Via:SIP/2.0/TLS 192.168.100.6:5072;received=187.190.XXX.XXX;branch=z9hG4bK-c77bd320^M
    From:<sip:w3nca1a025@XXXXX.example.com>;tag=fcd8304d2abdd95co0^M
    To:<sip:w3nca1a025@XXXXX.example.com>;tag=799618563-1693867868150^M
    Call-ID:98126dba-9df06bd9@192.168.100.6^M
    CSeq:6367 REGISTER^M
    Session-ID:d1b7e5b700804ca4a817949623258793;remote=300e21a200105000a0002c01b5e753d5^M
    WWW-Authenticate:DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXlm5h6zucT8ymkkBW",algorithm=MD5^M
    Contact:<sip:w3nca1a025@192.168.100.6:5072;transport=tls>;expires=120^M
    Content-Length:0^M
    ^M
    Le périphérique envoie l'en-tête REGISTER avec l'en-tête Authorization : 
    3863 NOT Sep 04 22:51:08.186602 (2656-2764) voice- =====> Send (TLS) [139.177.XXX.XXX]:8934 SIP MSG:: REGISTER sip:XXXXX.example.com SIP/2.0^M
    Via: SIP/2.0/TLS 192.168.100.6:5072;branch=z9hG4bK-be588fb^M
    From: <sip:w3nca1a025@XXXXX.example.com>;tag=fcd8304d2abdd95co0^M
    To: <sip:w3nca1a025@XXXXX.example.com>^M
    Call-ID: 98126dba-9df06bd9@192.168.100.6^M
    CSeq: 6368 REGISTER^M
    Max-Forwards: 70^M
    Authorization: Digest username="+1XXXXXXXXXX",realm="BroadWorks",nonce="BroadWorksXlm5h6zucT8ymkkBW",uri="sip:XXXXX.example.com",algorithm=MD5,response="0c379711174db09d2cd15b0a249c2dd4",qop=auth,nc=00000001,cnonce="97d74412"^M
    Contact: <sip:w3nca1a025@192.168.100.6:5072;transport=tls>;expires=3600^M
    User-Agent: Cisco-CP-8865-3PCC/12.0.2_<MAC_ADDRESS>_47cff26a-4713-41a1-8d75-28d7b638ffe8_2c01b5e7-53d5-41a1-8d75-28d7b638ffe8^M
    Peripheral-Data: none^M
    Session-ID: 300e21a200105000a0002c01b5e753d5;remote=d1b7e5b700804ca4a817949623258793^M
    Content-Length: 0^M
    Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE^M
    Allow-Events: hold,talk,conference^M
    Ensuite, le périphérique reçoit un SIP 200 OK : 
    4056 NOT Sep 04 22:51:08.236092 (2656-2764) voice- <===== Recv (TCP) [139.177.XXX.XXX]:8934 SIP MSG:: SIP/2.0 200 OK^M
    Via:SIP/2.0/TLS 192.168.100.6:5072;received=187.190.XXX.XXX;branch=z9hG4bK-be588fb^M
    From:<sip:w3nca1a025@XXXXX.example.com>;tag=fcd8304d2abdd95co0^M
    To:<sip:w3nca1a025@XXXXX.example.com>;tag=258864438-1693867868205^M
    Call-ID:98126dba-9df06bd9@192.168.100.6^M
    CSeq:6368 REGISTER^M
    Session-ID:d1b7e5b700804ca4a817949623258793;remote=300e21a200105000a0002c01b5e753d5^M
    Allow-Events:call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference^M
    Contact:<sip:w3nca1a025@192.168.100.6:5072;transport=tls>;q=0.5;expires=120^M
    Content-Length:0^M
    ^M
    Après ce processus, le périphérique doit être activé et enregistré auprès des services WxC.

    Dépannage de DNS (Register URLs)

    Si vous vous trouvez sur le même réseau où les périphériques rencontrent des problèmes avec la résolution DNS, la commande nslookup peut être utilisée pour vérifier si le serveur DNS est en mesure de résoudre le domaine. Ouvrez l'interface de ligne de commande et procédez comme suit :

    • nslookup -> Entrée
    • set type=SRV -> Entrée
    • _sips._tcp.da02.hosted-us10.bcld.webex.com

    Si le PC peut résoudre le domaine, il peut se présenter comme suit :

    nslookup SRV OBPnslookup SRV OBP

    Capture de paquets (processus d’enregistrement)

    Vous pouvez prendre l'adresse IP du téléphone pour l'enregistrer, un filtre peut être utilisé dans la capture de paquets pour examiner la connexion TLS :

    PCAP SSEPCAP SSE

    La capture de paquets peut aider à voir si la connexion TLS a échoué.

    Assistance TAC par téléphone Cisco Webex

    Si vous avez besoin d'aide pour analyser les journaux et trouver la cause première du problème, contactez l'équipe Cisco Webex Calling TAC.

    Informations relatives au support

    Informations de référence de port pour les appels Webex

    Historique de révision

    Révision Date de publication Commentaires
    2.0
    18-Apr-2024
    Première publication
    1.0
    04-Oct-2023
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Enrique Martinez Garcia
      Ingénieur-conseil technique

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits