Embed Size (px)
Citation preview
Effective IP PBX Deployment and Migration
Strategies
Alfredo RizzoAdapt
www.teamadapt.com [email protected] 773.634.2044
Session Outline
"Quality of Service“ (QoS) and Network Design
Quality, QoS, Measurement, and Possible Issues LAN / WAN Considerations Voice Readiness Assessment On-going Monitoring and Reporting
Network Exposure and Security The impact of NATs and Firewalls Security Best Practices
Other Issues Legacy Integration Emergency Service Cabling Power Remote Site Survivability
First, Let’s Define “Quality”
What is Quality? Quality is a characteristic that can only be measured in words, not numbers. A phone call can be “good”, “noisy”, “jittery” or “unintelligible”.
Issues that Can Affect Voice Quality
Latency – also called “delay”. Latency is measured one-way, and is the amount of time it takes for time from a sender’s mouth to arrive at the listener’s ear.
Jitter – variation in delay. Some packets may arrive at their destination before others that were sent earlier.
Bandwidth – if there is not enough bandwidth for the voice traffic, or if the bandwidth is not prioritized to give preference to the voice traffic over other types of traffice, that’s an issue.
A Way of Measuring Quality
A group of users make calls and rate them “Excellent”, “Fair”, “Poor”, etc. The quality of the calls will be the average of all their scores, or the Mean Opinion Score (MOS).
The European Telecommunications Standards Institute (ETSI) developed an accepted way of measuring voice quality called the “E-Model”, which is based on the MOS.
Delay can Affect Quality
Delay (Latency) is defined as: the amount of time it takes for
sound from a talker’s mouth to arrive at the listener’s ear.
The maximum amount of delay that is acceptable for a one-way transmission is described by the International Telecommunications Union in Document G.114
G.114
ITU Recommendation (in ms)
Private Network Recommendation (in ms)
Description
0 – 150 0 – 200 Acceptable for most applications
150 – 400 200 – 250 Acceptable provided that the administrators are aware.
400+ 250+ Unacceptable
G.114
Manage Your Delay Budget
Serialization Delay - the speed at which the router processes each packet. This adds precious milliseconds to the delay budget. Older, slower routers are not recommended for voice applications.
Packetization Delay - the amount of time it takes for the telephony device (IP Phone, Router, IP PBX) to packetize the audio sample.
Propagation Delay – the amount of time it takes for packets to travel down the medium.
Jitter
Variation in delay Caused by network congestion The receiving device must
“buffer” them so that they can be delivered in sequence to the receiving party.
Can cause jitter buffer overruns
Bandwidth
How much is enough for IP Telephony? Depends on:
• Number of simultaneous sessions• Codec(s) used• Will Voice Activity Detection (VAD) be used?• Transport Protocol (cRTP, etc.)• Control Protocol (RTCP)• Data Link Protocol (Ethernet, Serial, ATM, Frame)
Very different considerations for LAN vs. WAN
Quality of Service (QoS)
Quality Of Service (QoS) refers to the mechanisms in the network that make the actual determination of which packets have priority.
QoS policies give priority to traffic based on their relative importance to the business.
However, this only prioritizes traffic; it does not guarantee a level of bandwidth. Without guaranteed bandwidth, high priority applications will still experience performance degradation.
Traffic Shaping
Often the terms “QoS” and “traffic shaping” are used interchangeably, since most devices that support QoS also support many forms of traffic shaping.
Traffic shaping can be used to actually guarantee bandwidth for certain types of traffic and limit available bandwidth for others. Traffic shaping can provide an effective way to prevent congestion, minimizing the impact of rogue traffic on mission-critical applications. Traffic shaping can be performed by switches, routers, or dedicated devices.
LAN Considerations
Separate voice and data traffic using VLANs. All voice devices should go in the voice VLAN.
Use a discovery protocol on your switches where possible (available on Adtran, Cisco, Extreme, and other switches). This will allow the phones to identify the themselves and automatically be assigned to their VLAN.
Use DHCP where possible to hand down settings to IP phones. Gateways and servers should have static IP addresses.
Route minimal traffic from the data to the voice VLAN, using access policies on your layer 3 device.
LAN Considerations - Continued
Where to I “tag” my packets? The VoIP endpoint can tag the packet,
and the switch can trust its tagging It is also easy to tag at the switch ports,
if those are used exclusively for VoIP devices (i.e., the IP PBX).
Alternatively, QoS tags can be placed at the network level (i.e., the entire VLAN).
LAN-only traffic can use G.711, no VAD Less packetization delay Less expensive hardware
WAN Considerations – Manage your Scarcest
Resources Most Efficiently
WAN Considerations
MPLS (Multi-Protocol Label Switching) – MPLS WANs are HIGHLY recommended for
QoS enforcement on the WAN. MPLS networks enforce QoS tags set by the
originating network. This typically requires the purchase of a “Class of Service” option (more $$) to allow for some amount of bandwidth of prioritized traffic.
Unlike frame relay, MPLS is a routed network, so PVC’s are not required. This means that any site can communicate directly with any other site.
Network-based Internet access is typically also available, sometimes with a network firewall option.
WAN Considerations - Continued If using frame relay, you can use
separate PVCs for voice and data, and thus guarantee your required voice bandwidth. Or you can use a traffic shaper to prioritize traffic prior to its entering the cloud, such that voice traffic stays within CIR’s.
Protocol selection and compression algorithms are very important. Use compressed codecs (g.729, g.723) over WAN.
WAN Considerations - Continued
Routers must be capable of QoS and traffic shaping.
If using VLAN’s on your LAN, routers must be capable of VLAN trunking (802.1Q)
Codec Selection
Different considerations for LAN vs WAN As can be seen in the following table, MOS increases
as the required bandwidth for to VOIP call increases.
Codec performance will also vary by vendor, so be sure to test the codecs you are selecting on your vendors equipment and review its quality prior to cut-over.
Major Implementation Pitfalls Bad design/planning, resulting in:
Inadequate network equipment to enforce QoS and shape traffic
Insufficient bandwidth Incorrect assumptions regarding bandwidth-
affecting factors Insufficient management/reporting tools – you
must inspect what you expect Bad WAN topology – go MPLS if possible!
Lack of end-to-end adherence Within your network Within others’ (carriers, etc.) networks
Voice Readiness Assessment Several packages available. Typically consists of the assessment server
at a main site (can run on a laptop), generating VoIP calls, and agent software at other sites, receiving the calls and reporting back on key metrics.
Allow you to run the actual voice traffic that you predict you’ll have before you deploy the first IP telephony end-point.
Assesses all key voice quality indicators, and most packages also inventory network device and links in the path of voice traffic.
HIGHLY recommended.
Voice Readiness Assessment –Sample Report Graphs and Tables
Router Average CPU Utilization by Hour
0%
20%
40%
60%
80%
100%
0.0%
0.4%
0.8%
1.2%
1.6%
2.0%
Ave
rag
e C
PU
Uti
lizat
ion
(%
)
Good 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100
Acceptable 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Poor 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Unavailable 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Avg CPU Util .1% .1% .1%.2%.4%.8%1.4%1.2%1.5%1.9%1.2%1.5%1.2%1.3%1.1%1.0%.9%.5%.3%.4%.3%.2%.1% .1%
12 AM
1 AM
2 AM
3 AM
4 AM
5 AM
6 AM
7 AM
8 AM
9 AM
10 AM
11 AM
12 PM
1 PM
2 PM
3 PM
4 PM
5 PM
6 PM
7 PM
8 PM
9 PM
10 PM
11 PM
WAN Link Average Bandwidth Utilization by Hour
0%
20%
40%
60%
80%
100%
0.0%
5.0%
10.0%
15.0%
20.0%
25.0%
Ave
rag
e B
and
wid
th U
tiliz
atio
n (
%)
Good 95 98 93 95 89 83 79 88 78 70 82 75 87 83 77 81%86 93 98 91%93 93 97 98
Acceptable 5%2%7%5%8%14%14%11%15%16%13%11%6%13%13%7%9%7% 3%9%6%7%3%3%
Poor 0%0%0%0%3%3% 7%2%8%14%6%14%8%3%10%13%5%0% 0%0% 1% 0%0%0%
Unavailable 0%0%0%0%0%0% 0%0%0%0%0%0%0%0%0%0%0%0% 0%0%0%0%0%0%
Avg Bandwidth Util 2.9 2.4 4.1 4.3 7.110.216.413.419.822. 16.421.515.615.115.915.612.26.4 4.3 5.7 5.3 4.7 2.8 2.7
12 AM
1 AM
2 AM
3 AM
4 AM
5 AM
6 AM
7 AM
8 AM
9 AM
10 AM
11 AM
12 PM
1 PM
2 PM
3 PM
4 PM
5 PM
6 PM
7 PM
8 PM
9 PM
10 PM
11 PM
On-Going Monitoring and Reporting
Again, many packages available Differs from assessment packages in
that monitoring refers to measurement of voice performance on an on-going basis, on a production network
Allows you to do “what if” scenarios Allows you to report on QoS
performance and adherence to requirements
Allows you to plan for future growth
Network Exposure and Security
NAT and Firewall Issues Security Best Practices
What’s the Problem with NAT?
VoIP protocols for session control (SIP, H.323, MGCP, MEGACO) are Application Layer protocols
But IP operates at the Network Layer (Layer 3) and NAT devices change that address. Now VoIP (SIP , H.323, etc.) message
comes back to the sender’s public address, and is discarded.
What’s the problem with Firewalls?
Firewalls control all TCP and UDP port availability through policies.
Typically only certain ports (static) are allowed from certain source addresses / networks to certain destination addresses / networks.
But the RTP sessions (the actual voice stream) use two dynamically generated port addresses for each session. No two sessions will use the same port address at the same endpoint (i.e., IP PBX).
What Can We Do? The absolute simplest solution, most
widely used and recommended in an enterprise environment, is to use VPN’s to tunnel (and encrypt) traffic from an external host or network through a firewall.
Use an Application Layer Gateway (ALG) to bridge the session control protocol (SIP, H.323, etc.)
Use an RTP Relay device, such as a back-to-back user agent, to terminate RTP sessions from both endpoints (internal and external) and then bridge them.
More on Traversing Firewalls and NATs
STUN (RFC 3489) provides a way for endpoints to initiate outbound (only) call requests using their assigned public IP address in the application layer header (some limitations).
uPNP – created by an industry consortium, primarily with the goal of solving this puzzle in home networks that use a NAT device for outside communications. OS-dependent.
STUN – Binding Acquisition
Client sends STUN Request to Server
STUN Server can be ANYWHERE on Public Internet
STUN Server Response Client knows Public IP
for that Socket Client Sends INVITE
Using that IP to Receive Media
Call Flow Proceeds Normally
No Special Proxy Functions
Media Flows End-To-End
More Help is on the Way
RFC 3581 - Making SIP “NAT Friendly” “This extension defines a new
parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.”
Addresses SIP only, not RTP or other session control protocols
Security Best Practices
VLANs allow for easier securing of voice traffic. Access control on Voice VLANs keep rogue traffic (viruses, worms, etc.) out.
MAC access control to voice VLANs can be used to provide for additional security.
Port-based filtering on switch ports can be used to allow only the required traffic by the VoIP endpoints (i.e., SIP, RTP, and SSL).
SRTP (Secure RTP) is an emerging option that is being adopted quickly by vendors.
SIP provides for encrypted authentication. Most IP Phones now use signed
configuration files.
Other Issues
Legacy Integration Issues Emergency Service Issues Cabling Network Core Power Remote Site Survivability
Existing / Legacy Infrastructure Integration Issues
Typically an IP PBX deployment is a migration, so some level of integration is required between the IP PBX and existing voice platforms.
Tie lining to legacy PBX – need a gateway?
Coordinating extension and dial plans (no news here)
Messaging who does it? Will need cover paths and pilot
numbers into TUI. If both do it, will you replicate?
• AMIS – Audio Messaging Interchange Specification• VPIM – Voice Profile for Internet Mail
Support for analog devices – IP PBX must support stand-alone fax machines, modems, and analog conference phones.
Emergency Service Issues
Emergency Service (911/E911):
You will need to provide 911 service remote offices. What happens if they dial 911 from their IP Phone? What about telecommuters and mobile workers?
When the number follows the user, should 911 info? The physical location of the IP Phone must determine the emergency call route.
Some states require businesses with PBX equipment to pass 911 information to the PSAP based on the user’s specific location, subdividing larger spaces into smaller ones – i.e., floors and quadrants with different entry points.
E911 Best Practices
Ensure that all static IP Phones at a given site are hard-coded (through their configuration files) to route emergency calls through the local PSTN gateway.
Test 911 calls to make sure that the correct address comes up at the PSAP
If you will support mobile workers with soft phones, do not allow mobile workers (at hotels, airports) using soft phones to call 911 through the soft phone. Address this through training and have them sign a short notice of understanding before providing them with a soft phone.
If you allow for hard-phone mobility, ensure that 911 is addressed for phones that are moved. This can be done manually (i.e., a permanent move), or automatically through a dedicated server/application typically ($$).
Soft Phone Example – Careful of 911 Dialing from Soft Phones
Cabling
Cabling options:
Same CAT5 jack for phone and PC• Preferred configuration• Less wiring• More switch configuration – requires VLAN
trunking on each phone port• If you reboot your phone, your PC loses its
network connection
Separate CAT5 jacks for each IP phone/device.
• More wiring• Less switch configuration• Can make sense in certain situations
Power
Typically, you must maintain power to phones for several hours in the event of an outage
911 calling Business continuity, at least to a subset of
phones Possible solutions
PoE – Power over Ethernet – IEEE 802.3af• Powered Switches• In-line Powered Patch Panels
FXS Media Gateways in the closet (with UPS)
UPSs on all phones
Remote Site Survivability
At a remote site, certain features must still be available in the event that a WAN link connecting them to their IP PBX goes down.
Remote site phones should still be able to receive, transfer, and even conference (3-way) calls locally, as well as place outbound calls.
Remote site Can be vendor-specific or standards-based – i.e., SIP Proxies or Cisco SRST.
Inbound calls to the remote site should be redirected to the main site for things like voice mail and IVR.
