Preparing the Infrastructure to Support Unified Communications

In this section, the best practices components for preparing the network to properly support Unified Communications are explored. Topics covered include the following:

• Voice VLANs

• DHCP

• NTP

• Power over Ethernet

• IP Phone firmware and configuration filesPrivate Line Automatic Ringdown (PLAR)

Voice VLANs

VLANs provide a logical separation of Layer 3 traffic and are created at Layer 2 (the network switch). A voice VLAN (VVLAN, also called an Auxiliary VLAN) is an additional VLAN for the exclusive use of VoIP and video traffic. The benefits of using a VVLAN include isolation from the broadcast traffic data VLANs, a measure of additional security, and simpler deployment because you do not have to renumber the IP address scheme of the whole network to add VoIP endpoints. (Each VLAN is a new, separate subnet.)

Most Cisco IP Phones are actually 3-port switches. The port that connects to the network switch can act as an 802. lq trunk, allowing both voice and data traffic to be multiplexed in their respective VLANs on the single cable to the network switch. The second port connects the desktop PC to the phone (and thus to the network over the trunk on the first port), and the third port is an internal one for the voice traffic generated and received by the phone.

On many Cisco switches, the port connecting the phone does not need to be a trunk; it can be an access port instead. The switch is capable of sending the VVLAN ID using CDP messages, and the phone then sends frames from itself tagged with the learned VVLAN ID and forwards frames from the attached PC untagged. These untagged frames will be tagged with the access VLAN ID configured on the switch port when they are processed by the switch.


The phone adds a QoS marking to its own frames, using the 802. lq frame header Class of Service (CoS) field. The phone marks its frames as CoS 5 by default. This is the recommended setting, but it can be modified.

The following is a typical switchport configuration for an attached IP Phone in VVLAN 100 and the PC in VLAN 50:

DHCP

It is recommended that you use DHCP for IP Phone addressing. Create a separate subnet for the Voice VLAN and add the Option 150 parameter to identify the TFTP server IP address. This can be done on an existing DHCP server, or a new one can be added if necessary; Cisco routers have DHCP server capability. The following configuration is a typical example of router-based DHCP to support IP Phones:


If you choose to use a DHCP server that resides on a different network, you will need to add the ip helper-address command on the Voice VLAN interface of the router so that it will forward DHCP broadcasts from the phones to the DHCP server.


Network Time Protocol

Clock synchronization is important in VoIP systems for accurate Call Detail Records (used for billing), easier troubleshooting and debugging, and for good voice performance. Network Time Protocol (NTP) is used on all Cisco devices to sync the system clock to a master clock. IP Phones get their time from the call agent (CM, CM Business Edition, CM Express, or SBCS). The call agent(s) are configured to get their time from a master clock, usually a highly accurate atomic or radio clock external to the network.


Cisco IP Phone Firmware and XML Configuration Files

Cisco IP Phones need the following three separate files to function:

• The firmware file: This file is loaded into nonvolatile memory and is persistent across reboots. To make the firmware files available to the phones, use the router command tftp-server flash:firmware-file-name. The command load phone-type firmware-file is also required to associate the model of IP phone with the appropriate firmware file.
  

• SEPAAAABBBBCCCC.cnf.xml: This is the device-specific XML configuration file (AAAABBBBCCCC is the MAC address of the phone), which specifies the IP address, port, firmware, locale, directory URL, and many other pieces of information. This file is created when the IP Phone has been added to the configuration.

• XMLDefault.cnf.xml: This is the XML configuration file that devices use if their specific SEP file is not available (typically if they have not registered before or if they have been factory reset).

These files are downloaded by the phone during its boot process.


Power over Ethernet

Power over Ethernet (PoE) is a desirable option because it eliminates the cost and clutter of power bricks for the IP Phones. There are two methods of PoE delivery:

• Cisco prestandard (inline power)

• 802.3af standard

Extra care should be taken to ensure the following:

• RJ-45 cabling is tested and meets the required standard.

• The IP Phone and the switch have a common PoE delivery method.

• The PoE switch has a suitable UPS backup to provide power continuance in the event of a power failure.

Alternatively, each IP Phone may be powered by its own cable and transformer, or a variety of power injectors are available.

The Cisco prestandard PoE method works as follows:

1. The switch sends a special tone, called a Fast Link Pulse (FLP), out of the port. The FLP goes to the powered device, in this case an IP phone.

2. When unpowered, the PoE device has a physical link between the pin on which the FLP arrives and a pin that goes back to the switch. This creates a circuit, resulting in the FLP arriving back at the switch. Non-PoE devices will not have this link; the switch will therefore never receive the FLP from a device that does not require PoE.

3. When the switch receives the returning FLP, it applies power to the line.

4. The link comes up within 5 seconds.

5. The powered device (IP phone) boots.

6. Using CDP, the IP Phone tells the switch exactly how much power it needs. (Power requirements vary from device to device.)

The 802.3af PoE standard works slightly differently. The standard requires that all eight pins in the RJ-45 cable be present and punched down. The following describes the 802.3af PoE negotiation steps:

1. The switch applies constant DC power to all ports that may require PoE.

2. An 802.3af-compliant device will apply 25 ohms resistance across the DC circuit.

3. The switch detects the resistance and applies low-power PoE to the link.

4. The powered device (the phone) boots.

5. The phone uses CDP to specify its power needs.

Internet Telephony Service Providers

As VoIP technology matured and stabilized, telephone service providers began extending VoIP connectivity to their customers, allowing for simple, flexible connection alternatives to traditional TDM links. Internet Telephony Service Providers (ITSP) connections are typically much less expensive, available in smaller bandwidth increments than Tl or PRI links, and can route nonvoice data traffic concurrently. QoS configuration is supported (and in fact is required for proper VoIP operation). Most ITSP links use SIP, but H.323 is an option. The gateway configuration is relatively simple, with the creation of a VoIP dial peer pointing at the provider with the parameters they supply. PSTN calls are routed to the provider, who then routes calls to their PSTN connection, usually with a toll-minimizing route that dramatically reduces long-distance costs to the customer.


Understanding Call Setup and Digit Manipulation

Successfully completing a phone call requires that the correct digits are sent to the terminating device, whether on the VoIP network or the PSTN. PSTN calls are typically more complex because of the varying local and international requirements for the number of digits required to route the call. Over and above this basic requirement are the additional complexities imposed by requirements of the business: we may want to change our ANI number, add or strip access codes, compensate for undesirable default behavior, or build specialized functionality for our particular purposes. This section deals with digit manipulation and troubleshooting.

Translation rules use regular expression syntax, which can be quite complex. The following table defines the characters used, and examples follow.