Transcript Effective IP PBX Deployment and Migration Strategies

Effective IP PBX Deployment
and Migration Strategies
Alfredo Rizzo
Adapt
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
Calculating Required Bandwidth
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
100%
2.0%
80%
1.6%
60%
1.2%
40%
0.8%
20%
0.4%
0%
Good
Acceptable
Poor
Unavailable
12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11
A A A A A A A A A A A A P P P P P P P P P P P P
M M M M M M M M M M M M M M M M M M M M M M M M
100 100 100 100 100 100 100 100 100 100 100 100
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
100 100 100 100 100 100 100 100 100 100 100 100
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
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%
0.0%
Average CPU Utilization (%)
Router Average CPU Utilization by Hour
100%
25.0%
80%
20.0%
60%
15.0%
40%
10.0%
20%
5.0%
0%
Good
Acceptable
Poor
Unavailable
12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11
A A A A A A A A A A A A P P P P P P P P P P P P
M M M M M M M M M M M M M M M M M M M M M M M M
95 98 93 95 89 83 79 88 78 70 82 75 87 83 77 81% 86 93
5% 2% 7% 5% 8% 14%14%11%15%16%13%11% 6% 13%13%7% 9% 7%
0% 0% 0% 0% 3% 3% 7% 2% 8% 14%6% 14%8% 3% 10%13%5% 0%
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
98 91% 93 93 97 98
3% 9% 6% 7% 3% 3%
0% 0% 1% 0% 0% 0%
0% 0% 0% 0% 0% 0%
Avg Bandwidth Util 2.9 2.4 4.1 4.3 7.1 10.2 16.413.419.8 22. 16.421.515.6 15.115.915.612.2 6.4 4.3 5.7 5.3 4.7 2.8 2.7
0.0%
Average Bandwidth Utilization (%)
WAN Link Average Bandwidth Utilization by Hour
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 backto-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 Response
Client knows Public IP for
that Socket
Client Sends INVITE Using
that IP to Receive Media
Call Flow Proceeds
Normally


STUN Server can be
ANYWHERE on Public
Internet
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 hardcoded (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.
Questions / Answers
Alfredo Rizzo
Adapt
www.teamadapt.com
[email protected]
773.634.2044