Effective IP PBX Deployment and Migration Strategies

2. Effective IP PBX Deployment and Migration Strategies Alfredo Rizzo Adapt www.teamadapt.comalfredor@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, 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”.

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

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

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

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 CIR’s. • 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 VLAN’s 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 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.

25. Voice Readiness Assessment –Sample Report Graphs and Tables

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

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

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

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. 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 STUN – Binding Acquisition

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 user’s 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.comalfredor@teamadapt.com 773.634.2044