Fehlerbehebung beim MPP-Telefon in WxC für Bereitstellung und Registrierung

Download-Optionen

  • PDF     (1.9 MB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (1.8 MB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (1.1 MB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:18. April 2024
Dokument-ID:221021

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

    Einleitung

    Dieses Dokument beschreibt die Fehlerbehebung bei MPP-Telefonen in WxC für Bereitstellungs- und Registrierungsprobleme, wenn das Gerät über die MAC-Adresse hinzugefügt wird.

    Anforderungen

    Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

    • Grundlegendes Netzwerkwissen
    • MPP-Telefon

    Verwendete Komponenten

    Die Informationen in diesem Dokument basieren nur auf MPP-Telefonen wie 78XX, 88XX.

    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.

    Gerät im Control Hub hinzufügen

    Schritt 1: Navigieren Sie zu admin.webex.com, und verwenden Sie die Administrator-Anmeldeinformationen. Navigieren Sie in der Organisation zu Geräte > Gerät hinzufügen:

    Registerkarte GeräteRegisterkarte Geräte

    Schritt 2: Wählen Sie Persönliche Nutzung, die einem Benutzer zugewiesen werden soll, oder Freigegebene Nutzung, die einem Arbeitsbereich zugewiesen werden soll. (In diesem Szenario wird ein Benutzer verwendet.)

    Gerät hinzufügenGerät hinzufügen

    Schritt 3: Suchen Sie den Benutzer, den Sie diesem Gerät zuweisen möchten, und klicken Sie auf Weiter:

    Nach einem Benutzer suchenNach einem Benutzer suchen

    Schritt 4: Wählen Sie Cisco IP-Telefon aus, und suchen Sie nach dem gewünschten Gerätemodell:

    Gerätemodell auswählenGerätemodell auswählen

    Schritt 5: Wählen Sie nach Auswahl des Geräts die Option Nach MAC-Adresse aus, geben Sie die MAC-Adresse des Geräts ein, und klicken Sie auf Speichern:

    MAC-Adresse hinzufügenMAC-Adresse hinzufügen

    Schritt 6: Sobald sich das Gerät im Control Hub befindet, können Sie überprüfen, ob es korrekt hinzugefügt wurde, wenn Sie die MAC-Adresse in der Suchleiste durchsuchen:

    Überprüfung des GerätsÜberprüfung des Geräts

    Der Status wird als "Nicht verfügbar" angezeigt, da das Gerät noch immer nicht bereitgestellt ist. Sobald sich das Gerät im Control Hub befindet, wird es im nächsten Schritt auf die Werkseinstellungen zurückgesetzt. Nach dem Zurücksetzen auf die Werkseinstellungen muss das Gerät eine Anforderung an die WxC-Server senden, um Konfigurationsdateien abzurufen. (Das ist der Bereitstellungsprozess.) Das Gerät wird erfolgreich bereitgestellt, wenn die Telefonnummer und/oder die Durchwahl auf dem Bildschirm angezeigt wird.

    Wenn Sie feststellen, dass auf dem Gerät nicht die richtige Konfiguration angezeigt wird, ist der Bereitstellungsprozess für das Gerät fehlgeschlagen.

    Kurze Zusammenfassung des Prozesses zur Bereitstellung eines Geräts in WxC

    BereitstellungsdiagrammBereitstellungsdiagramm

    Fehlerbehebung beim Bereitstellen eines Geräts in WxC

    Das MPP-Gerät kann WxC nicht bereitstellen, wenn es wie folgt konfiguriert ist:

    • Ein im DHCP-Server konfigurierter TFTP-Server
    • Wenn Option (OPT66, OPT160, OPT159 oder OPT150) vom DHCP-Server konfiguriert und bereitgestellt wird

    Um festzustellen, ob das Telefon eine TFTP-Konfiguration von einem DHCP-Server übernommen hat, sind die PRT-Protokolle erforderlich.

    PRT-Protokolle von einem MPP-Gerät generieren

    Senden Sie die PRT-Protokolle vom Telefon. Die nächsten Schritte zeigen, wie die PRT-Protokolle generiert werden.

    PRT vom Gerät generieren

    Schritt 1.Drücken Sie auf dem Gerät die Anwendungstaste EinstellungstasteEinstellungen .

    Schritt 2:Gehe zu Status > Problem melden.

    Schritt 3: Geben Sie Datum und Uhrzeit des Problems ein.

    Schritt 4.Wählen Sie eine Beschreibung aus der Liste aus.

    Schritt 5.Drücken Sie Senden. 

    Wenn die Protokolle eingesendet wurden, sehen Sie sich die folgenden Schritte zum Herunterladen der PRT-Protokolle an:

    Schritt 1: Melden Sie sich an unter https://IP_ADDRESS_PHONE/

    note-icon

    Hinweis: Hinweis: Wenn die IP-Adresse unbekannt ist, finden Sie sie unter Einstellungen > Status > Network Status > IPv4 Status.

    Schritt 2: Navigieren Sie zu Info > Debug Info > Laden Sie das PRT-Protokoll herunter (klicken Sie mit der rechten Maustaste auf den Link, und wählen Sie Save As...)

    WeboberflächeWeboberfläche

    PRT-Protokolle

    Wenn Sie die Protokolle öffnen, sehen Sie eine Ansicht wie diese:
    note-icon

    Hinweis: Sie können die Protokolle mit einem Programm wie WinRAR öffnen, da die Protokolle komprimiert sind.

    PRT-ProtokollansichtPRT-Protokollansicht
    Um den Bereitstellungsprozess für das Gerät zu analysieren, muss das Protokoll " logcat" geöffnet werden. Es kann mit einem Texteditor wie Notepad oder Notepad++ geöffnet werden.
    Mit der Funktion "Suchen" im Texteditor kann ermittelt werden, ob auf dem Telefon ein TFTP-Server konfiguriert ist. Verwenden Sie DHCP-tftpsvr1 oder DHCP-tftpsvr2, um die spezifische Zeile für dieses Protokoll zu finden. Wenn Sie einen Blick und die anderen Zeilen der Protokolle werfen, finden Sie weitere Informationen zur DHCP-Konfiguration: 
    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:
    Wie Sie im Protokoll sehen können, wird im DHCP-Server eine TFTP-IP-Adresse konfiguriert. Aus diesem Grund hat das Telefon versucht, eine Bereitstellung auf diesem TFTP-Server anstelle der WebEx Calling Server vorzunehmen. 
    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.
    Nachdem Sie eine TFTP- und eine OPT-Konfiguration vom DHCP-Server entfernt haben, müssen Sie das Gerät auf die Werkseinstellungen zurücksetzen, um den Bereitstellungsprozess für das Gerät mit WxC erneut zu starten.
    Der erste Versuch, den das Telefon mit dem Bereitstellungsprozess für das Gerät unternimmt, besteht darin, eine Anforderung an die URL activate.cisco.com zu senden. Das Telefon fragt den DNS-Server ab, um die Domäne aufzulösen. Wenn die DNS-Auflösung fehlschlägt, kann sie wie folgt aussehen: 
    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
    Wenn das Telefon die Domäne auflösen kann, kann es wie folgt aussehen: 
    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
    Nachdem das Telefon die 200 OK von der GET-Anfrage an activate.cisco.com erhalten hat, sendet es eine Anfrage an cisco.siplash.com. Es ist der gleiche Prozess, das Telefon versucht, die Domain aufzulösen und wenn es scheitert, kann es so aussehen: 
    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"

    Wenn das Telefon die Domäne auflösen kann, kann es wie folgt aussehen:

    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

    Fehlerbehebung-DNS (Bereitstellung von URLs)

    Wenn Sie sich in demselben Netzwerk befinden, in dem die Geräte Probleme mit der DNS-Auflösung haben, kann ein nslookup verwendet werden, um zu überprüfen, ob der DNS-Server in der Lage ist, die Domäne aufzulösen. Öffnen Sie die Befehlszeilenschnittstelle, und führen Sie die folgenden Schritte aus:

    • nslookup -> Eingabe
    • set type=A -> Eingabe
    • activate.cisco.com

    Wenn der PC die Domäne auflösen kann, sieht er wie folgt aus:

    nslookup activate.cisconslookup activate.cisco

    Derselbe Prozess kann für cisco.sipflash.x durchgeführt werden, um die Domäne aufzulösen:

    nslookup cisco sipflashnslookup cisco sipflash

    Wenn der PC die Domänen nicht auflösen kann, überprüfen Sie Ihren DNS-Server.

    Fehlerbehebung bei der Registrierung für ein MPP-Gerät in WxC

    In diesem Beispiel lautet der ausgehende Proxy da02.hosted-us10.bcld.webex.com. Das Telefon versucht, die SRV-Domäne aufzulösen:

    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

    Wenn das Telefon die SRV-Domäne auflösen kann, werden die Hostnamen abgerufen:

    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

    Von einem dieser Hostnamen führt das Telefon einen von ihnen, um sich für den WxC-SBC zu registrieren:

    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
    Das Gerät muss eine 401 Unauthorized-Meldung von der WxC-Seite erhalten: 
    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
    Das Gerät sendet REGISTER mit dem Autorisierungs-Header: 
    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
    Und dann bekommt das Gerät einen 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
    Anschließend muss das Gerät bei den WxC-Services registriert und aktiviert werden.

    Fehlerbehebung bei DNS (URLs registrieren)

    Wenn Sie sich in demselben Netzwerk befinden, in dem die Geräte Probleme mit der DNS-Auflösung haben, kann nslookup verwendet werden, um zu überprüfen, ob der DNS-Server in der Lage ist, die Domäne aufzulösen. Öffnen Sie die Befehlszeilenschnittstelle, und führen Sie die folgenden Schritte aus:

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

    Wenn der PC in der Lage ist, die Domäne aufzulösen, kann dies folgendermaßen aussehen:

    nslookup SRV OBPnslookup SRV OBP

    Paketerfassung (Registrierungsprozess)

    Sie können die IP-Adresse des Telefons für die Registrierung verwenden. Ein Filter kann bei der Paketerfassung verwendet werden, um den TLS-Handshake zu untersuchen:

    PCAP-SSEPCAP-SSE

    Die Paketerfassung kann dabei helfen, festzustellen, ob der TLS-Handshake fehlgeschlagen ist.

    Cisco WebEx TAC-Support

    Wenn Sie Unterstützung benötigen, um die Protokolle zu analysieren und die Ursache des Problems zu finden, wenden Sie sich an das Cisco Webex Calling TAC-Team.

    Support-bezogene Informationen

    Port-Referenzinformationen für WebEx Anrufe

    Revisionsverlauf

    Überarbeitung Veröffentlichungsdatum Kommentare
    2.0
    18-Apr-2024
    Erstveröffentlichung
    1.0
    04-Oct-2023
    Erstveröffentlichung
    TAC Authored

    Beiträge von Cisco Ingenieuren

    • Enrique Martinez Garcia
      Technical Consulting Engineer

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren

    Dieses Dokument gilt für folgende Produkte.