Troubleshoot MPP Phone in WxC for Provision and Registration

Available Languages

Download Options

  • PDF     (1.6 MB)
    View with Adobe Reader on a variety of devices
  • ePub     (1.8 MB)
    View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle)     (1.1 MB)
    View on Kindle device or Kindle app on multiple devices
Updated:April 18, 2024
Document ID:221021

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

    Introduction

    This document describes how to troubleshoot MPP phones in WxC for provision and registration issues when the device is added by MAC Address.

    Requirements

    Cisco recommends that you have knowledge of these topics:

    • Basic Network knowledge
    • MPP phones

    Components Used

    The information in this document is based only on MPP Phones such as 78XX, 88XX.

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

    Add the Device in Control Hub

    Step 1. Navigate to admin.webex.com and use the admin credentials. In the organization, navigate to Devices > Add device:

    Devices tabDevices tab

    Step 2. Select Personal usage to be assigned to a user or select Shared Usage to be assigned for a workspace. (In this scenario a user is used.)

    Add deviceAdd device

    Step 3. Search and select the user that you want to assign to this device and click on Next:

    Search for a userSearch for a user

    Step 4. Select Cisco IP Phone and search for your device model:

    Select model of deviceSelect model of device

    Step 5. Once the device is selected, select the option By MAC Address and enter the MAC Address of the device and click Save:

    Add MAC AddressAdd MAC Address

    Step 6. Once the device is in Control Hub, you can verify that was added correctly when you search the MAC Address in the search bar:

    Verification of deviceVerification of device

    The status shows as "Unavailable" since the device is still not provisioned. Once the device is in Control Hub, the next step is to factory reset the device. After the factory reset, the device must make a request to the WxC servers to get config files. (That is the provision process.) The device is provisioned successfully when the device displays the phone number and/or the extension in the screen.

    If you see that the device is not showing the proper configuration, the process for provision the device failed.

    Brief Summary of the Process for Provision a Device in WxC

    Provisioning diagramProvisioning diagram

    Troubleshoot the process for Provision a Device in WxC

    The MPP device can not provision with WxC if it is configured with:

    • A TFTP server configured in the DHCP server
    • If Option (OPT66, OPT160, OPT159 or OPT150) is configured and provided by the DHCP Server

    To see if the phone took a TFTP configuration from a DHCP server, the PRT logs are needed.

    Genereate the PRT logs from an MPP device

    Submit from the PRT logs from the phone. The next steps shows how to generate the PRT logs.

    Generate the PRT from the Device

    Step 1.On the device, press theApplicationsbutton Settings buttonSettings button .

    Step 2.Go toStatus > Report Problem.

    Step 3.Enter Date and Time of the problem.

    Step 4.Select a Description from the list.

    Step 5.PressSubmit. 

    Once the logs are submitted, see the next steps to download the PRT logs:

    Step 1. Login to https://IP_ADDRESS_PHONE/

    note-icon

    Note: Note: If the IP Address is unknown, it can be obtained from Settings > Status > Network Status > IPv4 Status

    Step 2. Navigate to Info > Debug Info > Download the PRT log (Right click on the link and select Save As...)

    Web GUIWeb GUI

    PRT logs

    When you open the logs, you can see a view like this:
    note-icon

    Note: You can open the logs with a program like WinRAR since the logs are compressed.

    PRT Log viewPRT Log view
    In order to analyze the process for provision the device, the log called logcat needs to be opened. It can be opened with a text editor like Notepad or Notepad++.
    The function "Find" from the text editor can be used in order to find if the phone has an TFTP server configured. Use DHCP-tftpsvr1 or DHCP-tftpsvr2 to find the specific line for that log. If you take a look and the other lines of the logs, more information about the DHCP configuration can be found:
    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:
    As you can see in the log, a TFTP IP Address is configured in the DHCP server. This cause that the phone tried to provision to this TFTP server instead of the Webex Calling servers.
    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.
    After remove any TFTP configuration and any OPT configuration from the DHCP server, you must factory reset the device in order to start the process to provision the device with WxC again.
    The first attempt that the phone do with the process for provisiong the device is to make a request to the URL activate.cisco.com. The phone makes a query to the DNS server in order to resolve the domain. If the DNS Resolution fail, it can look like this:
    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
    If the phone can resolve the domain, it can look like this:
    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
    After receiveing the 200 OK from the GET request to activate.cisco.com the phone makes a request to cisco.siplash.com. It is the same process, the phone tries to resolve the domain and if it fails it can look like this:
    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"

    If the phone can resolve the domain, it can look like this:

    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

    Trobuleshoot DNS (Provision URLs)

    If you are in the same network where the devices has problems with the DNS resolution, an nslookup can be used to check if the DNS server is able to resolve the domain. Open the command line interface and do the next steps:

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

    If the PC can resolve the domain, it can look like this:

    nslookup activate.cisconslookup activate.cisco

    The same process can be made for cisco.sipflash.x to resolve the domain:

    nslookup cisco sipflashnslookup cisco sipflash

    If the PC is unable to resolve the domains, look at your DNS server.

    Trobleshoot the Registration for an MPP device in WxC

    For this example, the outbound proxy is da02.hosted-us10.bcld.webex.com. The phone tries to resolve the SRV domain:

    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

    If the phone is able to resolve the SRV domain it gets the hostnames:

    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

    From one of those hostnames the phone takes one of them to register de device to the 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
    The device must get a 401 Unauthorized message from the WxC side:
    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
    The device sends the REGISTER with the Authorization 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

    And then, the device gets a 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
    After this process, the device must be up and registered to the WxC services.

    Troubleshoot DNS (Register URLs)

    If you are in the same network where the devices have problems with the DNS resolution, nslookup can be used to check if the DNS server is able to resolve the domain. Open the command line interface and do the next steps:

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

    If the PC is able to resolve the domain it can look like this:

    nslookup SRV OBPnslookup SRV OBP

    Packet Capture (Registration Process)

    You can take the IP Address that the phone has for register, a filter can be used in the packet capture to look at the TLS handshake:

    PCAP SSEPCAP SSE

    The packet capture can help in order to see if the TLS handshake failed.

    Cisco Webex Calling TAC Support

    If you need support in order to analyze the logs and find the root cause of the issue, please contact the Cisco Webex Calling TAC team.

    Support Related Information

    Port Reference Information for Webex Calling

    Revision History

    Revision Publish Date Comments
    2.0
    18-Apr-2024
    Initial Release
    1.0
    04-Oct-2023
    Initial Release
    TAC Authored

    Contributed by Cisco Engineers

    • Enrique Martinez Garcia
      Technical Consulting Engineer

    Was this Document Helpful?

    FeedbackFeedback

    Contact Cisco

    This Document Applies to These Products