Effective Deploymennt and Migration Strategies of IPPBX

Document Sample
Effective Deploymennt and Migration Strategies of IPPBX Powered By Docstoc
					Effective IP PBX Deployment
  and Migration Strategies


                Alfredo Rizzo
                    Adapt
www.teamadapt.com      alfredor@teamadapt.com
                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   Private Network   Description
(in ms)              Recommendation
                     (in ms)

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
                    Router Average CPU Utilization by Hour




                                                                                                    Average CPU Utilization (%)
     100%                                                                                    2.0%

       80%                                                                                   1.6%

       60%                                                                                   1.2%

       40%                                                                                   0.8%

       20%                                                                                   0.4%

        0%                                                                                   0.0%
               2                   0 1 2                   0 1
              1 1 2 3 4 5 6 7 8 9 1 1 1 1 2 3 4 5 6 7 8 9 1 1
              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
Good           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
              1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
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%
               % % %              .4%1 .5%1 .2%1 .2%1  .1 .0%.9% .5% .3% .4% .3% .2% .1 .1
Avg CPU Util .1 .1 .1 .2% .4% .8%1 .2%1 .9%1 .5%1 .3%1 %1                              % %
               WAN Link Average Bandwidth Utilization by Hour




                                                                                                                Average Bandwidth Utilization (%)
          100%                                                                                          25.0%

              80%                                                                                       20.0%

              60%                                                                                       15.0%

              40%                                                                                       10.0%

              20%                                                                                       5.0%

              0%                                                                                        0.0%
                     2                   0 1 2                   0 1
                    1 1 2 3 4 5 6 7 8 9 1 1 1 1 2 3 4 5 6 7 8 9 1 1
                    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
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                          4%1 1 5%1 3%1 %        3%1
                    5% 2% 7% 5% 8% 1 4%1 %1 6%1 1 6% 1 3%7% 9% 7% 3% 9% 6% 7% 3% 3%
Poor                0% 0% 0% 0% 3% 3% 7% 2% 8% 14%6% 1         0%1             %
                                                      4%8% 3% 1 3%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%
                                        0.2 6.41 9.8
Avg Bandwidth Util 2.9 2.4 4.1 4.3 7.1 1 1 3.41 22. 1     .51 5.11 5.61
                                                     6.421 5.6 1 5.91 2.2 6.4 4.3 5.7 5.3 4.7 2.8 2.7
  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.
 Questions / Answers


                Alfredo Rizzo
                    Adapt
www.teamadapt.com      alfredor@teamadapt.com
                773.634.2044

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:5/15/2010
language:English
pages:50