Device Connection Process
Topic Last Modified: 2012-06-21
This topic describes the device connection process. It is important to understand this process when troubleshooting devices because the steps in the process map to potential failure points that you can troubleshoot.
Connection Process for Internal IP Phones
The connectivity process for internal IP phones applies to all IP phones. The process differs only in the types of authentication that each IP phone uses. Only the new IP phones (that is, the Aastra 6721ip common area phone, Aastra 6725ip desk phone, HP 4110 IP Phone [common area phone], HP 4120 IP Phone [desk phone], Polycom CX500 IP common area phone, Polycom CX600 IP desk phone, and Polycom CX3000 IP conference phone) can use personal identification number (PIN) authentication. The Polycom CX700 IP desk phone can use certificate or NTLM authentication.
.jpg "98345d35-bee9-40a3-9196-8c9b140e6eac")
The process begins with the device’s attempt to obtain a virtual local area network (VLAN) ID by first trying Link Layer Discovery Protocol (LLDP), and, if that’s not available, falling back to Dynamic Host Configuration Protocol (DHCP).
Note
If the device fails to obtain a VLAN ID, the bootstrapping process continues.
Next, the device uses DHCP to acquire an IP address, queries the Domain Name System (DNS) for the SRV record for Lync Server SIP, and then parses that record to obtain the domain name. The name of the web server, ucupdates-r2, gets prepended to the domain to give the Device Update Web service’s fully qualified domain name (FQDN). The device then queries DNS for the A record for the Device Update Web service’s FQDN and queries the Device Update Web service for an update. If there is an update, the device will pull it down from the Device Update Web service’s store and apply it before rebooting. After rebooting, the device queries DHCP to discover the Web Services URL and the FQDN of the Director. The device can also determine the FQDN of the Director by querying DNS for the SRV record.
When the user starts to sign in, the authentication process begins. The device downloads the root certificate issuer chain of the Web Services (if this has not been previously obtained) and then connects to the web server over TLS and verifies the server’s certificate by using that chain. The certificate and the chain are stored on the device for future use.
The device authenticates, providing credentials as follows and using TLS for the communication:
The new IP phones (the Aastra 6721ip, Aastra 6725ip, HP 4110, HP 4120, Polycom CX500, Polycom CX600, and Polycom CX3000) provide a PIN and phone number or extension.
The older IP phone (Polycom CX700 IP desk phone) provides a user name, domain name, and password.
Note
The Aastra 6725ip, HP 4120, Polycom CX600, and Polycom CX700, and Polycom CX3000 also allow users to sign in by connecting the device to their computer by using a USB cable.
Web Services checks the credentials by contacting the Registrar to look up the user and the user’s home pool. If the credentials are correct, the device requests a certificate for the user, which is returned to the device and also published to the user store. The device uses the user’s certificate to authenticate the logon request and all subsequent SIP communications with the Registrar.
The following logic is used to determine which Registrar FQDN is used (that is, the one returned by DHCP or the one returned by DNS). In this logic, each record is tried until one succeeds. In Lync Server, Standard Edition the record is published automatically. In a Front End pool, you must publish the record manually. This A record should point to the virtual IP (VIP) of the Front End pool.
Internal DNS SRV (TLS)
DHCP address (TLS)
Internal DNS SRV (TCP)
DHCP address (TCP)
External DNS (TLS)
External DNS (TCP)
Lastly, the device connects to the Registrar, with a SIP Register request, and authenticates the communications with the user’s certificate. This logon is the start of any SIP communications.
Connection Process for External IP Phones
Before an external IP phone can connect, it must have had a successful connection, internally. The connection process for devices that are located outside the corporate network differs based on the authentication method that was used for that internal connection.
.jpg "a916ffc0-2dc1-4921-8793-e4c09dae6a09")
The user of an Aastra 6721ip, Aastra 6725ip, HP 4110, HP 4120, Polycom CX500, Polycom CX600, and Polycom CX3000 must successfully authenticate and log on to the Registrar internally in order to obtain the FQDN of the Device Update Web service (provided by in-band provisioning when a user logs on to Lync Server), the Web Services issuer certificate chain and server certificate, and the user’s certificate, all of which are required for a successful connection externally.
The user of a Polycom CX700, must log on internally, successfully, so that the device has obtained the external Device Update Web service FQDN, from in-band provisioning. The device does not need to use certificate authentication for this to take place. NTLM authentication is sufficient.
Alternately, if the Device Update Web service address cannot be obtained, the device will continue processing and attempt authentication and logon. After successful logon the device will know the FQDN of the server running the Device Update Web service and will resolve that to query for an update.
External Polycom CX700 that Used NTLM Authentication to Log On Internally
An external Polycom CX700 that has already logged on internally by using NTLM authentication, first attempts to obtain an IP address by using the local (external) DHCP server. Next, the device queries DNS, providing the FQDN value to locate the address of the server running the Device Update Web service, and then queries for an update. If one is available, the device will download the update, install it, and then restart.
After restarting, the device again obtains an IP address and again queries the Device Update Web service for an update. This time, it should not need another update so then the device queries DNS for the SRV for the enterprise’s Registrar FQDN. After it obtains this, the device queries for the corresponding A record.
Next, the device connects and authenticates, using NTLM as the credentials. The Registrar confirms authentication and returns the user’s home pool and SIP URI. The device then sends a SIP REGISTER request to log on, and the Registrar returns the FQDN of Web Services in the ACK response.
At this point, the device connects to Web Services and obtains the web server’s certificate chain. After it is obtained, the device attempts to authenticate first over TCP, which will be denied because Web Services in the extranet requires secure communications, and then over TLS. Web Services responds to the TLS query, providing the Web server certificate as its credential. By using the previously downloaded certificate chain, the device is able to authenticate Web Services. It sends a getAndPublish request. Web Services generates a certificate for the user on the device, publishes it in the user store, and returns it to the device.
From this point on, the device can use certificate authentication (the preferred method), as it has the credentials it needs, and it uses certificate authentication for subsequent connection requests.
External Aastra 6725ip, HP 4120, Polycom CX600, and Polycom CX700 that Used Certificate Authentication to Log On Internally
In this case, at startup, the external device first attempts to acquire an IP address by using the local (external) DHCP server. Next, the device queries DNS--providing the FQDN value that it obtained previously by using in-band provisioning--to get the Device Update Web service’s address, and then it queries for an update. If an update is available, the device downloads the update, installs it, and then restarts.
After restarting, the device goes through the IP address acquisition process again and then sends a TLS authentication request to Web Services, providing the user certificate as the credentials. If Web Services can validate the user, the response will be success, and the device will send a SIP REGISTER request to the external Registrar address, providing the user’s personal identification number (PIN) and phone number/extension as credentials.
For details about external user access, see Planning for External User Access in the Planning documentation.
Bootstrapping Process
After an IP phone is powered on and connected to the corporate network, the bootstrapping process is as follows:
Tip
Issues can occur in each of these stages, and the issues may differ depending on whether the device is inside or outside your organization’s firewall and on whether it is a new or older IP phone. To see issues that may come up during this process, see the following topics.