Voice over IP (VoIP) is becoming more and more common in the enterprise world by replacing traditional TDM phone systems with feature-rich IP-based communication servers.  

Some benefits of converged voice, video, and data into a single network include:        

• Expense reducer – if only a single cable drop is required per user, cabling and network provisioning costs go down.  PSTN costs also go down as more calls can use the existing data network and not the public phone service.
• Efficiencies in bandwidth – for example, if a voice call is not in progress data can be transmitted on the same link.  That’s not the case with traditional phone lines.
• Innovative features- VoIP allows new services to be added including unifying several modes of communication (ex. voicemail, email, IM).  Service providers can also sell new services and provide more flexible pricing arrangements.

[table id=6 /]        

AVVID    

Architecture for voice, video and integrated data, more commonly referred to by Cisco as AVVID, was an all-encompassing blueprint for converged enterprise networks pitched by Cisco.  While it was originally intended to include a very large cross-section of product families, it has been primarily focused on Cisco’s VoIP products.  For the exam you should simply be aware of the fundamental deployment concerns which AVVID addresses:          

• High availability
• QoS
• Security
• Mobility
• Scalability

VoIP Components

• IP Phones – Provides voice and applications to users
• Cisco Unified Communications Manager (UCM) – Essentially an IP PBX
• Voice Gateways – Translate between IP and PSTN (can also serve as a backup to UCS)
• Gatekeepers- Optional, usually in larger environments.  Performs call admission control, allocates bandwidth for calls, and resolves phone numbers to IP addresses
• Video Conferencing Units – Allow voice/video calls
• Multipoint Control Units - Allow multi-point audio and videoconferencing
• Application Servers – Provide application services like Unity Voicemail

 Note:  Voice traffic comes in two types, voice bearer and call control signaling.  The voice bearer traffic uses RTP (Real Time Protocol) over UDP, while the call control portion can use several different protocols to communicate between the phone and UCM and UCM to voice gateway.        

VoIP Network Requirements

 When planning for a VoIP deployment, keep in mind the following factors:        

Features like call security, QoS, delay, etc.        

Cabling, use at least CAT-5.        

Power, either PoE from the switch, power inline module, or power brick connected to the phone itself.        

Bandwidth planning is crucial.  Commit no more than 75% capacity to allow for oversubscription and other types of traffic like video, and data.        

Network Management is important for proactively managing bandwidth and availability.        

High availability means redundant links, an auto-restart UPS, monitoring, and a response contract.        

Call Signaling

There are generally two separate traffic streams when placing a VoIP call.  The first is the call control signaling, used to setup, tear-down, maintain, and redirect calls.  Some examples of call signaling protocols include H.323, SIP, and MGCP.  Make sure you do not confuse these protocols with the voice compression protocols like G.729 and G.711.         

The second is the actual UDP voice traffic itself, which used RTP (Real-Time Transport Protocol) to encapsulate the traffic.         

Bandwidth Considerations

Each call uses somewhere around 21-106 kbs depending on the codec used, plus around 150 bps for control traffic.  Each voice packet is in the neighborhood of 60-120 bytes.        

A good formula for calculating call bandwidth is: (Packet payload + all headers) * Packets per second        

• Max one-way delay of 150 ms
• Under 1% packet loss
• Max average jitter (variable queue delays) of 30 ms
• The sum of every application’s bandwidth (including voice) should not exceed 75% of the total available bandwidth for each link.

Voice VLANs

Voice VLANs(sometimes referred to as auxiliary VLANS) are a way for Cisco switches to dynamically tag and assign voice traffic including placing it in it’s own separate VLAN/subnet.  That allows for QoS and security to be applied as well as simplified troubleshooting.  Voice VLANs are disabled by default.         

Cisco IP phones have a small internal switch that places an 802.1q tag on the voice traffic and marks the Class of Service (CoS) bits in the tag.  Data traffic (from the attached PC) is sent over the native VLAN, while all voice traffic is sent over the configured VLAN on the access port.  Cisco calls this setup a multi-VLAN access port.  This whole process of enabling voice VLANs also enables the switch to forward frames with specific 802.1Pmarkings.  802.1P designates how QoS is applied at the MAC layer.           

Power over Ethernet

PoE Switches

 Two different power standards exist for PoE, Cisco Inline PoE and IEEE 802.3af.  Both have a mechanism to sense that a powered device is connected to a port  – 802.3af relies on the devices to let the switch know how much power it needs, while Cisco’s devices can additionally use CDP to send that information.  Most phones don’t require more that 15 Watts of power, but some PoE equipment still requires more.  The new 802.3at standard will specify up to 30 Watts of power.  Some current Cisco switches can supply up to 20W.        

Switch assumes all PoE devices require 15.4 W of power until the device tells the switch otherwise.  If the switch reboots, all PoE devices will receive 15.4 Watts at the same time, which is why you should budget 15.4 W for every PoE device when doing power planning.        

Note:  Non-CDP devices always get 15.4 W allocated to them.        

PoE Configuration

 Cisco switches automatically detect and provide power, but if you need to disable it or re-enable it – use the following commands:        

Switch(config-if)# power inline {never | auto}        

To view power information for all ports:        

Switch# show power inline [interface]        

Video

Video traffic, from Cisco’s perspective, falls into one of three categories:     

Many to many – Examples include Telepresence, WebEx, peer-to-peer video apps
Data flows client-to-client or MCU-to-client
Bandwidth requiremenmts for high-def video can be up to 12 Mbs per location (with compression) 

Many to few - Examples include IP surveillance cameras.
Typically require up to 4 Mbs of bandwidth 

Few to Many – Example is Internet streaming from a single source
Quality not as critical
Traffic flows storage to client or server  to client