Chapter 3 – CCNA VOICE

This chapter includes the following topics:
• Connecting and Powering Cisco IP Phones: To provide a centralized power system, the Cisco IP Phones must receive their power from a centralized source using PoE. This section discusses the different options for PoE and the selection criterion of each.
• VLAN Concepts and Configuration: VLANs allow you to break the switched network into logical pieces to provide management and security boundaries between the voice and data network. This section discusses the concepts and configuration behind VLAN.
• Understanding Cisco IP Phone Boot Process: This section discusses the foundations of the Cisco IP Phone boot process. Understanding this process is critical to troubleshooting issues with the IP Telephony system.
• Configuring a Router-Based DHCP Server: This section discusses configuring a Cisco router as a DHCP server for your network.
• Setting the Clock of a Cisco Device with NTP: Because a VoIP network heavily depends on accurate time, the sole focus of this section is keeping the clocks accurate on Cisco devices by using NTP.
• IP Phone Registration: Once the Cisco IP Phone receives all its network configuration settings, it is ready to speak to a call processing agent. This section describes the process and protocols that make it happen.
!!!!!
!
Before we can get to the point of plugging in phones and having happy users placing and receiving calls, we must first lay the foundational infrastructure of the network. This includes technologies such as Power over Ethernet (PoE), voice VLANs, and Dynamic Host Configuration Protocol (DHCP).
!
After you physically connect the IP phone to the network, it needs to receive power in some way. There are three potential sources of power in a Cisco VoIP network:
• Cisco Catalyst Switch PoE (Cisco prestandard or 802.3af power)
• Power Patch Panel PoE (Cisco prestandard or 802.3af power)
• Cisco IP Phone Power Brick (wall power)
!
The terms inline power and PoE describe two methods you can use to send electricity over the unused Ethernet wires to power a connected device. There is now a variety of devices that can attach solely to an Ethernet cable and receive all the power they need to operate. In addition to Cisco IP Phones, other common PoE devices include wireless access points and video surveillance equipment.
!
PoE became an official standard (802.3af) in 2003. However, the IP telephony industry was quickly developing long before this. To power the IP phones without an official PoE standard, some proprietary methods were created, one such method being Cisco Inline Power.
!
Note
The IEEE standards body has recently created the 802.3at PoE standard (also called PoE Plus), the goal of which is to increase the current maximum PoE wattage from 15.4W to 25.5W. In addition, some proprietary implementations of PoE have reached 51W of power by using all four pairs of wire in the Ethernet cable.
!
Note
Some devices exceed the power capabilities of the 802.3af PoE standard. For example, when you add a sidecar module to a Cisco IP Phone (typically to support more line buttons), PoE connections can no longer support the device. These devices will need a power brick adapter.
!
There are many benefits to using VLANs in an organization, some of which include the following:
• Increased performance: By reducing the size of the broadcast domain, network devices run more efficiently.
• Improved manageability: The division of the network into logical groups of users, applications, or servers allows you to understand and manage the network better.
• Physical topology independence: VLANs allow you to group users regardless of their physical location in the campus network. If departments grow or relocate to a new area of the network, you can simply change the VLAN on their new ports without making any physical network changes.
• Increased security: A VLAN boundary marks the end of a logical subnet. To reach other subnets (VLANs), you must pass through a routed (Layer 3) device. Any time you send traffic through a router, you have the opportunity to add filtering options (such as access lists) and other security measures.
!
Using this process, the PC never knows what VLAN it belongs to. The VLAN tag is applied when the incoming frame crosses a trunk port. The VLAN tag is removed when exiting the port to the destination PC. Always keep in mind that VLANs are a switching concept; the PCs never participate in the VLAN tagging process.
VLANs are not a Cisco-only technology. Just about all managed switch vendors support VLANs. In order for VLANs to operate in a mixed-vendor environment, a common trunking or “tagging” language must exist between them. This language is known as 802.1Q. All vendors design their switches to recognize and understand the 802.1Q tag, which is what allows us to trunk between switches in any environment.
!
It is a common and recommended practice to separate voice and data traffic by using VLANs. There are already easy-to-use applications available, such as Wireshark and Voice Over Misconfigured Internet Telephones (VOMIT), that allow intruders to capture voice conversations on the network and convert them into WAV data files. Separating voice and data traffic using VLANs provides a solid security boundary, preventing data applications from reaching the voice traffic. It also gives you a simpler method to deploy QoS, prioritizing the voice traffic over the data.
One initial difficulty you can encounter when separating voice and data traffic is the fact that PCs are often connected to the network using the Ethernet port on the back of a Cisco IP Phone. Because you can assign a switchport to only a single VLAN, it initially seems impossible to separate voice and data traffic. That is, until you see that Cisco IP Phones support 802.1Q tagging.
!
NOTE
Keep in mind that Cisco IP phones will be able to receive this voice VLAN configuration from the switch via CDP. After it receives the voice VLAN number, the IP Phone begins tagging its own packets. Non-Cisco IP Phones cannot understand CDP packets. This typically requires you to manually configure each of the non-Cisco IP Phones with its voice VLAN number from a local phone configuration window (on the IP phone).
!
DHCP options include items such as default gateway, DNS server information, domain name information, and so on. In the case of Cisco IP Phones, a unique DHCP option is included, known as Option 150. This option directs the IP phone to a TFTP server.
!
After the Cisco IP Phone has the IP address of the TFTP server, it contacts the TFTP server and downloads its configuration file. Included in the configuration file is a list of valid call processing agents (such as Cisco Unified Communications Manager or Cisco Unified Communications Manager Express CME agents).
!
When you configure a Cisco IP Phone in Cisco Unified Communications Manager (CUCM) or CME, an XML configuration file is generated and stored on a TFTP server. These CML configuration files have a filename format of SEP<IP Phone MAC Address>.cnf.xml and contain a base configuration for the IP phone (specifying language settings, URLs, and so on). Most importantly, these XML files contain a list of up to three CUCM server or CME IP addresses the Cisco IP Phone uses for registration. After the IP phone receives the XML file, it attempts to register with the first CUCM or CME server listed in the file. If it is unable to reach that server, it moves down to the next until the list is exhausted (at which point the IP phone reboots and tries it all over again).
!
Note
If the Cisco IP Phone has not yet been configured in CUCM or CME (no SEP<MAC>.cnf.xml file exists on the TFTP server), the IP Phone requests a file named XMLDefault.cnf.xml. This is a base configuration file typically used for a feature called Auto-Registration (allowing phones to register without being configured).
!
Tip
Many people often wonder the meaning of SEP at the beginning of the configuration filename. SEP stands for Selsius Ethernet Phone. Selsius was the name of the company Cisco acquired when they first began manufacturing VoIP technology.
!
Here is a quick list of just some of the reasons why you want an accurate clock on your network devices:
• It allows Cisco IP Phones to display the correct date and time to your users.
• It assigns the correct date and time to voicemail tags.
• It gives accurate times on Call Detail Records (CDR), which are used to track calls on the network.
• It plays an integral part in multiple security features on all Cisco devices.
• It tags logged messages on routers and switches with accurate time information.
!
A stratum 1 time server is one that has a radio or atomic clock directly attached. The device that receives its time from this server via NTP is considered a stratum 2 device. The device that receives its time from this stratum 2 device via NTP is considered a stratum 3 device, and so on. There are many publicly accessible stratum 2 and 3 (and even some stratum 1) devices on the Internet.
!!!!!!!!!!!!!
!
Note
Example 3-4 illustrates configuring a Cisco router to support NTP. This is necessary if you are supporting a Cisco IP Telephony network using Communication Manager Express (CME). If you were using a full CUCM solution, you’d configure NTP on the CUCM server.
!
If the IP phone finds an active server in the list, it goes through the registration process using either the Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP). The protocol the phone uses depends on the firmware it is using. Today, most Cisco IP Phones use the SCCP, which is Cisco proprietary. However, as the SIP protocol matures, widespread support continues to grow. Because SIP is an industry standard, using it across your network provides benefits such as vendor neutrality and inter-vendor operation.
!
Regardless of the protocol used, the registration process is simple: The Cisco IP Phone contacts the call processing server and identifies itself by its MAC address. The call processing server looks at its database and sends the operating configuration to the phone. The operating configuration is different than the settings found in the configuration XML file located on the TFTP server. The TFTP server configuration is “base level settings,” including items such as device language, firmware version, call processing server IP addresses, port numbers, and so on. The operating configuration contains items such as directory/line numbers, ring tones, softkey layout (on-screen buttons), and so on. Although the TFTP server configuration is sent using the TFTP protocol, the operating configuration is sent using SIP or SCCP.
!
These protocols (SIP or SCCP) are then used for the vast majority of the phone functionality following the registration. For example, as soon as a user picks up the handset of the phone, it sends a SCCP or SIP message to the call processing server indicating an off-hook condition. The server quickly replies with a SCCP or SIP message to play dial tone and collect digits. As the user dials, digits are transmitted to the call processing server using SCCP or SIP; call progress tones, such as ringback or busy, are delivered from the call processing server to the phone using SCCP or SIP.
!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s