Effective IP PBX Deployment and Migration Strategies

1
(No Transcript)
2
Effective IP PBX Deployment and Migration
Strategies
Alfredo Rizzo Adapt www.teamadapt.com
alfredor_at_teamadapt.com 773.634.2044
3
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

4
First, Lets 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.

5
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 senders mouth to arrive at
  the listeners 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, thats an
  issue.

6
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.

7
Delay can Affect Quality

• Delay (Latency) is defined as
• the amount of time it takes for sound from a
  talkers mouth to arrive at the listeners 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

8
G.114
9
G.114
10
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.

11
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

12
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

13
Calculating Required Bandwidth
14
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.

15
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.

16
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.

17
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

18
WAN Considerations Manage your Scarcest
Resources Most Efficiently
19
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
  PVCs 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.

20
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 CIRs.
• Protocol selection and compression algorithms are
  very important. Use compressed codecs (g.729,
  g.723) over WAN.

21
WAN Considerations - Continued

• Routers must be capable of QoS and traffic
  shaping.
• If using VLANs on your LAN, routers must be
  capable of VLAN trunking (802.1Q)

22
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.

23
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

24
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 youll 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.

25
Voice Readiness Assessment Sample Report Graphs
and Tables
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
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

33
Network Exposure and Security

• NAT and Firewall Issues
• Security Best Practices

34
Whats 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 senders public address, and is discarded.

35
Whats 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).

36
What Can We Do?

• The absolute simplest solution, most widely used
  and recommended in an enterprise environment, is
  to use VPNs 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.

37
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.

38
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

39
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

40
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.

41
Other Issues

• Legacy Integration Issues
• Emergency Service Issues
• Cabling
• Network Core
• Power
• Remote Site Survivability

42
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.

43
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
  users specific location, subdividing larger
  spaces into smaller ones i.e., floors and
  quadrants with different entry points.

44
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 ().

45
Soft Phone Example Careful of 911 Dialing from
Soft Phones
46
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

47
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

48
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.

49
Questions / Answers
Alfredo Rizzo Adapt www.teamadapt.com
alfredor_at_teamadapt.com 773.634.2044
50
(No Transcript)