Topic Last Modified: 2011-05-04

This topic describes the device connection process.

It is important to understand this process when troubleshooting devices as 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 phone applies to all IP phones. The process differs only in the types of authentication that each device uses. Only the new IP phones (that is, Polycom CX600, Polycom CX500, Polycom CX3000, Aastra 6725ip, and Aastra 6721ip) can use PIN authentication. The Polycom CX700 can use certificate or NTLM authentication.


The process begins with the device’s attempt to obtain a VLAN ID by first trying LLDP, and, if that’s not available, falling back to DHCP.

Note:
We strongly recommend that all devices are put into a VLAN so as to improve voice communications by separating unified communications (UC) devices from other network traffic; however, it is not required for connectivity. If the device fails to obtain a VLAN ID, the bootstrapping process continues.

Next, the device uses DHCP to acquire an IP address, queries 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 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 Services 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 (Polycom CX600, Polycom CX500, Polycom CX3000, Aastra 6725ip, and Aastra 6721ip) provide a PIN and phone number or extension.

  • The older IP phone (Polycom CX700) provides a user name, domain name, and password.

    Note:
    The Polycom CX600, Polycom CX3000, and Aastra 6725ip also allow users to sign in by connecting the device using a USB cable to their computer.

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 VIP of the Front End pool.

  1. Internal DNS SRV (TLS)

  2. DHCP address (TLS)

  3. Internal DNS SRV (TCP)

  4. DHCP address (TCP)

  5. External DNS (TLS)

  6. 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.


The user of a new IP phone 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 the older IP phone, the 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, 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 Polycom CX700 and Aastra 6725ip 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.
  1. Finding the VLAN ID

  2. Obtain an IP Address

  3. Find the Device Update Web Service

  4. Check for Updates

  5. Obtain Registrar FQDN and Web Service URL

  6. Connect to the Web Service and Download the Root CA Certificate Chain

  7. Authentication Process

  8. Receive and Publish Certificate.

  9. Log on to the Lync Server