Cisco Systems IP Phone 7920 IP User Manual

Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Table of Contents  
RF Overview Site Surveys and Design Recommendations................................................................2  
Security for the Cisco 7920 and WLAN Networks................................................................................5  
Network Sizing.......................................................................................................................................6  
Number of 802.11b Devices per AP................................................................................................6  
Number of 802.11b IP Phones per AP.............................................................................................6  
Numbers of 802.11b Phones per Layer 2 Subnet or VLAN............................................................8  
WLAN QoS for VoIP...........................................................................................................................14  
Connecting APs to the Catalyst 2950 SI........................................................................................20  
Related Information..............................................................................................................................23  
i
Download from Www.Somanuals.com. All Manuals Search And Download.  
AVVID design guides and administration.  
Components Used  
The information in this document is based on the software and hardware versions below:  
The Cisco 7920 IP Phone.  
The information in this document was created from the devices in a specific lab environment. All of the  
devices used in this document started with a cleared (default) configuration. If your network is live, make sure  
that you understand the potential impact of any command.  
Conventions  
For more information on document conventions, see the Cisco Technical Tips Conventions.  
Cisco 7920 IP Phone Overview  
The Cisco 7920 IP Phone extends the AVVID family of IP phones from 10/100 Ethernet to 802.11b WLANs.  
The Cisco 7920 provides a multi−line appearance with functionality similar to existing Cisco 79xx IP Phones.  
In addition, the Cisco 7920 provides enhanced WLAN security and Quality of Service (QoS) for operation in  
802.11b networks. Future enhancements to the Cisco 7920 will add support for XML−based data access and  
services, as well as Universal Serial Bus (USB) connectivity for additional data services.  
WLAN Overview  
802.11b WLAN networks allow multiple devices to transmit data, voice, and video at data rates up to 11Mb.  
While WLAN networks allow similar types of traffic to be transmitted over them, it does have certain  
characteristics that differ from wired networks:  
WLANs operate as a shared medium, which means that communication on the WLAN is half−duplex  
and that all devices within a single WLAN share the 11Mb.  
WLAN bandwidth varies based on the distance that a WLAN client is from a WLAN Access Point  
(AP). The farther the distance, the lower the data rates that traffic is supported.  
Since all WLAN traffic is seen by all other WLAN devices (within range), additional security  
considerations need to be taken to ensure that traffic is not captured or manipulated by intruders.  
RF Overview Site Surveys and Design Recommendations  
Before getting started with any WLAN deployment, the first activity that every network administrator should  
undertake is a complete site survey of the environment where the WLAN devices are deployed. The site  
survey should be performed to understand the number of APs required to provide Radio Frequency (RF)  
coverage. It should take into consideration which types of antennas provide the best coverage, as well as  
where sources of RF interference exist.  
An important factor to keep in mind is that rarely do two physical environments have the same RF  
characteristics. Because of this, the sections of this document that are RF specific are generalized. Network  
administrators may need to adjust those parameters to their specific RF environment and requirements.  
While you may have already performed RF site surveys for an initial WLAN deployment, it is important to  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
remember that the Cisco 7920 has somewhat different roaming characteristics than Cisco Aironet Network  
Interface Cards (NICs). This includes thresholds on the Cisco 7920 that determine when the phone roams or  
how much the RF environment needs to change in order to determine when a roaming event should occur.  
Because of this, it is recommended that a secondary site survey be performed for the Cisco 7920s. This gives  
you the opportunity to tune the APs to ensure that the Cisco 7920s have enough RF coverage and bandwidth  
to provide proper voice quality.  
The design recommendation is that the Received Signal Strength Indication (RSSI) level in the RF network is  
at least 20 throughout the network. This provides the Cisco 7920 with the minimum signal coverage to be able  
to not only initiate a new call, but also roam properly between APs.  
RSSI  
dBm  
15  
−85  
30  
−70  
45  
−50  
60  
−35  
The design recommendation is that the QoS Basis Service Set (QBSS) level on the APs is kept lower than 40.  
If the Cisco 7920 attempts to initiate a call and the QBSS element in the beacon is more than 40, the call will  
fail with a network busy tone to the user.  
The power levels of the APs vary from network to network and need to be adjusted to meet site−specific  
requirements. On the APs, the coverage area increases as the power levels increase. But this does not  
necessarily mean that all the APs should be set to 50 or 100mW. This could potentially create an RF  
environment where the Cisco 7920s roam too frequently because of RF coverage overlap. Frequent roams  
could potentially cause interruptions in the overall voice quality. On the Cisco 7920, another tradeoff to  
consider is that the higher the power−level, the shorter the battery life.  
VoIP QoS  
While Voice over IP (VoIP) does convert voice signals into IP data packets and converge them with data  
traffic, the requirements of voice and data are very different when transmitted over an IP network. Data traffic  
can be classified with the following characteristics:  
Bursty Traffic can be sent in large or small bursts, depending on the application.  
Bandwidth Greedy Transmission Control Protocol (TCP) applications attempt to use as much  
bandwidth as the network allows.  
Packet Loss Insensitive The retransmission capabilities of TCP allow data to continue to work  
correctly even with packet loss on the network.  
Delay Insensitive Most TCP applications can handle some packet delay without effecting overall  
performance.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Voice traffic can be classified with the following characteristics:  
Smooth VoIP packets are sent at consistent intervals with uniform packet sizes.  
Benign VoIP packets only attempt to use the bandwidth necessary to send from end to end. VoIP  
does not use any windowing to determine data rates.  
Packet Loss Sensitive VoIP traffic is extremely sensitive to packet loss. Excessive loss degrades  
overall voice quality.  
Delay Sensitive While VoIP can tolerate some amount of delay, excessive delay or excessive delay  
variation (jitter) degrade overall voice quality.  
User Datagram Protocol (UDP) Best Effort VoIP sends Real Time Protocol (RTP) packets using  
UDP. UDP does not have a mechanism to retransmit lost packets.  
The network guidelines defined by Cisco AVVID for proper VoIP operation are as follows:  
Delay Not to exceed 150 ms (one way).  
Delay Variation (Jitter) Not to exceed 30ms.  
Packet Loss Not to exceed 1 percent.  
Note: While isolated testing may show that VoIP calls could operate in a network outside of these guidelines,  
deploying a VoIP network under those conditions cannot be predictably engineered. Support from the Cisco  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Technical Assistance Center (TAC) (if problems arise) is limited for this situation.  
Security for the Cisco 7920 and WLAN Networks  
The Cisco 7920 is supported in the architecture of the Cisco Wireless Security Suite.  
The architecture is discussed in detail in documents for Wireless LAN Security Solution.  
The architecture fits into the overall Cisco SAFE security architecture. For more information, refer to Cisco  
SAFE: Wireless LAN Security in Depth.  
Note: The Cisco 7920 does not support Cisco Temporal Key Integrity Protocol (TKIP) or Cisco Message  
Integrity Check (MIC) in the initial software release. Future versions of the Cisco 7920 software will add  
support for TKIP and MIC as well as Wi−Fi Protected Access (WPA).  
The Cisco 7920 supports both static Wired Equivalency Protocol (WEP), 802.1, and Extensible  
Authentication Protocol (EAP) − Cisco Light Extensible Authentication Protocol (LEAP) for authentication  
and data encryption. When either encryption model is used, both the signaling (Signaling Connection Control  
Part (SCCP)) and media (RTP) are encrypted between the Cisco 7920 and AP.  
Static WEP requires that a 40 or 128 bit key be manually entered on all of the Cisco 7920s as well as the APs.  
It performs AP−based authentication based on the device (such as the Cisco 7920) having a matching key.  
LEAP allows devices (such as the Cisco 7920 and the AP) to be mutually authenticated (Cisco 7920 > AP, AP  
> Cisco 7920) based on a username and password. Upon authentication, a dynamic key is used between the  
Cisco 7920 and the AP to encrypt traffic.  
If LEAP is used, a LEAP−compliant RADIUS server such as the Cisco Secure ACS for Windows, is required  
to provide access to the user database. The ACS server can either store the username and password database  
locally, or it can access that information from an external Microsoft Windows directory.  
Note: While it is a valid configuration option, it is not recommended that an external (off ACS) database be  
used to store the username and password credentials for Cisco 7920 phones. Because the ACS server must be  
queried whenever the Cisco 7920 roams between APs, the unpredictable delay to access this external database  
could cause excessive delay and poor voice quality.  
The placement of the ACS server should be considered when deploying LEAP. This is because LEAP  
authentication is required every time a Cisco 7920 roams between APs, and RTP traffic (voice) does not flow  
until the LEAP authentication is completed. Reducing the amount of delay (such as router hops and WAN  
links) between APs and the ACS significantly improves the overall voice quality when Cisco 7920 users are  
roaming..  
The three options for deploying the ACS functionality are as follows:  
Centralized ACS server All users access the ACS server in a central location within the network.  
Remote ACS server For remote offices that have slow speed WAN links or congested WAN links  
that might delay LEAP processing, a ACS server could be deployed locally in the office.  
Local and Fallback RADIUS server functionality in a Cisco AP In Cisco IOS® Software  
Release 12.2(11)JA , the Cisco AP supports the ability to authenticate LEAP users without having to  
access an external ACS server. This functionality supports up to 50 users, and is supported for  
EAP−Cisco (LEAP) only. This functionality does not interact with a centralized or remote ACS  
server in terms of database synchronization. This functionality is designed to be used as the primary  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
RADIUS functionality in a small office, but could also be used as a ACS server in case of WAN  
failure.  
The following is a step−by−step example of configuring the fallback RADIUS server for LEAP  
authentication:  
1. Configure the Network Access Server (NAS), by issuing the following commands:  
radius−server local  
nas 192.168.10.35 key Cisco  
nas 192.168.10.45 key Cisco  
2. Configure the user database, by issuing the following commands:  
radius−server local  
user BM−AP1200−one−SCM password Cisco  
user BM−AP1100−two−SCM password Cisco  
user testuser password Cisco  
3. Configure the local RADIUS server in the APs RADIUS server list, by issuing the following  
commands:  
aaa group server radius rad_eap  
server 192.168.10.45 auth−port 1812 acct−port 1813  
radius−server host 192.168.10.45 auth−port 1812 acct−port 1813 key Cisco  
4. Configure the RADIUS server timeouts, by issuing the following commands:  
radius−server deadtime 10  
5. Disable client holdoff, by issuing the following command:  
no dot11 holdoff−time  
Network Sizing  
Outside of normal IP Telephony design guidance for sizing (such as a Public Switched Telephone Network  
(PSTN) gateway ports, transcoders, and WAN bandwidth), there are several 802.11b specific considerations  
to address.  
Number of 802.11b Devices per AP  
Between 15 to 25 802.11b devices per AP is recommended. Normal caveats apply in terms of traffic types,  
usages patterns, and physical space coverage.  
Number of 802.11b IP Phones per AP  
Before any discussion about network planning can take place, it helps to understand the basics of the overall  
network capacity. The chart below shows the theoretical maximum throughput of an 802.11b WLAN  
network. The highlighted sections show the data that is relevant for the packet sizes of VoIP traffic (G.711  
and G.729).  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
One of the key aspects when calculating network capacity for 802.11b networks is that it is a shared medium.  
Because of this, consideration must be given for radio contention among the various devices. This means that  
the back−off algorithms in 802.11b, that allow multiple devices to access the medium, affect the overall  
throughput.  
For the VoIP calculations below, a VoIP call has the following characteristics:  
1. The packets are made up of a 20 byte IP header, an 8 byte UDP header, a 12 byte RTP header, and the  
RTP data.  
2. The RTP data is a 20ms voice sample. For G.729, this is 20 bytes. For G.711, this is 160 bytes.  
3. The total VoIP packet is 200 bytes of (IP+UDP+RTP) headers + RTP data. The 802.11 header (Layer  
2 MAC) is 24 bytes long, so the total packet is 224 bytes.  
4. RTP data is transmitted at 50 packets per second (pps) in each direction, or 100pps for a full−duplex  
conversation.  
Looking at the 11Mb column of the chart, we can make the following calculations for G.711:  
256 byte packet size = 2,596,588 bits per second = 324,573 bytes per second (Theoretical packet rate)  
100 packets per second * 224 bytes per packet = 22,400 bytes per second (Bandwidth of a G.711  
VoIP call)  
324,573 / 22,400 = 14.489 calls (Theoretical maximum VoIP capacity per 802.11b channel)  
14.489 * .6 = 8.69 calls (Theoretical maximum number of VoIP calls * 60 percent of the bandwidth)  
Note: Sixty percent of the bandwidth is used to calculate the number of VoIP calls, which allows for  
the following:  
It allows bandwidth to be available for data traffic.  
It provides bandwidth consideration for 802.11b management traffic and acknowledgements.  
The design consideration for G.711 calls is not to exceed seven concurrent VoIP calls per AP. This number  
has been proven in lab testing to provide acceptable voice quality.  
The design consideration for G.729 calls is not to exceed eight concurrent VoIP calls per AP. This number has  
been proven in lab testing to provide acceptable voice quality.  
Note: The following information affects Voice Activity Detection (VAD) configuration:  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
All of the above calculations and design recommendations are based on VAD being disabled on the Cisco  
7920 IP Phones. VAD is a mechanism in VoIP where no RTP packets are sent if no speech is occurring  
during the conversation.  
VAD can be enabled on the Cisco 7920 phones and provides some bandwidth conservation, typically around  
30 percent. With VAD enabled on the Cisco 7920, it does not use VAD for transmit (Tx) packets, but it  
understands what to do on the receive (Rx)−side if VAD is being used by the remote device (such as  
understanding the Service ID (SID) bit).  
VAD is a global parameter on Cisco CallManager for all phones registered with a specific server or cluster.  
And the general design guidance for wired AVVID networks is to disable VAD because it can provide better  
overall voice quality. This means that unless the Cisco 7920 phones are going to register to a separate Cisco  
CallManager server than wired Cisco 79xx IP Phones, the VAD setting must be the same for all Cisco 79xx  
phones.  
Beyond determining how much bandwidth is needed for an 802.11b VoIP call, consideration must also be  
made for the overall radio contention for a particular RF channel. The general rule is that no more than 15 to  
25 802.11b end−points should be deployed per AP. As more end−points are added to an AP, the amount of  
overall bandwidth is reduced and transmission delays potentially increase.  
The number of phones per AP is dependent on calling patterns of individual customers (Erlang ratios). Cisco  
Enterprise Solutions Engineering (ESE) recommends no more than seven calls (concurrent) using G.711, or  
eight calls (concurrent) using G.729. Beyond that number of calls, when background data is present, the voice  
quality of all calls becomes unacceptable.  
Packetization rates for this testing were done with 20ms sample rates. This generates 50pps in each direction.  
VAD was disabled during the testing. Using large sample sizes (such as 40ms) could result in a larger number  
of simultaneous calls, but it also increases the end−to−end delay of the VoIP calls.  
These testing results come from the creation of traffic simulating normal desktop traffic for 15 to 20 users  
(such as HTTP, FTP, Simple Mail Transfer Protocol (SMTP), Point of Presence (POP), Telnet 3270  
(TN3270)), and then adding incremental Cisco 7920 phones. The number of Cisco 7920s phones added (with  
active calls) stopped when the Mean Opinion Scores (MOSs) dropped below the average MOS for G.711 or  
G.729 calls on the wired network.  
Numbers of 802.11b Phones per Layer 2 Subnet or VLAN  
The number of 802.11b phones that should be deployed per Layer 2 subnet or VLAN is dependent on the  
following factors:  
No more than 30 APs should be deployed per Layer 2 subnet or VLAN. This is the recommendation  
to optimize memory and performance on the APs.  
No more than seven (G.711) or eight (G.729) active calls should be deployed per AP.  
The calling ratio used to determine active versus non−active calls. This is often determined using  
Erlang calculators.  
Based on these factors, and normal business−class Erlang ratios (3:1 through 5:1), it is recommended not to  
exceed 450 to 600 Cisco 7920s per Layer 2 subnet or VLAN.  
Note: The limitation of 30 APs per subnet or VLAN is introduced due to new functionality added to Cisco  
WLAN clients (such as PCs) and Cisco APs. The functionality is called Secure Fast Roaming, and introduces  
a new WLAN architecture that reduces the amount of time it takes a WLAN client to roam between APs. The  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
30 AP limit is due to memory and processor constraints on the Wireless Domain Server (WDS), which is AP  
functionality to provide this enhanced roaming and security. This functionality is introduced into Cisco IOS  
Software Release 11.2(11)JA on the Cisco APs.  
Deployments that do not require this functionality, or have a physical area that requires more than 30 APs of  
coverage, can disable the WDS or Secure Fast Roaming functionality on the APs. This eliminates the  
limitation of 30 APs in the subnet or VLAN.  
In the future, as WDS functionality is migrated to faster processing devices within the network, the 30 AP per  
subnet limitation will be expanded or removed. For more information on this, refer to Cisco Structured  
Wireless Aware Network (SWAN) Overview.  
Understanding Layer 2 and Layer 3 Roaming  
One of the obvious benefits of WLAN IP phones over wired IP phones is the ability to physically move from  
place to place while having a conversation. However, unlike cellular phone services, where coverage areas are  
usually nationwide or international, WLAN IP phones have smaller coverage areas. In addition, administrators  
of WLAN IP phone networks need to understand and consider their IP addressing schemes before deploying  
WLAN IP phones. What needs to be considered is how WLAN IP phone coverage overlays with the Layer 2  
and Layer 3 addressing within the IP network. An Layer 2 network is defined as being a single IP subnet and  
broadcast domain. An Layer 3 network is defined as the combination of multiple IP subnets and broadcast  
domains.  
Understanding Roaming Terminology  
When discussing the term roaming, it is often good to understand the audience and their understanding of the  
term. For people that mostly work with voice systems, they often associate roaming with the concept of  
physical movement and from where a call can be originated. For people that mostly work with 802.11 data  
networks, they also often associate roaming with the concept of physical movement, but they often associate  
this with data connectivity while physically moving.  
To simplify the terminology, the following two terms are introduced:  
Pre−Call Roaming This is when a user with a Cisco 7920 physically moves from place to place  
(within a campus or between sites) before making a voice call. This roaming may be within an Layer  
2 VLAN, or across Layer 3 subnet boundaries. If this is within an Layer 2 VLAN, the IP address on  
the Cisco 7920 remains the same. If it is across an Layer 3 boundary, and Dynamic Host  
Configuration Protocol (DHCP) is enabled on the Cisco 7920, the Cisco 7920 recognizes that it is no  
longer in the previous subnet and uses DHCP to obtain a new IP address.  
Note: The process by which the Cisco 7920 recognizes that it is no longer in the correct subnet works  
as follows:  
1. The Cisco 7920 does not received SCCP keepalive messages from the Cisco CallManager  
that it is registered with (30 to 90 seconds).  
2. It attempts to re−register with an alternate Cisco CallManager (30 to 60 seconds).  
3. It realizes that it cannot reach the Cisco CallManager through the IP address and requests a  
new IP address using DHCP.  
Mid−Call Roaming This is when a user with a Cisco 7920 physically moves from place to place  
(within a campus or between sites) while a voice call is active on the phone.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Note: Any references to roam or roaming throughout the remainder of this document is in the context  
of mid−call roaming.  
As it relates to roaming, the Cisco 7920 IP Phone currently only supports Layer 2 roaming. This means that a  
Cisco 7920 IP Phone can roam between APs that have coverage for a single Layer 2 subnet, but calls are  
dropped when the phone roams into the AP coverage for another Layer 2 network.  
Layer 2 Roaming  
Layer 2 Roaming occurs when a WLAN device, for example the Cisco 7920, physically moves enough that its  
radio associates to a different AP. The original and the updated AP offer coverage for the same IP subnet, so  
that the WLANs client are still valid after the roam.  
The Cisco 7920 performs an Layer 2 roam for the following reasons:  
When the Cisco 7920 initially boots, this is considered a roaming event because it is associating with  
a new AP.  
The Cisco 7920 does not receive beacons from the associated AP, and therefore believes that the AP  
is no longer available. If three consecutive beacons are not received by the Cisco 7920, and its unicast  
packet to the AP is not acknowledged, the Cisco 7920 begins the roaming process to another AP.  
The Cisco 7920 periodically scans for better APs. Because the initial startup is considered to be a  
roaming event, all client stations have roamed at least once. After the roam process has completed, the  
client station maintains the list of eligible roam targets. When all AP information is received (channel  
update, current AP update), the phone evaluates its current AP with the list of eligible roam targets. If  
conditions change on the current AP (RSSI low or QBSS high) so that one of the APs in the client's  
stored list now appears to be a better choice than the current AP, the phone starts a handoff procedure  
to associate with the AP.  
The Service Set Identifier (SSID) or encryption type on the Cisco 7920 has changed.  
Once one of the events above occurs, the Layer 2 roaming process proceeds as follows:  
1. The Cisco 7920 looks at its list of eligible roam targets (APs with a matching SSID or encryption  
type) and chooses the best candidate. The Cisco 7920 then attempt to associate and authenticate to  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
this AP. If either the association or authentication fails, it continues to try the next best AP.  
Note: As a Cisco 7920 roams between APs, it re−authenticates with each new AP.  
2. AP B sends a null MAC multicast using the source address of the Cisco 7920. This updates the  
Content Addressable Memory (CAM) tables in upstream switches and directs further LAN traffic for  
the Cisco 7920 to AP B, and not AP A.  
3. AP B sends a MAC multicast using its own source address telling the old AP that AP B now has the  
client associated to it. AP A receives this multicast and removes the client MAC address from its  
association table. This message uses the Inter−AP Protocol (IAPP).  
In trying to determine potential candidate APs for Layer 2 roaming, the Cisco 7920 uses several variables to  
determine the best AP to associate with. The variables are RSSI and QBSS. Definitions of these terms follow:  
RSSI This is used by the Cisco 7920 to determine the signal strength and quality of available APs  
within an RF coverage area. The Cisco 7920 attempts to associate with the AP that has the highest  
RSSI value (and matching authentication or encryption Type).  
QBSS This is a beacon Information Element (IE) that allows the AP to communicate the Channel  
Utilization (CU) to the Cisco 7920. The Cisco 7920 uses the QBSS value to determine if it should  
attempt to roam to another AP, as APs with high CU may not be able to effectively handle VoIP  
traffic.  
When roaming, the Cisco 7920 uses the following model to determine which AP should be used as the  
handoff candidate:  
1. Determine which APs are advertising QBSS in their beacons. These should be considered handoff  
candidates before APs that are not advertising QBSS. If any of these meet the threshold criteria, begin  
the roaming process.  
2. If no APs advertise QBSS, or those advertising do not meet the threshold criteria, look for APs that  
are not advertising QBSS but have acceptable RSSI levels.  
The amount of time it takes for the Cisco 7920 to roam between APs is dependent on the security model used  
(average times):  
Layer 2 roaming with static WEP: less than 100ms.  
Layer 2 roaming with LEAP (local ACS authentication): 200 to 400ms  
Note: Delay times with LEAP could be longer than 200 to 300ms if the ACS server is heavily used by other  
applications (such as remote access dial−up or VPN, or TACACS authentication).  
Layer 2 roaming time is the time between the last RTP packet seen on AP1 and the first RTP packet seen on  
AP2. It also includes the times it takes to re−authenticate and reassociate with AP2.  
The following image shows a sample trace of a Cisco 7920 roaming to a new AP and the LEAP messaging  
that is between the Cisco 7920 and the AP:  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Layer 2 roaming with both static WEP and LEAP has been shown to provide acceptable QoS using either  
G.711 or G.729. If LEAP is being used, it is recommended that users are defined locally on the ACS server.  
This is because using off−box databases have potentially unknown response times, which could adversely  
effect overall QoS during Layer 2 roaming.  
Layer 3 Roaming  
Layer 3 roaming occurs when a client moves from an AP that covers IP subnet A to an AP that covers IP  
subnet B. At this point, the client would no longer have an IP address or default gateway that is valid within  
the new IP subnet. Since the clients IP address and default gateway are no longer valid, its existing data  
sessions or VoIP calls fail since the remote client can no longer reach the local client.  
There are the following ways that clients can work in an environment where they are roaming across Layer 3  
boundaries:  
Obtain a new IP address or default gateway in the new subnet through DHCP. While this is supported  
on some operating systems, it is not an effective model for VoIP since it would break all existing calls  
(signaling and media).  
Mobile IP (MIP) is a mechanism where routers within the network allow end points to keep their  
existing IP address or default gateway, and the routers handle rerouting packets to the clients on their  
new IP subnet. MIP requires Home Agent and (optionally) Foreign Agent functionality on the routers,  
as well as a MIP client on the end points. This functionality is not supported on the Cisco 7920.  
Proxy MIP (PMIP) provides similar functionality to MIP, except that the end points do not have to have an  
embedded MIP client. The MIP client is contained in a network device, such as an AP, and that device acts as  
a MIP proxy for the end points that reside behind it. PMIP is currently supported on Cisco APs, but it is  
currently not supported for VoIP applications.  
The Cisco 7920 does not currently support native Layer 3 roaming using MIP. In addition, the current lack of  
VLAN support on the Cisco APs when using PMIP prevents the Cisco 7920s from being deployed for Layer 3  
roaming. The use of VLANs to create isolated voice and data traffic is required by Cisco AVVID design  
guidelines.  
Note: In multistory WLAN deployments where the WLANs on each floor have different subnets, particular  
care needs to be taken in the RF site survey to ensure that stations on one floor do not roam to WLANs on  
floors above or below.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
VLANs  
VLANs are used by WLAN networks to provide two distinct functions:  
Segment traffic into distinct broadcast domains (IP subnets).  
Create separate security domains for different security models (such as open, WEP, LEAP, Protected  
Extensible Authentication Protocol (PEAP), EAP Transport Layer Security (EAP/TLS))  
The Cisco AVVID design guide states that separate VLANs should be created for voice and data traffic. This  
allows appropriate QoS to be provided to different classes of traffic as well as addressing issues such as IP  
addressing, security, and network dimensioning.  
Cisco AP350, AP1100, and AP1200 support up to 16 VLANs. Cisco APs can be connected to Cisco Catalyst  
switches through 802.1q trunks (hybrid mode: native VLAN (Port VLAN ID (PVID)) is not tagged). Each  
VLAN is then mapped to a unique SSID on the AP. Users (or IP phones) can then be assigned to VLANs  
based on either static configuration of SSID or dynamically though the use of RADIUS authentication. Each  
VLAN can use a different security mechanism, although only one can be unencrypted (open). The following  
is an example of configuring VLANs on VxWorks−based APs (AP350 or AP1200):  
The following is an example of configuring VLANs on Cisco IOS Software−based APs (AP1100 or AP1200):  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
For more details on deploying VLANs in WLAN networks, refer to the Wireless Virtual LAN Deployment  
Guide.  
WLAN QoS for VoIP  
As mentioned earlier, WLANs operate as a shared medium. This means that QoS on WLAN networks are  
more difficult than wired networks because end points do not have dedicated bandwidth for sending and  
receiving traffic. The following is a list of characteristics of a wired VoIP QoS:  
Dedicated access per user or device (switched ethernet, Point−to−Point (P2P) WAN).  
Packets marked with 802.1p and IP Type of Service (ToS) or Differentiated Services (DiffServ).  
Can provide hard QoS.  
QoS can be applied to upstream or downstream traffic.  
Can provide hard admission control.  
The following is an example of characteristics of WLAN VoIP QoS:  
Shared access to bandwidth.  
Packets marked with 802.1p and IP ToS or DiffServ.  
Provides soft QoS.  
QoS is currently available to downstream traffic from the AP, but few devices other than the Cisco  
7920 provide upstream QoS toward the AP.  
Can only provide limited admission control.  
Unlike networks with dedicated bandwidth, WLAN networks have to consider traffic direction when  
discussing QoS. Traffic needs to be considered as either upstream or downstream from the point of view of  
the AP, as shown in the following example:  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Before discussing how WLAN QoS works, you must first understand how end points transmit data on WLAN  
networks. Similar to wired Ethernet networks, 802.11b WLANs employ Carrier Sense Multiple Access  
(CSMA). However, instead of using Collision Detection (CD), WLANs use Collision Avoidance (CA). This  
means that instead of each station trying to transmit as soon as the medium is free, WLAN devices use a CA  
mechanism to prevent multiple stations from sending at the same time.  
The model used for WLAN data transmission is called Distributed Coordination Function (DCF). The  
following image is an example of 802.11b DCF:  
DCF ensures that the following events occur when the end points try to transmit data:  
1. After the previous frame has been transmitted and detected by the other end points, each end point  
waits for a period of time called Inter−Frame Space (IFS).  
2. There are the following three potential values for IFS:  
Short IFS (SIFS) The shortest interval. It is used by APs to send acknowledgements and  
management traffic.  
Point Coordination IFS (PIFS) This is not used by commercial products.  
Distributed IFS (DIFS) DIFS is the interval used by most other end points.  
3. After the IFS interval has expired, the end points begin their CA procedure. This procedure uses two  
values, called aCWmin and aCWmax. The Contention Window (CW) determines what additional  
amount of time an end point should wait, after the IFS, to attend to transmit a packet. The value of the  
CW used is determined by the following:  
1. Each end point has the values for aCWmin and aCWmax defined.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
2. After the IFS expires, the end point selects a value between 0 and aCWmin. The end point  
waits the length of this value and determines if the medium is available to transmit.  
3. If the medium is available, the end point transmits the packets.  
4. If the medium is unavailable (such as if another device sent a packet), the end point waits  
until the end of the packet transmission (from another device) and the IFS period. In addition,  
it doubles the value chosen in Step 2 and then attempts to transmit.  
5. The end point continues to double the value from b until it either reached aCWmax or the  
packet is transmitted.  
The following shows the growth in the random backoff range with retries:  
For WLAN QoS, Cisco APs and Cisco 7920 phones use a technique similar to IEEE 802.11e, called  
Enhanced DCF (EDCF). EDCF is a model that allows end devices that have delay sensitive multimedia traffic  
to modify their aCWmin and aCWmax values to allow for statically greater (and more frequent) access to the  
medium. The following is an example of how EDCF works on Cisco WLAN devices:  
By default, end points usually have aCWmin and aCWmax values of 31 and 255, respectively, for all data  
traffic. For VoIP traffic, Cisco APs and Cisco 7920s set the aCWmin and aCWmax to values of 3 and 31,  
respectively. This is equivalent to CoS of 6. Cisco IOS Software based APs can also vary the IFS (in addition  
to the aCWmin and aCWmax).  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Cisco Aironet APs support a QoS similar to EDCF as of Cisco IOS Software Release 12.0T SW. This  
provides up to eight queues for downstream (toward the 802.11b clients) QoS. These queues can be allocated  
in the following ways:  
Based on ToS or DiffServ settings of packets.  
Based on Layer 2 or Layer 3 Access Control Lists (ACLs).  
Based on the VLAN.  
Based on the dynamic registration of devices such as the Cisco 7920 IP Phone.  
Although eight queues are supported on the AP, it is recommended to only have two queues for traffic on the  
AP to ensure the best possible voice QoS. Voice (RTP) and signaling (SCCP) traffic should be placed into the  
highest priority queue. All data traffic should be placed into a best effort queue. While 802.11b EDCF does  
not guarantee that voice traffic is protected from data traffic, using this queuing model should provide the best  
statistical results for voice QoS.  
The Cisco 7920 IP Phones support a QoS similar to EDCF for upstream (toward the AP) traffic. In additional,  
the Cisco 7920 dynamically announces its presence with the Cisco Aironet AP to ensure its downstream  
traffic is placed into the high priority queue on the AP. This dynamic announcement is done through Cisco  
Discovery Protocol (CDP). The CDP packets are sent from the Cisco 7920 to the AP and identify the phone  
so that the AP can place all traffic to the phone in the high priority queue.  
The SCCP signaling messages are marked with DiffServ Assured Forwarding (AF)31, and RTP packets are  
marked with DiffServ Expedited Forwarding (EF). This matches the DiffServ markings of Cisco wired  
Ethernet IP phones, and allows the QoS settings to be consistent from LAN to WLAN environments.  
In addition to setting the DiffServ markings correctly and supporting a QoS similar to EDCF, the Cisco 7920  
also supports an intelligent mechanism to determine the QoS that can be provides by a given AP. It does this  
based on an algorithm that takes into consideration RSSI and RF CU based on updates received by the Cisco  
AP in beacon messages using the QBSS element. Based on this information, the Cisco 7920 can determine if  
the load on a given AP is excessive and if it should attempt to associate with a less congested AP in order to  
preserve the QoS of an IP Telephony call. The following is an example of configuring the QBBS element in  
beacons on VxWorks−based APs:  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
The following is an example of configuring the QBBS element in beacons on Cisco IOS Software−based APs:  
Beyond just having queuing and setting packets with the correct DiffServ markings, delay and jitter need to be  
taken into consideration. This is especially true for upstream traffic since there is no queuing among clients on  
the 802.11b side of the AP. The simplest way to accomplish this is to stay within the guidelines for the  
number of WLAN clients per AP. Exceeding this creates additional opportunities to introduce packet delay  
and jitter.  
For more details about deploying QoS in WLAN networks, refer to the Wireless Quality−of−Service  
Deployment Guide.  
Interconnecting WLANs to Cisco Campus Infrastructure  
This section contains pre−tested, recommended configurations. This helps you to quickly and simply build  
and deploy a Cisco approved network design using Catalyst 3550 and 2950 series Intelligent Ethernet  
Switches.  
By following the information in this section, you can create a Cisco AVVID Network Infrastructure to run  
converged voice, video, and data network over IP, with due consideration for QoS, bandwidth, latency, and  
high performance in demand by Cisco AVVID Network Infrastructure solutions.  
The AP template should be configured when a single AP is attached to a port. This template adds all the  
baseline security and resiliency features of the standard desktop template, but for the Catalyst 3550, it also  
optimizes the performance of the attached AP.  
Ethernet switch ports can transmit and receive at 100Mbps. However, APs, depending on the type (802.11b),  
only have a practical throughput of 6Mbps or less. This throughput mismatch means that with a burst of  
traffic, the AP needs to do packet drops, which adds an excessive processor burden to the unit and affects  
performance.  
By taking advantage of the Catalyst 3550 policing and rate limiting capabilities, the task of dropping  
excessive packets is removed from the AP. This template rate limits the port to the practical throughput of 6M  
and guaranteeing 1Mbps for high priority voice and control traffic. Because of this prioritization, this template  
can be used with wireless IP telephones.  
The 3550−24−PWR in−line power switch can be used to provide power to the AP.  
This template helps create a secure and resilient network connection with the following features:  
Return Port Configurations to Default Prevents configuration conflicts clearing any pre−existing  
port configurations. This allows you to start with a clean slate.  
Disable Dynamic Trunking Protocol (DTP) Disables trunking, which is not needed for a  
connection to an AP.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Disable Port Aggregation Protocol (PagP) − PagP is enabled by default, but it is not needed for  
user−facing ports.  
Enable Port Fast Allows a switch to quickly resume forwarding traffic if a Spanning Tree Protocol  
(STP) link goes down.  
Configure Wireless VLAN Creates a unique wireless VLAN that isolates wireless traffic from  
other data, voice, and management VLANs, thereby isolating traffic and ensuring greater control of  
traffic.  
Enable QoS, and Do not Trust the Port (mark down to 0) Ensures appropriate treatment of high  
priority traffic, including soft phones, and prevents users from consuming excessive bandwidth by  
re−configuring their PCs.  
Connecting APs to the Catalyst 3550 SMI or EMI  
The following configuration is a reference template for use on Catalyst switch ports that are connected to  
Cisco APs. It provide the required configurations for security, QoS, and STP:  
default interface <xx/yy>  
switchport mode access  
spanning−tree bpduguard [enable]  
spanning−tree bpdufilter [enable]  
no channel−protocol  
spanning−tree portfast  
vlan [vlan id]  
mls qos  
auto qos voip trust  
mls qos map cos−dscp 0 10 18 26 34 46 48 56  
mls qos aggregate−police AGG−POL−5M−DEFAULT 5000000 8000 exceed−action drop  
class−map match−any EGRESS−DSCP−0  
match ip dscp 0  
class−map match−any EGRESS−DSCP−10  
match ip dscp 10  
class−map match−any EGRESS−DSCP−56  
match ip dscp 56  
class−map match−any EGRESS−DSCP−26  
match ip dscp 26  
class−map match−any EGRESS−DSCP−18  
match ip dscp 18  
class−map match−any EGRESS−DSCP−48  
match ip dscp 48  
!
policy−map EGRESS−POLICING  
class EGRESS−DSCP−0  
police aggregate AGG−POL−5M−DEFAULT  
class EGRESS−DSCP−10  
police aggregate AGG−POL−5M−DEFAULT  
class EGRESS−DSCP−18  
police aggregate AGG−POL−5M−DEFAULT  
class EGRESS−DSCP−34  
police aggregate AGG−POL−5M−DEFAULT  
class EGRESS−DSCP−48  
police aggregate AGG−POL−5M−DEFAULT  
class EGRESS−DSCP−56  
police aggregate AGG−POL−5M−DEFAULT  
!
interface [interface id]  
description 11m Towards Wireless Access Point  
no ip address  
mls qos monitor dscp 0 10 18 26 34 46 48 56  
service−policy output EGRESS−POLICING  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
wrr−queue cos−map 4 5  
priority−queue out  
Connecting APs to the Catalyst 2950 EI  
The following configuration is a reference template for use on Catalyst switch ports that are connected to  
Cisco APs. It provide the required configurations for security, QoS, and STP:  
default interface <xx/yy>  
switchport mode access  
spanning−tree bpduguard [enable]  
spanning−tree bpdufilter [enable]  
no channel−protocol  
spanning−tree portfast  
vlan [vlan id]  
auto qos voip trust  
Connecting APs to the Catalyst 2950 SI  
The following configuration is a reference template for use on Catalyst switch ports that are connected to  
Cisco APs. It provide the required configurations for security, QoS, and STP:  
default interface <xx/yy>  
switchport mode access  
spanning−tree bpduguard [enable]  
spanning−tree bpdufilter [enable]  
no channel−protocol  
spanning−tree portfast  
vlan [vlan id]  
Using Cisco Emergency Responder for E911 calls with the  
Cisco 7920  
The Cisco Emergency Responder proactively queries Cisco CallManager for new phone and user login  
registration events. In response to these events, Cisco Emergency Responder automatically searches known  
Cisco Catalyst switches in the network and finds the location of the phone and the user, based on the switch  
port to which the phone is attached (through CDP or the MAC address). This information is then updated in a  
Cisco Emergency Responder location database, and is used to identify a caller s location when an E911 call  
is placed. With this solution, users can move within a campus or between sites, wherever and whenever they  
want, without any administrative intervention from the IT organization. This eliminates the administrative  
costs associated with relocating phones or users, while maintaining accurate and updated location information  
for E911 state and safety mandates.  
Cisco Emergency Responder makes informed inbound and outbound call routing decisions based on the  
location of emergency callers, and provides crucial location information to emergency operators in Public  
Safety Answering Points (PSAPs). Outbound emergency calls are directed to a gateway associated with the  
PSAP that is nearest to the caller, and in the event of an unintentional call disconnect or need for additional  
information, inbound calls from a PSAP are returned to the original caller.  
For more information, refer to product literature for the Cisco Emergency Responder.  
For Cisco 7920 phones, several guidelines should be followed to accommodate the roaming nature of 802.11b  
phones.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Cisco Emergency Responder can query for IP Phones through either CDP (on the Catalyst switches)  
or the MAC address. Since CDP is sent as a link−layer multicast and is used by the Cisco AP to  
determine the QoS settings for the Cisco 7920, it is not propagated up to the Catalyst switch. This  
means that Cisco Emergency Responder should query the Catalyst switches for the MAC addresses of  
the Cisco 7920 phones.  
Cisco Emergency Responder groups devices into Emergency Response Locations (ERL) so they can  
be identified by a physical location (such as building, floor, or region of floor). Depending on how the  
power levels are configured on the Cisco APs, it is possible that the signal could propagate to floors  
above or below the actual AP that the Cisco 7920 is associated with. Using antennas that propagate  
RF signal in a more horizontal pattern helps alleviate this, but emergency personnel within a building  
should be made aware of this when organizing their searches for the individual or device that initiated  
the emergency call.  
An E911 coverage policy is an individual decision that each company needs to make and adapt it to their  
physical locations.  
It is recommended that each AP been assigned to its own ERL (or minimally grouping a couple of adjacent  
APs into one ERL). This has the benefit of allowing on−site, and potentially PSAP personnel, to identify that  
the caller is using a wireless device (by using a code or abbreviation in the Automatic Location Information  
(ALI) or switch port location field). This is important information for first responders because it means that  
adjacent floors, hallways, rooms, and even buildings may need to be searched to locate an unconscious or  
incapable caller. The following image is an example of the Cisco Emergency Responder's configuration  
Graphical User Interface (GUI):  
Caveats and Limitations  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Call Admission Control  
Call Admission Control (CAC) provides the mechanism that prevents the presence of the next voice call to  
interrupt or provide poor QoS for all existing voice calls. Regarding Time−Division Multiplex (TDM), this is  
accomplished by a finite number of DS0 channels. In wired Ethernet AVVID networks, this is provided by an  
interaction between the Cisco CallManager regions and Cisco H.323 gatekeepers. However, these  
mechanisms only address CAC for the initial setup of IP Telephony calls. They do not address CAC when the  
underlying network is changing for the IP phone throughout the call. This is the case when a Cisco 7920  
roams between two APs.  
While the Cisco APs does send out QBSS information about the CU, and the Cisco 7920 can utilize this  
information to determine the best AP to associate with, this does not provide a 100 percent guarantee that calls  
retain proper QoS during a roam between APs. One example of when this degraded QoS could occur is an  
event that causes more than seven or eight active Cisco 7920s to roam into an area served by a single AP, thus  
exceeding the guidelines for calls per AP.  
If the CU is above the CU threshold, the call is not setup and the phone displays a network busy  
message. If the CU of the candidate handoff AP is above the threshold, the Cisco 7920 remains associated  
to the existing AP for as long as possible. Once the current AP is lost (no probe response or beacons received),  
the Cisco 7920 handsoff to the candidate AP regardless of the CU. A beep is heard before this happens so the  
user can go back toward the current AP or stop and finish the conversation.  
Another area of admission control that needs to be considered with the Cisco 7920 is when a user takes the  
Cisco 7920 from one location to another (such as campus to branch). When the Cisco 7920 re−registers with  
the Cisco CallManager, there is no mechanism that updates which Cisco CallManager region (or gatekeeper  
zone) the Cisco 7920 is associated with. This means that it is possible that calls to or from that Cisco 7920  
would not properly be accounted for across a WAN link, and could cause poor voice quality to phones that are  
registered in that region.  
Designing Around the Lack of Layer 3 Roaming  
For customers that require roaming support for a large area (such as between floors of a buildings), large  
Layer 2 VLANs (spanning across access switches) can be created to eliminate the Cisco 7920s crossing an  
Layer 3 boundary when roaming. The following guidelines need to be considered for customers that are  
looking to deploy large Layer 2 VLANs:  
Cisco ESE guidelines do not recommend that data VLANs span multiple access switches.  
An Layer 2 VLAN should not cross a building boundary. If this is required, then an additional  
(overlay) Layer 2 core needs to be built to avoid creating instability and excessive traffic in the  
traditional Layer 3 core.  
Both the voice VLAN and the native VLAN on the AP need to be trunked across the large Layer 2  
VLAN. This is required to allow both voice traffic and IAPP traffic between the APs.  
Having Layer 2 VLANs span multiple access switches creates the possibility of STP loops (if  
configured incorrectly) and overall network instability. Designs using this should model should be  
reviewed with your Cisco Systems Engineer before deployment.  
For customers that may eventually be considering extending their Layer 3 networks down to the  
access switches, the model of building large Layer 2 VLANs is no longer valid.  
Other Caveats and Limitations  
The following are other things to be aware of regarding the Cisco 7920 IP Phone:  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Cisco 7920 does not support network−based directories. This will be supported in future software  
releases.  
Cisco 7920 does not support XML−based applications. This will be supported in future software  
releases.  
Related Information  
Voice Technologies  
Voice, Telephony and Messaging Devices  
Voice Software  
Voice, Telephony and Messaging TAC eLearning Solutions  
Recommended Reading: Troubleshooting Cisco IP Telephony  
Technical Support − Cisco Systems  
All contents are Copyright © 1992−2003 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.  
Cisco − Wireless IPT Design Guide for the Cisco 7920 IP Phone  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 

Blackberry Cell Phone 9790 User Manual
Black Box Musical Instrument Amplifier AC2000A User Manual
Blue Rhino Charcoal Grill NB1854WRT C User Manual
Blue Rhino Outdoor Fireplace WAF501CS User Manual
Bosch Power Tools Power Hammer 11387 User Manual
Bryant Furnace 398AAV User Manual
Carrier Portable Generator ASPB07 1SI User Manual
Casio Projector XJ S42 XJ S47 User Manual
CAT Lawn Mower 325DL User Manual
Char Broil Charcoal Grill 11401587 User Manual