Identificar e solucionar problemas do telefone MPP em WxC para provisionamento e registro

Atualizado:18 de abril de 2024
ID do documento:221021

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

    Introdução

    Este documento descreve como solucionar problemas de telefones MPP em WxC para problemas de provisionamento e registro quando o dispositivo é adicionado pelo endereço MAC.

    Requisitos

    A Cisco recomenda que você tenha conhecimento destes tópicos:

    • Conhecimento básico de rede
    • Telefones MPP

    Componentes Utilizados

    As informações neste documento são baseadas apenas em telefones MPP como 78XX, 88XX.

    As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

    Adicionar o Dispositivo ao Hub de Controle

    Etapa 1. Navegue até admin.webex.com e use as credenciais de administrador. Na organização, navegue até Devices > Add device:

    guia Dispositivosguia Dispositivos

    Etapa 2. Selecione Uso pessoal a ser atribuído a um usuário ou selecione Uso compartilhado a ser atribuído a um espaço de trabalho. (Neste cenário, um usuário é usado.)

    Adicionar dispositivoAdicionar dispositivo

    Etapa 3. Pesquise e selecione o usuário que você deseja atribuir a este dispositivo e clique em Avançar:

    Procurar um usuárioProcurar um usuário

    Etapa 4. Selecione Cisco IP Phone e procure o modelo do seu dispositivo:

    Selecionar modelo do dispositivoSelecionar modelo do dispositivo

    Etapa 5. Depois que o dispositivo for selecionado, selecione a opção By MAC Address, insira o endereço MAC do dispositivo e clique em Save:

    Adicionar endereço MACAdicionar endereço MAC

    Etapa 6. Quando o dispositivo estiver no Hub de controle, você poderá verificar se ele foi adicionado corretamente ao pesquisar o endereço MAC na barra de pesquisa:

    Verificação do dispositivoVerificação do dispositivo

    O status é mostrado como "Indisponível", pois o dispositivo ainda não foi provisionado. Quando o dispositivo estiver no Hub de controle, a próxima etapa será redefinir o dispositivo de fábrica. Após a redefinição de fábrica, o dispositivo deve fazer uma solicitação aos servidores WxC para obter arquivos de configuração. (Esse é o processo de provisão.) O dispositivo é provisionado com êxito quando o dispositivo exibe o número do telefone e/ou o ramal na tela.

    Se você vir que o dispositivo não está mostrando a configuração adequada, o processo para provisionar o dispositivo falhou.

    Breve resumo do processo de provisionamento de um dispositivo em WxC

    Diagrama de provisionamentoDiagrama de provisionamento

    Solucionar problemas do processo de provisionamento de um dispositivo em WxC

    O dispositivo MPP não pode provisionar com WxC se estiver configurado com:

    • Um servidor TFTP configurado no servidor DHCP
    • Se a Opção (OPT66, OPT160, OPT159 ou OPT150) for configurada e fornecida pelo Servidor DHCP

    Para ver se o telefone obteve uma configuração TFTP de um servidor DHCP, os registros PRT são necessários.

    Gerar os logs de PRT a partir de um dispositivo MPP

    Envie os registros da PRT pelo telefone. As próximas etapas mostram como gerar os registros PRT.

    Gere a PRT a partir do dispositivo

    Etapa 1.No dispositivo, pressione o botão Applicationsbutton Botão ConfiguraçõesSettings .

    Etapa 2.Vá paraStatus > Relatar problema.

    Etapa 3.Insira a data e a hora do problema.

    Etapa 4.Selecione uma Descrição na lista.

    Etapa 5.Pressione Enviar. 

    Depois que os registros forem enviados, consulte as próximas etapas para fazer o download dos registros PRT:

    Etapa 1. Faça login em https://IP_ADDRESS_PHONE/

    note-icon

    Observação: Observação: se o endereço IP for desconhecido, ele poderá ser obtido em Settings > Status > Network Status > IPv4 Status

    Etapa 2. Navegue até Info > Debug Info > Download do registro PRT (Clique com o botão direito do mouse no link e selecione Save As...)

    GUI da WebGUI da Web

    Logs PRT

    Ao abrir os logs, você poderá ver uma exibição como esta:
    note-icon

    Observação: você pode abrir os logs com um programa como o WinRAR, já que os logs estão compactados.

    Visualização do registro PRTVisualização do registro PRT
    Para analisar o processo de provisionamento do dispositivo, o log chamado logcat precisa ser aberto. Ele pode ser aberto com um editor de texto como Notepad ou Notepad++.
    A função "Localizar" do editor de texto pode ser usada para descobrir se o telefone tem um servidor TFTP configurado. Use DHCP-tftpsvr1 ou DHCP-tftpsvr2 para encontrar a linha específica para esse log. Se você observar as outras linhas dos logs, poderá encontrar mais informações sobre a configuração do 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:
    Como você pode ver no registro, um endereço IP TFTP é configurado no servidor DHCP. Isso faz com que o telefone tente provisionar para esse servidor TFTP em vez dos servidores de chamada Webex. 
    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.
    Após remover qualquer configuração TFTP e qualquer configuração OPT do servidor DHCP, você deve redefinir o dispositivo de fábrica para iniciar o processo para provisionar o dispositivo com WxC novamente.
    A primeira tentativa que o telefone faz com o processo de provisionamento do dispositivo é fazer uma solicitação ao URL activate.cisco.com. O telefone consulta o servidor DNS para resolver o domínio. Se a Resolução DNS falhar, pode ser assim: 
    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 o telefone puder resolver o domínio, ele poderá ter a seguinte aparência: 
    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
    Após receber o 200 OK da solicitação GET para activate.cisco.com, o telefone faz uma solicitação para cisco.siplash.com. É o mesmo processo, o telefone tenta resolver o domínio e, se falhar, pode ter a seguinte aparência: 
    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 o telefone puder resolver o domínio, ele poderá ter a seguinte aparência:

    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

    Solucionar problemas de DNS (Provisione URLs)

    Se você estiver na mesma rede em que os dispositivos têm problemas com a resolução DNS, um nslookup pode ser usado para verificar se o servidor DNS é capaz de resolver o domínio. Abra a interface de linha de comando e siga os próximos passos:

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

    Se o PC puder resolver o domínio, ele poderá ter esta aparência:

    nslookup ativate.cisconslookup ativate.cisco

    O mesmo processo pode ser feito para cisco.sipflash.x para resolver o domínio:

    nslookup cisco sipflashnslookup cisco sipflash

    Se o computador não puder resolver os domínios, consulte o servidor DNS.

    Solucionar problemas de registro de um dispositivo MPP em WxC

    Para este exemplo, o proxy de saída é da02.hosted-us10.bcld.webex.com. O telefone tenta resolver o domínio 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 o telefone puder resolver o domínio SRV, ele obterá os nomes de 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

    A partir de um desses nomes de host, o telefone leva um deles para registrar o dispositivo de para o 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
    O dispositivo deve receber uma mensagem 401 Unauthorized do lado 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
    O dispositivo envia o REGISTER com o cabeçalho de autorização: 
    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 então, o dispositivo recebe um 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
    Após esse processo, o dispositivo deve estar ativo e registrado nos serviços WxC.

    Solucionar problemas de DNS (Registrar URLs)

    Se você estiver na mesma rede em que os dispositivos têm problemas com a resolução DNS, o nslookup pode ser usado para verificar se o servidor DNS é capaz de resolver o domínio. Abra a interface de linha de comando e siga os próximos passos:

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

    Se o PC puder resolver o domínio, ele poderá ter esta aparência:

    nslookup SRV OBPnslookup SRV OBP

    Captura de pacotes (processo de registro)

    Você pode pegar o endereço IP que o telefone tem para registro, um filtro pode ser usado na captura de pacotes para examinar o handshake TLS:

    PCAP SSEPCAP SSE

    A captura de pacotes pode ajudar para ver se o handshake TLS falhou.

    Suporte do Cisco Webex Calling TAC

    Se precisar de suporte para analisar os registros e encontrar a causa raiz do problema, entre em contato com a equipe do TAC do Cisco Webex Calling.

    Informações relacionadas ao suporte

    Informações de referência de porta para chamada Webex

    Histórico de revisões

    Revisão Data de publicação Comentários
    2.0
    18-Apr-2024
    Versão inicial
    1.0
    04-Oct-2023
    Versão inicial
    TAC Authored

    Colaborado por engenheiros da Cisco

    • Enrique Martinez Garcia
      Engenheiro de consultoria técnica

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos