Cisco IP Telephony Fundamentals

IP Telephony, also referred to as Voice over IP (VoIP), is a generic term that used to describe the transport of traditional communications services, such as voice and fax, over the Internet Protocol (IP). Some common elements found in a typical Cisco IP Telephony (IPT) solution include the following:

• One or more Call Agents
• IP Phones
• Application Servers
• Voice Gateways
• Voice Gatekeepers

Call agents, such as Cisco Unified Communications Manager, are responsible for ordering and directing each step of call completion for the endpoints, which may include IP phones and analog and digital ports on voice gateways. Cisco Unified Communications Manager (CUCM) typically communicates with Cisco IP phones using the Skinny Call Control Protocol, abbreviated as SCCP or sometimes simply referred to as Skinny. SCCP is a proprietary network terminal control protocol that is built on a client / server model. Using Skinny, end stations, which may be IP phones or even gateway ports communicate with the call agent (CUCM) and receive call setup and teardown instructions, amongst other things from the call agent.

In addition to using Skinny, the call agent can communicate with endpoints using the MGCP protocol. MGCP stands for Media Gateway Control Protocol. Like SCCP, MGCP also uses a client / server model where the call agent is responsible for ordering and directing each step of call completion for the endpoints. However, unlike Skinny, MGCP is an open standard that is supported by many different vendors.

In addition to controlling and directing endpoints, call agents also provide other services and functions which include bandwidth management, address translation, and Call Admission Control (CAC). CAC is used to protect the quality of voice call by preventing call completion if there are not enough resources available to support the call(s). It is not the same thing as QoS which is used to protect real-time traffic, such as voice and video, from data traffic that is also contending for the same network resources.

NOTE: You are not required to go into any further detail on SCCP or MGCP in the TSHOOT exam. Additionally, while QoS is a core requirement of the TSHOOT exam, you are not required to go into detail on Call Admission Control (CAC). SCCP, MGCP and CAC are not described in any additional detail in this chapter or the remainder of this guide.

An IP phone is simply a telephony endpoint that allows telephone calls to be made over an IP network connection instead of a traditional analog connection.
Cisco IP Telephony implementations typically include one or more application servers that are used to provide additional services such as voice mail (Cisco Unity, Unity Connection and Unity Express), unified messaging (Cisco Unity Unified Messaging), call routing and comprehensive contact management capabilities (Cisco Unified Contact Center Enterprise and Cisco Unified Contact Center Express), and user availability and communications capabilities information (Cisco Unified Presence).

Voice gateways are an integral part of the Voice over Internet Protocol (VoIP) network. In their most simple form, gateways are used to connect dissimilar networks, such as the IP network to the traditional Public Switched Telephone Network (PSTN). In essence, the primary function of a gateway is to convert data traveling through it to a format that the other side understands. However, Cisco IOS voice gateways can perform additional tasks and functions such as translations, Call Admission Control (CAC) and Quality of Service (QoS) amongst other things. The call agent can communicate with Cisco IOS voice gateways using MGCP, SCCP, H.323 or the Session Initiation Protocol (SIP). As is the case with MGCP and SCCP, you are not required to go into any detail on either H.323 or SIP in the current TSHOOT exam.

Gatekeepers are optional H.323 IP Telephony components that, when used, provide advanced services such as address translation, CAC, bandwidth control and zone management. A zone is a collection of all endpoints that are managed by the gatekeeper. A simple common example of an endpoint would be a voice gateway. Figure 12-1 shows the components described in this section and how they would be integrated into an IP Telephony solution:

Fig. 12-1. A Basic IP Telephony Implementation

Figure 12-1 shows the different VoIP components described in the previous section. It should be noted that this diagram is reflective of a single site. In the event that there are multiple sites, sometimes the voice gateways may also be used to connect to the WAN, allowing remote IP phones to communicate with the local call agent. Alternatively, additional dedicated routers can also be used to connect to the WAN, providing additional network fault tolerance.

Prior to implementing and IPT or VoIP solution, it is imperative that the network, i.e. both the LAN and the WAN, be adequately prepared or configured to support this traffic. The sections that follow describe some core requirements, which include the following:

• Dynamic Host Configuration Protocol Services
• Network Time Protocol Services
• Trivial File Transfer Protocol Services
• Cisco Discovery Protocol
• Voice or Auxiliary VLAN
• Power over Ethernet
• LAN and WAN Quality of Service

Dynamic Host Configuration Protocol Services

Like most other endpoints, Cisco IP phones require the services of a DHCP server to obtain the addressing information necessary for them to access network services. However, in addition to basic addressing services, Cisco IP phones also need DHCP servers to provide them with address information for the TFTP server from which they will download their configuration file.
Within the DHCP server configuration, the IP address of the TFTP server should be configured as either DHCP Option 150 when specifying an IP address or DHCP Option 66 when you specify a FQDN. However, it should be noted that you can also specify an IP address when you use DHCP Option 66. When configuring the DHCP pool for the IP phones, it is important to remember that these two options should never be configured together for the same pool. These options are considered mutually exclusive; i.e. use one or the other. Using both of these options could result in IP phones using the incorrect or less preferred TFTP server.

NOTE: If DHCP Option 66 is used and a name is specified, a DNS server must be available to resolve the name to an IP address otherwise the IP phone will not be able to contact the TFTP server to retrieve its configuration file. Because using Option 66 adds additional dependency on a DNS server, this method is seldom used and DHCP Option 150 is most commonly used.

The following configuration example illustrates how to configure Cisco IOS DHCP server for IP phones and specify the IP address of the TFTP server using DHCP Option 150:

The following configuration example illustrates how to configure Cisco IOS DHCP server for IP phones and specify the name of the TFTP server using DHCP Option 66. Because a name is specified, the DHCP pool is also configured with the IP addresses of two DNS servers. This will allow the IP phones to communicate with the named TFTP server:

NOTE: Additional information on Cisco IOS DHCP server and Cisco IOS DHCP relay agent configuration can be found in the ‘ Troubleshooting Cisco IOS DHCP and NAT’ chapter in this guide or within the ‘ Branch Office and Teleworker Technologies’ chapter in the ROUTE guide which is currently available online.
Network Time Protocol Services

NTP is an integral component of the IPT implementation. NTP services are applicable to both the Cisco IP phones as well as the Cisco Unified Communications Manager. For Cisco IP phones, the NTP server can be used to ensure that they display the correct time. However, this service may also be used for additional functions such as restricting calls based on time and correct or accurate reporting, for example. This functionality is configured in the DHCP server which provides this information to the IP phones in conjunction with other addressing parameters. In Cisco IOS software, one or more NTP servers can be specified for the DHCP pool using theoption 42 <ip|ascii> [address|name] DHCP pool configuration command.

Again, keep in mind that if a DNS name is provided then the pool must also be configured with at least one DNS server. The following example illustrates how to specify an NTP server for Cisco IP phones when configuring a DHCP pool and using the Cisco IOS DHCP server feature:

In addition to Cisco IP phones, Cisco Unified Communications Manager servers also use the services of an NTP server. During installation, Cisco Unified CallManager prompts the administrator to specify the external NTP server at publisher installation. If the server is not reachable, the installation fails. Additionally, when installing additional servers as part of cluster, if the first node is not synchronized with an NTP server, the installation of the subsequent node will fail.

NOTE: The CUCM server can be configured to synchronize with a Cisco IOS router or switch configured as an NTP server. Cisco IOS software NTP server configuration is described in the ‘ Network Monitoring and Maintenance’ chapter in this guide.

TFTP Services

TFTP services are a critical component of the overall Cisco IP Telephony solution. Cisco IP phones receive their configuration parameters from the specified TFTP server. In most instances, the Cisco Unified Communications Manager server is the TFTP server. However, Cisco IOS routers running Cisco Unified Communications Manager Express can also be configured as TFTP servers. The phone receives TFTP server information via either DHCP Option 150 or 66 as described previously in the DHCP services section.

Cisco IOS TFTP server functionality is disabled by default, but can be enabled using the tftp-server <location>:<filename> global configuration command. The following configuration example illustrates how to configure a Cisco IOS software router running Cisco Unified Communications Manager Express (CUCME) to function as a TFTP server for IP phones. This configuration allows Cisco IP phones that use this device as the TFTP server to download the correct firmware files:

