Effective IP PBX Deployment and Migration Strategies - PowerPoint PPT Presentation

About This Presentation
Title:

Effective IP PBX Deployment and Migration Strategies

Description:

Propagation Delay the amount of time it takes for packets to travel down the medium. ... to traffic based on their relative importance to the business. ... – PowerPoint PPT presentation

Number of Views:145
Avg rating:3.0/5.0
Slides: 51
Provided by: alfred86
Category:

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com