Sommario

Introduzione

Requisiti

Componenti usati

Aggiungi il dispositivo in Control Hub

Breve riepilogo del processo di provisioning di un dispositivo in WxC

Risoluzione dei problemi relativi al provisioning di un dispositivo in WxC

Generare i registri PRT da un dispositivo MPP

Generazione della porta dal dispositivo

Registri porte

Risoluzione dei problemi relativi al DNS (URL di provisioning)

Risoluzione dei problemi relativi alla registrazione di un dispositivo MPP in WxC

Risoluzione dei problemi relativi a DNS (registrazione di URL)

Acquisizione pacchetti (processo di registrazione)

Cisco Webex Calling TAC Support

Informazioni correlate al supporto

Introduzione

Questo documento descrive come risolvere i problemi di provisioning e registrazione dei telefoni MPP in WxC quando il dispositivo viene aggiunto tramite indirizzo MAC.

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Conoscenze base di rete

- telefoni MPP

Componenti usati

Le informazioni di questo documento si basano solo su telefoni MPP come 78XX, 88XX.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Aggiungi il dispositivo in Control Hub

Passaggio 1. Passare a admin.webex.com e utilizzare le credenziali di amministratore. Nell'organizzazione, selezionare Dispositivi > Aggiungi dispositivo:

Scheda Dispositivi

Passaggio 2. Selezionare Uso personale da assegnare a un utente oppure selezionare Uso condiviso da assegnare a un'area di lavoro. In questo scenario viene utilizzato un utente.

Aggiungi dispositivo

Passaggio 3. Cercare e selezionare l'utente che si desidera assegnare al dispositivo e fare clic su Avanti:

Cerca un utente

Passaggio 4. Selezionare Cisco IP Phone e cercare il modello del dispositivo:

Selezionare il modello del dispositivo

Passaggio 5. Una volta selezionato il dispositivo, selezionare l'opzione By MAC Address (Per indirizzo MAC), immettere l'indirizzo MAC del dispositivo e fare clic su Save (Salva):

Aggiungi indirizzo MAC

Passaggio 6. Una volta che il dispositivo si trova in Control Hub, è possibile verificare che sia stato aggiunto correttamente quando si cerca l'indirizzo MAC nella barra di ricerca:

Verifica del dispositivo

Lo stato viene visualizzato come "Non disponibile" poiché il dispositivo non è ancora stato predisposto. Una volta che il dispositivo si trova nell'hub di controllo, il passaggio successivo consiste nel ripristinare il dispositivo. Dopo il reset di fabbrica, il dispositivo deve fare una richiesta ai server WxC per ottenere i file di configurazione. (Questo è il processo di provisioning). Il provisioning del dispositivo è stato eseguito correttamente quando il dispositivo visualizza il numero di telefono e/o l'interno sullo schermo.

Se la configurazione del dispositivo non è corretta, il processo di provisioning del dispositivo non è riuscito.

Breve riepilogo del processo di provisioning di un dispositivo in WxC

Diagramma di provisioning

Risoluzione dei problemi relativi al provisioning di un dispositivo in WxC

Il dispositivo MPP non può effettuare il provisioning con WxC se è configurato con:

- Un server TFTP configurato nel server DHCP

- Se l'opzione (OPT66, OPT160, OPT159 o OPT150) è configurata e fornita dal server DHCP

Per vedere se il telefono ha preso una configurazione TFTP da un server DHCP, sono necessari i registri PRT.

Generare i registri PRT da un dispositivo MPP

Inoltrare dal registro PRT dal telefono. La procedura riportata di seguito illustra come generare i registri PRT.

Generazione della porta dal dispositivo

Passaggio 1. Sul dispositivo, premere il pulsante Applicazioni

Impostazioni

.

Passaggio 2. Andare a Stato > Segnala problema.

Passaggio 3. Inserire la data e l'ora del problema.

Passaggio 4. Selezionare una descrizione dall'elenco.

Passaggio 5.Premere Submit (Invia).

Una volta inviati i log, vedere la procedura seguente per scaricare i log della PRT:

Passaggio 1. Accedi a https://IP_ADDRESS_PHONE/

Nota: se l'indirizzo IP è sconosciuto, è possibile ottenerlo da Settings > Status > Network Status > IPv4 Status

Passaggio 2. Selezionare Info > Debug Info > Download del registro PRT (fare clic con il pulsante destro del mouse sul collegamento e selezionare Salva con nome...)

GUI Web

Registri porte