NOTE: The $ sign in the configuration above is simply due to the text being too long for a single line and is therefore truncated. The configuration also assumes that the files specified exist in the specified location, i.e. in Flash memory. Make sure that the relevant files do exist prior to implementing such configurations.

Cisco Discovery Protocol

It is common (recommended) practice to disable CDP for security purposes as it prevents any adjacent devices from gaining information about the router or switch. However, CDP is an integral component of the Cisco IP Telephony solution. CDP is used to inform Cisco IP phones are the voice or auxiliary VLAN. Additionally, CDP is also an integral component of inline power. If you must disable CDP, do it on a per-port basis, ensuring that the switch ports connected to Cisco IP phones have CDP enabled. If CDP is disabled on these ports, the IP phone cannot exchange messages with the switch about the voice VLAN or power requirements.

Voice VLAN(s)

When connecting Cisco IP phones to the switch, it is recommended that the switch interface be configured as a Multi-VLAN Access Port (MVAP), which allows the Cisco IP phone and connected device, e.g. a laptop or workstation, to use different VLANs. This configuration will allow voice traffic to receive priority over the data traffic sent by the connected device. While not mandatory, the use of a separate VLAN for the voice traffic ensures that this delay-sensitive traffic is able to be prioritized over normal user data traffic.

NOTE: When using an MVAP, from the perspective of the attached device, it is simply connected to a switch. In other words, the connected device, e.g. the workstation or laptop is completely unaware of the fact that it is actually connected to an IP phone.

The voice or auxiliary VLAN is configured in the same manner as any other VLAN. All normal VLAN rules, such as Spanning Tree priorities and parameters, apply to this VLAN in the same manner as they would for any standard data VLAN. On an MVAP, a native VLAN for data traffic for the workstation connected to the IP phone is identified by the port VLAN identifier (PVID) which is specified using the switchport access vlan <vlan> interface configuration command. An Auxiliary VLAN for voice service is identified by the voice VLAN identified (VVID) which is specified using the switchport voice vlan <vlan> interface configuration command. Following this configuration, the switch communicates the VVID to the IP phone using the Cisco Discovery Protocol (CDP).

Frames sent by the PC connected to the Cisco IP phones will be sent in the native VLAN (PVID). These frames will be untagged. Frames or packets sent by the Cisco IP phone will use the auxiliary VLAN (VVID). These frames will include the 802.1Q tag. Within this tag, the User Priority field contains the Quality of Service (QoS) information. QoS requirements for VoIP are described later in this section.

Power over Ethernet

Cisco IP phones can use an external power supply to draw their power, or they can draw their power from the switch to which they are connected; with the latter being the most commonly used method. When power is drawn from the switch, the power is sent within the Ethernet cable connecting the switch and the IP phone. There are 2 methods for providing inline power:

1. IEEE 802.3af-2003
2. Cisco Inline Power

The IEEE 802.3af-2003 Power over Ethernet (PoE) standard defines terminology to describe a port that acts as a power source (PSE) to a powered device (PD) defines how a powered device is detected and also defines two (2) methods of delivering Power over Ethernet to the discovered powered device. Cisco inline power (PoE) is a proprietary approach. The IEEE 802.3af standard is actually based on this method of PoE, which was available before PoE was standardized. Cisco has also extended power management extensions using Cisco Discovery Protocol negotiation to Cisco IEEE 802.3af compliant devices to further optimize PSE power management. Cisco Catalyst switches support both ILP and 802.3af.

When selecting to use PoE, it is important to adequately calculate the amount of power that will be required. You can use the Cisco Power Calculator available on the Cisco website to perform such calculations. Incorrect power calculations can adversely impact the IP Telephony implementation. When calculating total power requirements for the IP Telephony solution, you should also factor in other solutions or devices that will draw power from the same switches. Such devices may include wireless Access Points for example.

You can use the show power suite of commands to verify PoE functionality. For example, you can use the show power inline command to verify inline power status as follows: