Cisco AVVID (page 5 of 5)
20 Jan 2010 @ 09:50AM

Updated: 20 Jan 2010 @ 09:50AM
Cisco IP Telephony

Cisco offers a comprehensive solution for migrating all voice systems to IP. The heart of this system is the Cisco CallManager, which is a software suite offering connectivity for IP phones, media processing devices, VoIP, gateways, and multimedia applications. Additional components can interact with CallManager through its API.

The primary benefit of CallManager is everything is software based, and thus requires no specialized hardware. The software package can support all standard corporate phone services such as hold, transfer, forward, conference, multiple lines, automatic route selection, speed dial, redial, and extension mobility (the ability to have your phone number and settings follow you to any IP phone you log in to). CallManager can also be clustered, allowing scalability up to 10,000 users per cluster. Additionally, multiple clusters can be interlinked to increase the user capacity up to 100,000. Call manager can also manage QoS over WAN links and, if necessary, reroute excess calls to the PSTN.

The goals of IP telephony networks are:
  • End-to-end IP phone network
  • Primary voice path is WAN with a PSTN backup
  • Lower cost with more flexibility
  • Growth of new applications

There are currently four general design models. These are detailed below.
Comments (0)
Single-Site Model

  • Single Cisco CallManager or CallManager cluster
  • Max 10,000 users per cluster
  • Max eight servers in a cluster (four servers for primary call processing, two for backup call processing, one database publisher, and one TFTP server)
  • Max 2,500 registered users with CallManager at any time
  • PSTN only for all external calls
  • Digital signal processor (DSP) resources for conferencing
  • Voice mail and unified messaging components
  • G.711 codec for all IP phone calls (80 kbps of IP bandwidth per call, uncompressed)
  • For best quality, use Cisco switches with at least two queues.
Comments (0)
Multiple Sites with Independent Call Processing

  • Cisco CallManager or Cisco CallManager cluster per site for scalable call control
  • Max 10,000 IP phones per cluster, no limit to # of clusters
  • Use of PSTN for networking multiple sites and for all external calls
  • DSP resources for conferencing at each site
  • Voice message or unified messaging components at each site
  • Voice compression not required
Comments (0)
Multiple Sites with Distributed Call Processing

  • Cisco CallManager or Cisco CallManager cluster per location, 10,000 user max per site.
  • Cisco CallManager clusters within a single campus, not spanning the WAN
  • IP WAN as the primary voice path between sites, transparent failover to PSTN
  • Cisco IOS gatekeeper for E.164 address resolution
  • Cisco IOS gatekeeper for admission control to the IP WAN
  • Max 100 sites connected via IP WAN, hub and spoke topology
  • Compressed voice calls supported across the IP WAN
  • Single WAN codec supported
  • DSP resources for conferencing and WAN transcoding at each site
  • Voice mail and unified messaging components at each site
  • Minimum bandwidth requirement for voice and data traffic is 56 kbps. For interactive video the minimum requirement is 768 kbps. Bandwidth allocated should not exceed 75% of the pipe
  • Remote sites can use Cisco IOS as well as gateways based on the Skinny Gateway Protocol
Comments (0)
Multisite IP WAN with Centralized Call Processing

  • Central site supports only one active Cisco CallManager. Clusters may contain a secondary and tertiary Cisco CallManager as long as all IP phones served by the cluster are registered to the same Cisco CallManager at any given time. This is called a centralized call processing cluster
  • Each cluster supports max 2500 users, no limit on number of remote sites. Multiple clusters can be interconnected using H.323
  • No local Cisco CallManager at remote sites
  • Call admission control mechanism based on bandwidth by location
  • Compressed voice calls across IP WAN supported
  • PSTN is manually available if IP WAN is unavailable, but it requires a PSTN access code.
  • Dial backup is required for IP phone service across the WAN in case the IP WAN goes down
  • Voice mail, unified messaging, and DSP resource components are available at the central site only
  • Minimum bandwidth requirement for voice and data traffic is 56 kbps. For interactive video the minimum requirement is 768 kbps. Bandwidth allocated should not exceed 75% of the pipe
  • Remote sites can use Cisco IOS as well as gateways based on the Skinny Station Protocol
  • If using voice mail, each site must have unique internal dial plan number ranges. Internal dial plans cannot be overlapped among remote sites if voice mail is required
Comments (0)
20 Jan 2010 @ 09:53AM
by Satis

Updated: 20 Jan 2010 @ 09:53AM
Issues with VoIP

Packet loss is when a packet gets dropped during transmission. This can cause clipping and skipping in a voice conversation.

Delay is a major issue with voice traffic. Any delay below 200 milliseconds is acceptable, but anything beyond that can render speech unrecognizable. The two types of delay are propogation delay and handling delay. Propagation delay is how long it takes for a packet to go from one end of a wire (or fiber optic cable) to the other. Handling delay (or serialization delay) is any delay introduced by devices on the voice network, such as codecs and DSPs.

Jitter is the variation between expected receive time and actual receive time. For instance, the average packet trip may be 150ms, with the occasional packet only taking 50ms. Jitter is compensated for using a buffer on a voice device.

End-to-end delay is the total delay from one side to the other.

Echo is voice feedback given to the speaker and is normal in a conversation. However, if the feedback exceeds 25 milliseconds in latency, it can cause problems with a conversation. In regular telephony, the echo is created by impedance mismatches between the four-wire network conversion to a two-wire local loop and is controlled by echo cancellers. In a VoIP network, echo cancellers are built into the low bit-rate codecs and are operated on each DSP. The echo canceller is limited by the amount of time it will wait for reflected speech to be received. This is called the echo trail and is normally 32 milliseconds, though it can be configured to 8, 16, 24 or 32 milliseconds.

Several technologies are used to to minimize these problems. Included are QoS features such as classification, queueing, traffic shaping, Compressed Real-Time Transport Protocol (CRTP), and TCP header compression. There are several item to keep in mind when implementing QoS.

Latency is one issue. Different types of traffic have different levels of latency they can withstand. For instance, voice or video conferencing should have no more than 150-200ms latency one way, while streaming video can live with 4 or 5 seconds of delay. Similarly, jitter causes no issues for streaming video, while live video/voice should have no more than 30ms of jitter.

Another thing to keep in mind is the bandwidth requirements. Voice requires very little guaranteed bandwidth (17-106 Kbps + 150bps control overhead) while live video requires significantly more. Live video should have its bandwidth + 20% reserved, so a 768Kbps video stream should have 922Kbps available.

The way to achieve QoS is through classification of traffic. This can happen at layer 2 or 3. An important concept here is a trust boundary. Do you trust the client to make the QoS determination? If so, your trust boundary encompasses all devices on the network. However, if you don't trust the end-devices to handles QoS prioritization properly, the trust boundary moves back. First it moves to the access layer, but if your access layer hardware is unable to make QoS determination either, it has to move back to the distribution layer.

At layer 2, a CoS (Class of Service) can be assigned to a frame to weigh its relative importance. At layer 3, there is a ToS (type of service) field to make a similar determination.

By default, a Cisco IP phone send its frames tagged with a value of 5, plus an equal value in the ToS field of the IP packet. However, most PCs do not have NICs capable of doing 802.1Q tagging (layer 2 tagging), and thus leave that field set to 0. Specific applications running on a host can set this field, or the TCP/IP stack could be altered to change the default setting. However, if the phone is forwarding PC packets as well, default behaviour of the phone zeroes out the CoS field in all PC packets.

Based on the layer 2 CoS and the layer 3 ToS, routers and switches should be configured with priority queuing and/or QoS ACLs to control traffic. This would place delay-sensitive traffic at the head of any queue, placing data traffic and other, less-important data at the end of the queue. When transferring packets into a WAN, remember that layer 2 information will be lost. Thus, it's important that level 3 ToS be implemented to maintain QoS across a WAN.
Comments (0)
IP Phones

IP phones have a three port switch built into them. One port on the phone is meant to connect to the wall socket. Additionally, a PC can then be connected through the phone. This way, no physical changes need to be made to the wiring infrastructure. Alternately, a PC could be connected to a wall port separately from a phone, which allows the two systems to be physically removed from one-another. Different switches could then be used to provide redundancy and an ease in control. Alternately, a Cisco IP SoftPhone could be employed, which is basically a software phone that resides on a computer, rather than a physical phone.

IP Phones can pull their power from a variety of places. Most easily, they can be plugged into a power outlet. Alternately, they can be provided with inline power, in which the switch broadcasts power to the phone through the UTP cabling. Lastly, an external patch panel can feed power into the UTP cable, in the case where a power-enabled line card is not available. These patch panels have a 250W power supply and are able to supply power to 48 ports (48 phones at 6.3W/phone).

IP Phones can obtain an ip address either statically or dynamically. They can also be either on the same network as the PCs, or on their own network. Obviously, putting them on their own network has many advantages.

To implement DHCP, a phone would power up and grab its voice subnet automatically. At that point, it would send a DHCP request on that subnet for an IP. The IP phone uses CDP to get this voice vlan. To help with this, CDP has been enhanced with 3 additional field.

  • Voice VLAN ID (VVID). Tells the IP phone its voice vlan.
  • Trigger field. Solicits a response from a connected device. This way, a phone doesn't have to wait for the automatic CDP updates to be sent.
  • Power field. This is for getting the exact power requirements of the connected phone. Initially 10W is allocated, then adjusted with this field.

Following is a step-by-step explanation of the process a phone goes through to connect to a network.

  1. The phone sends a triggered CDP message to obtain its VVID from the switch
  2. DHCP request issued (default, can be set to static)
  3. Gets DHCP response with IP, maybe TFTP server to get config (option 150 on DHCP server).
  4. Does TFTP to get list of addresses of Cisco CallManagers (up to 3).
  5. Contacts Cisco CallManager to register and get config and runtime code (includes DN, which is phone's number).
  6. Ready to make/receive calls
Comments (0)
Configuring a voice vlan

By default, there is no voice vlan, and CoS settings are untrusted. First, QoS should be enabled and the trust state should be defined.

Switch(config)#mls qos
Switch(config-if)#mls qos trust

To configure the VVLAN.

Switch(config-if)#switchport voice vlan {vlan-id | dot1p | none | untagged}

vlan-id - vlan used for voice traffic, 1 - 4094.
dot1p - sets telephone to use priority tagging and vlan 0 (native vlan).
none - no configuration is sent to the phone about a voice vlan. Configuration must be made from the phone keypad.
untagged - No frame tagging and set to use vlan 4095.
Comments (0)