IP phones running Microsoft Communicator “14” Phone Edition support Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) and Power over Ethernet (PoE). To take advantage of LLDP-MED, the switch must support IEEE802.1AB and ANSI/TIA-1057. To take advantage of PoE, the switch must support PoE802.3AF or 802.3at.

To enable LLDP-MED, the administrator must enable LLDP by using the switch console window and set the LLDP-MED network policy with the correct voice VLAN ID.

In addition, if your deployment includes analog devices, you must configure the analog gateway to use Microsoft Communications Server 2010, and the gateway must be one of the following:

1. An analog telephone adapter (ATA)
   
   
2. A SIP-PSTN analog gateway
   
   
3. A Survivable Branch Appliance that includes a SIP-PSTN analog gateway
   
   
4. A Survivable Branch Appliance that includes a SIP-PSTN gateway that communicates with an ATA
   
   

To learn how to configure an analog gateway, see Appendix B: Configuring Analog Gateways and Devices.

Important:
You can configure the switch for Enhanced 9-1-1 (E9-1-1), if the switch supports this.

IP phones use port 443 for the Device Update service.

Note:
To configure ports for analog devices, use the Gateway Management Console, as described in <information to come.>

IP phones require certain DNS records. The following table describes the records that you must create and publish to a DNS service, within the corporate network, if you’re deploying IP phones. For information about the DNS records that are required for external IP phones, see Table 3, later in this topic.

Table 1. DNS Records for External Devices

Note:
If the pool is already deployed, this information can be referenced from the Communications Server Control Panel Topology tab by selecting the Edge server properties.

IP phones require the Web Services URL and Enhanced Registrar FQDN from the DHCP server, for connectivity. To make sure that the DHCP server can provide IP phones with this information:

• Turn on this functionality by using this Communications Server Management Shell command: set-CsRegistrarConfiguration –EnableDHCPServer $true
  
  
• Ensure that broadcast packets from devices can reach the DHCP server(s) by configuring DHCP relay agents to forward DHCP packets to the Communications Server DHCP servers.
  
  
• For internal communications, ensure that the following options are set up on the organization’s DHCP servers:
  
  

  Table 2. DHCP Options for Internal IP Phones

  Option	Value	Note
  43	CS Pool Certificate Provisioning Service URL	Specify the internal URL in the form https://ocsWebPoolFQDN:443/CertProv/CertProvisioningService.svc*
  120	FQDN for the CA Pool Registrar	Specify the FQDN of the pool that will be the first logon server for the device. Typically this is a Director pool. If you do not deploy a Director pool, then this is the Front End Pool FQDN. The pool FQDN suffix must match the user's SIP URI.*
  43	VLAN ID	We strongly recommended that you use a VLAN. However, if you decided not to use a VLAN for unified communications, or if you use LLDP-enabled switches in the enterprise to provide VLAN IDs, then don’t set this option. Note that option 43 is not an independent option. Depending on the Vendor Class ID it is configured for, the option may have different values. The client identifies the vendor for which it wants the information as option 60 in the DHCP Request.

  *These are general examples, for more information, see Appendix: Configuring DHCP Options on DHCP Servers other than Windows DHCP Server, in the Deployment Guide.
  
  

  Tip:
  If you’re not allowing external access, set up DHCP option 4 (TimeServer). We strongly recommend that you deploy Communications Server DHCP servers in subnets where the Communications Server servers are located and that you use Communications Server DHCP servers in the central site and in small branch sites where Communications Server clients and servers are in the same subnet.

If you’re allowing external access for IP phones, a PKI infrastructure must be in place, and devices must have a valid Communications Server certificate, which they obtain when they log on and is issued from a public CA (recommended) or a private CA that allows the devices to connect to the Device Update service from outside the intranet. For more information, see Certificate Infrastructure Requirements, in this guide.

If you’re allowing external access for IP phones, deploy Edge servers by following the instructions in Deploying Edge Servers for External User Access, at the TechNet website, but during the Set up the Infrastructure for Edge Servers process, use the following configuration information to enable external access to the Device Update service:

• In the Configure a Reverse Proxy step, configure the reverse HTTP proxy to use the Device Update service virtual directory https://<external Server FQDN>:443 for the external URL for Web Services and the Device Update service.
  
  
• In the Configure DNS step, use the following information:
  
  

  Table 3. DNS Records for External Devices

  Type	Value	Note
  SRV	Edge server:_sipexternal._tls.<SIP domain>, and _sipexternaltls.<SIP domain>	Allows external devices to connect via SIP over TLS to the Enhanced Registrar internally.
  A	Reverse proxy FQDN:<server name>.<SIP domain>	Allows external devices to connect via TLS over HTTP to the Update Service.

  Note:
  If the Edge server is already deployed, this information can be referenced from the Communications Server Control Panel Topology tab by selecting the Edge server properties.

If your deployment includes analog fax machines, you must enable media bypass in Mediation Server. Mediation Server does not support faxes. Also verify that the analog device is correctly marked as fax in the contact object configuration, as described in “Contact Objects,” in Required Communications Server 2010 (Beta Refresh) Components for Devices.

Fax devices must be connected to a gateway with PSTN connectivity for inbound and outbound calls.