Solución de problemas del teléfono MPP en WxC para aprovisionamiento y registro

Actualizado:18 de abril de 2024
ID del documento:221021

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

    Introducción

    Este documento describe cómo resolver problemas de teléfonos MPP en WxC por problemas de aprovisionamiento y registro cuando el dispositivo es agregado por la dirección MAC.

    Requirements

    Cisco recomienda que tenga conocimiento sobre estos temas:

    • Conocimiento básico de la red
    • Teléfonos MPP

    Componentes Utilizados

    La información de este documento se basa solamente en teléfonos MPP como 78XX, 88XX.

    La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

    Agregar el dispositivo en el concentrador de control

    Paso 1. Vaya a admin.webex.com y utilice las credenciales de administrador. En la organización, vaya a Dispositivos > Agregar dispositivo:

    Ficha DispositivosFicha Dispositivos

    Paso 2. Seleccione Uso personal para asignar a un usuario o Uso compartido para asignar a un espacio de trabajo. (En este escenario se utiliza un usuario.)

    Agregar dispositivoAgregar dispositivo

    Paso 3. Busque y seleccione el usuario que desea asignar a este dispositivo y haga clic en Next:

    Buscar un usuarioBuscar un usuario

    Paso 4. Seleccione Cisco IP Phone y busque el modelo de dispositivo:

    Seleccionar modelo de dispositivoSeleccionar modelo de dispositivo

    Paso 5. Una vez seleccionado el dispositivo, seleccione la opción By MAC Address e introduzca la dirección MAC del dispositivo y haga clic en Save:

    Agregar dirección MACAgregar dirección MAC

    Paso 6. Una vez que el dispositivo está en el concentrador de control, puede verificar que se agregó correctamente cuando busca la dirección MAC en la barra de búsqueda:

    Verificación del dispositivoVerificación del dispositivo

    El estado se muestra como "No disponible", ya que el dispositivo sigue sin estar aprovisionado. Una vez que el dispositivo está en el concentrador de control, el siguiente paso es restablecer de fábrica el dispositivo. Después del restablecimiento de fábrica, el dispositivo debe realizar una solicitud a los servidores WxC para obtener los archivos de configuración. (Ese es el proceso de provisión.) El dispositivo se suministra correctamente cuando muestra el número de teléfono o la extensión en la pantalla.

    Si observa que el dispositivo no muestra la configuración correcta, el proceso de aprovisionamiento del dispositivo ha fallado.

    Breve resumen del proceso para aprovisionar un dispositivo en WxC

    Diagrama de aprovisionamientoDiagrama de aprovisionamiento

    Resolución de problemas del proceso de aprovisionamiento de dispositivos en WxC

    El dispositivo MPP no se puede aprovisionar con WxC si está configurado con:

    • Un servidor TFTP configurado en el servidor DHCP
    • Si el servidor DHCP configura y proporciona la opción (OPT66, OPT160, OPT159 u OPT150)

    Para ver si el teléfono tomó una configuración TFTP de un servidor DHCP, se necesitan los registros PRT.

    Generar los registros PRT desde un dispositivo MPP

    Envíe los registros PRT desde el teléfono. Los siguientes pasos muestran cómo generar los registros PRT.

    Generar el PRT desde el dispositivo

    Paso 1.En el dispositivo, presione el botón Aplicacionesbotón Botón ConfiguraciónSettings .

    Paso 2.Vaya a Estado > Informe de problemas.

    Paso 3.Introduzca la fecha y la hora del problema.

    Paso 4.Seleccione una descripción de la lista.

    Paso 5.Pulse Enviar. 

    Una vez enviados los registros, consulte los siguientes pasos para descargar los registros PRT:

    Paso 1. Inicie sesión en https://IP_ADDRESS_PHONE/

    icono de nota

    Nota: Si la dirección IP es desconocida, puede obtenerse en Settings > Status > Network Status > IPv4 Status (Configuración > Estado > Estado de red > Estado de IPv4)

    Paso 2. Vaya a Info > Debug Info > Descargue el registro PRT (Haga clic con el botón derecho en el enlace y seleccione Save As...)

    GUI webGUI web

    registros PRT

    Al abrir los registros, puede ver una vista como esta:
    icono de nota

    Nota: Puede abrir los registros con un programa como WinRAR ya que los registros están comprimidos.

    Vista de registro PRTVista de registro PRT
    Para analizar el proceso de aprovisionamiento del dispositivo, es necesario abrir el registro denominado logcat. Se puede abrir con un editor de texto como Notepad o Notepad++.
    La función "Find" del editor de texto se puede utilizar para averiguar si el teléfono tiene un servidor TFTP configurado. Utilice DHCP-tftpsvr1 o DHCP-tftpsvr2 para buscar la línea específica para ese registro. Si echa un vistazo a las otras líneas de los registros, puede encontrar más información sobre la configuración 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 puede ver en el registro, se configura una dirección IP TFTP en el servidor DHCP. Esto provocó que el teléfono intentara aprovisionarse a este servidor TFTP en lugar de a los servidores de llamada 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.
    Después de quitar cualquier configuración TFTP y cualquier configuración OPT del servidor DHCP, debe restablecer de fábrica el dispositivo para iniciar el proceso para aprovisionar el dispositivo con WxC nuevamente.
    El primer intento que realiza el teléfono con el proceso de aprovisionamiento del dispositivo es realizar una solicitud a la dirección URL activate.cisco.com. El teléfono realiza una consulta al servidor DNS para resolver el dominio. Si la resolución DNS falla, puede verse de la siguiente manera: 
    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 el teléfono puede resolver el dominio, puede verse de la siguiente manera: 
    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
    Después de recibir el 200 OK de la solicitud GET a activate.cisco.com, el teléfono realiza una solicitud a cisco.siplash.com. Es el mismo proceso, el teléfono intenta resolver el dominio y si falla puede verse así: 
    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 el teléfono puede resolver el dominio, puede verse de la siguiente manera:

    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

    Solución de problemas de DNS (aprovisionamiento de URL)

    Si se encuentra en la misma red en la que los dispositivos tienen problemas con la resolución DNS, se puede utilizar nslookup para comprobar si el servidor DNS puede resolver el dominio. Abra la interfaz de línea de comandos y realice los siguientes pasos:

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

    Si el PC puede resolver el dominio, puede verse de la siguiente manera:

    nslookup activate.cisconslookup activate.cisco

    Se puede realizar el mismo proceso para que cisco.sipflash.x resuelva el dominio:

    nslookup cisco sipflashnslookup cisco sipflash

    Si el equipo no puede resolver los dominios, consulte el servidor DNS.

    Solucionar problemas de registro de un dispositivo MPP en WxC

    Para este ejemplo, el proxy saliente es da02.hosted-us10.bcld.webex.com. El teléfono intenta resolver el 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

    Si el teléfono puede resolver el dominio SRV, obtiene los nombres 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

    De uno de esos nombres de host, el teléfono toma uno de ellos para registrar el dispositivo en el SBC WxC:

    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
    El dispositivo debe recibir un mensaje 401 Unauthorized del 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
    El dispositivo envía el mensaje REGISTER con el encabezado 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
    Y luego, el dispositivo obtiene 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
    Después de este proceso, el dispositivo debe estar activo y registrado en los servicios WxC.

    Solucionar problemas de DNS (registrar URL)

    Si se encuentra en la misma red en la que los dispositivos tienen problemas con la resolución DNS, nslookup se puede utilizar para comprobar si el servidor DNS puede resolver el dominio. Abra la interfaz de línea de comandos y realice los siguientes pasos:

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

    Si el PC puede resolver el dominio, puede verse de la siguiente manera:

    nslookup SRV OBPnslookup SRV OBP

    Captura de paquetes (proceso de registro)

    Puede tomar la dirección IP que el teléfono tiene para registrarse, un filtro se puede utilizar en la captura de paquetes para observar el intercambio de señales TLS:

    PCAP SSEPCAP SSE

    La captura de paquetes puede ayudar para ver si el intercambio de señales TLS falló.

    Cisco Webex llamando al soporte del TAC

    Si necesita asistencia para analizar los registros y encontrar la causa raíz del problema, póngase en contacto con el equipo del TAC de Cisco Webex Calling.

    Información relacionada con el soporte

    Información de referencia de puerto para llamadas Webex

    Historial de revisiones

    Revisión Fecha de publicación Comentarios
    2.0
    18-Apr-2024
    Versión inicial
    1.0
    04-Oct-2023
    Versión inicial
    TAC Authored

    Con la colaboración de ingenieros de Cisco

    • Enrique Martinez Garcia
      Technical Consulting Engineer

    ¿Resultó útil este documento?

    FeedbackComentarios

    Contacte a Cisco

    Este documento se aplica a estos productos