Quando si aprono i registri, è possibile visualizzare una visualizzazione simile alla seguente:

Nota: è possibile aprire i registri con un programma come WinRAR poiché i registri sono compressi.

Vista log della porta

Per analizzare il processo di provisioning del dispositivo, è necessario aprire il registro logcat. Può essere aperto con un editor di testo come Blocco note o Blocco note+.

La funzione "Find" (Trova) dell'editor di testo può essere usata per verificare se il telefono ha un server TFTP configurato. Utilizzare DHCP-tftpsvr1 o DHCP-tftpsvr2 per trovare la riga specifica del registro. Se si esaminano le altre righe dei log, è possibile trovare ulteriori informazioni sulla configurazione 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:

Come si può vedere nel registro, sul server DHCP è configurato un indirizzo IP TFTP. Per questo motivo, il telefono ha tentato di effettuare il provisioning su questo server TFTP invece che sui server 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.

Dopo aver rimosso tutte le configurazioni TFTP e OPT dal server DHCP, è necessario reimpostare il dispositivo per avviare il processo di provisioning del dispositivo con WxC di nuovo.

Il primo tentativo del telefono di eseguire il provisioning del dispositivo consiste nel inviare una richiesta all'URL activate.cisco.com. Il telefono effettua una query sul server DNS per risolvere il dominio. Se la risoluzione DNS ha esito negativo, è possibile che il risultato sia il seguente:

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

Se il telefono può risolvere il dominio, può avere il seguente aspetto:

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

Dopo aver ricevuto il messaggio 200 OK dalla richiesta GET a activate.cisco.com, il telefono invia una richiesta a cisco.siplash.com. È lo stesso processo, il telefono tenta di risolvere il dominio e se non funziona può avere questo aspetto:

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"

Se il telefono può risolvere il dominio, può avere il seguente aspetto:

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

Risoluzione dei problemi relativi al DNS (URL di provisioning)

Se ci si trova nella stessa rete in cui i dispositivi hanno problemi con la risoluzione DNS, è possibile utilizzare nslookup per verificare se il server DNS è in grado di risolvere il dominio. Aprire l'interfaccia della riga di comando ed eseguire la procedura seguente:

- nslookup -> Invio

- set type=A -> Invio

- activate.cisco.com

Se il PC è in grado di risolvere il dominio, è possibile che l'aspetto sia il seguente:

nslookup attivazione.cisco

Lo stesso processo può essere eseguito per cisco.sipflash.x per risolvere il dominio:

nslookup cisco sipflash

Se il PC non è in grado di risolvere i domini, controllare il server DNS.

Risoluzione dei problemi relativi alla registrazione di un dispositivo MPP in WxC

Per questo esempio, il proxy in uscita è da02.hosted-us10.bcld.webex.com. Il telefono tenta di risolvere il dominio 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

Se il telefono è in grado di risolvere il dominio SRV, ottiene i nomi host:

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

Da uno di questi hostname il telefono prende uno di loro per registrare il dispositivo al 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

Il dispositivo deve ricevere un messaggio 401 Unauthorized dal lato 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

Il dispositivo invia il comando REGISTER con l'intestazione 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

E poi, il dispositivo ottiene 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

Al termine di questa procedura, il dispositivo deve essere attivo e registrato nei servizi WxC.

Risoluzione dei problemi relativi a DNS (registrazione di URL)

Se ci si trova nella stessa rete in cui i dispositivi hanno problemi con la risoluzione DNS, è possibile utilizzare nslookup per verificare se il server DNS è in grado di risolvere il dominio. Aprire l'interfaccia della riga di comando ed eseguire la procedura seguente:

- nslookup -> Invio

- set type=SRV -> Invio

- _sips._tcp.da02.hosted-us10.bcld.webex.com

Se il PC è in grado di risolvere il dominio, è possibile che abbia il seguente aspetto:

OBP SRV nslookup

Acquisizione pacchetti (processo di registrazione)

Si può prendere l'indirizzo IP che il telefono ha per la registrazione, un filtro può essere usato nell'acquisizione del pacchetto per guardare l'handshake TLS:

SSE PCAP

L'acquisizione del pacchetto può essere utile per verificare se l'handshake TLS ha avuto esito negativo.

Cisco Webex Calling TAC Support

Se è necessario supporto per analizzare i registri e trovare la causa principale del problema, contattare il team Cisco Webex Calling TAC.

Informazioni correlate al supporto

Informazioni di riferimento sulla porta per Webex Calling