CONNECTING TO LYNC/SKYPE FOR BUSINESS OVER THE INTERNET NETWORK PREP GUIDE

CONNECTING TO LYNC/SKYPE FOR BUSINESS OVER THE INTERNET NETWORK PREP GUIDE Engineering Version 1.3 June 3, 2015

Table of Contents Foreword... 3 Current Network... 4 Understanding Usage/Personas... 4 Modeling/Personas... 5 Data Collection to Validate Models for Estimating Call Flows... 6 Profile 1: Desktop Information Worker... 7 Profile 2: Remote Information Worker... 8 Profile 3: Shop / Retail Floor Worker... 8 Bandwidth Estimation... 9 Call Flows... 9 Peer-to-Peer Session... 9 Conference Session... 9 PSTN/Mediation Server Session... 9 Content Sharing... 10 RDP Bandwidth Estimations... 10 Bandwidth Tables... 11 Audio Capacity Planning for PSTN... 14 General Bandwidth Guidelines... 14 Deploying Lync/Skype for Business and Network Adjustments... 15 Internet/ISP connectivity... 15 Router SIP Inspection... 15 Firewall Configuration... 16 Preferred Traffic Configuration... 16 QoS/DSCP... 17 Wi-Fi... 17 WAN... 18 Using a VPN... 18 Network Readiness Assessment... 18

Foreword This Guide is designed to give the CallTower customer administrator a reference for preparing their network for the use of CallTower Complete for Microsoft Lync/Skype for Business. As a Unified Communications platform, Microsoft Lync/Skype for Business is a bandwidth intensive product that relies heavily on internal network setup and bandwidth to provide end users with a quality experience. While following these guidelines will better prepare your network for its use, CallTower cannot predict overall performance of the product across internal network connections, ports and firewalls due to the influence of user behavior on the network itself. Adhering to the guidance in this guide gives you and your organization a better opportunity to prepare and adjust your network to meet the needs of the product, allowing you to fully benefit from the robust feature set provided by Microsoft Lync/Skype for Business.

Current Network The best starting place in determining if your network is ready to support Lync/Skype for Business is with the network itself. There are several pieces of information that you will want to gather to begin your assessment. First, you should define the following about your current network: Define primary use of the network Describe the enterprise including user locations, site definitions and connectivity between sites. Obtain or design Network and Connectivity Diagrams showing all sites (including remote) and user counts, connectivity between sites, connectivity to the internet and associated bandwidth for all such connectivity. Define the predominant transport protocol in use today Is VPN being utilized across sites or internally? Define internet security and firewall/access list management What system is in use today for email? How is that email connected to the network? Connectivity to the internet and ISP definition Define all network hardware in use or planned for, including routers, switches, firewalls and cabling Define your Network Monitoring procedures What network tools are used? Define Network Redundancy Record this information for later use in determining network changes and optimization as determined by usage modeling, bandwidth and firewall configuration later in this document. Some immediate takeaways that can be determined for this initial analysis would be in the area of equipment in use. If you are running unmanaged switches, less than cat 5 cabling, less than 100Mb internal network, or firewalls that are not easily configurable, these items will likely need to be addresses before successful deployment. Understanding Usage/Personas Before we can begin determining the bandwidth needs, we must first understand who is going to be using the product, and how. Determining personas that can be allocated to your enterprise users, along with persona usage models, can help to define bandwidth needs for your organization.

Modeling/Personas The definition of a persona is the process of analyzing existing usage data, and then using this data to calculate the potential load on a new system. Usage scenarios describe different ways that users communicate by using Lync/Skype for Business. For instance, a peer-to-peer audio call or a video conference are examples of usage scenarios. A usage model represents a collection of data associated with specific users, which can help you customize and adapt a new system to your users specific needs. For example, the usage model that is associated with public switched telephone network (PSTN) calling defines "" users, or users in the medium usage category, as having a maximum of 10 percent concurrent calls to PSTN at your organization s busiest time. A persona is a logical grouping of users based on the behavior that they exhibit when using a specific functionality. For example, a group of users may have "" PSTN calling patterns, but High video conference usage. Another group of users may have no video usage scenarios at all. In practice we typically see four to five unique personas. To begin the process of usage modeling, you should ask a number of general questions: How many site locations are there? How many users are at each site location? How many users will always be remote? What are the future growth estimates? What sort of WAN technology/topology is deployed? What is your overall WAN link speed? What is the maximum/current available bandwidth for Lync/Skype for Business traffic per WAN link? A key ingredient in defining personas is to review the existing private branch exchanges (PBXs) or real-time communications system infrastructure capacity. This data helps to validate any personas and usage models that you create. It also helps to indicate any future capacity planning requirements for Lync/Skype for Business. Evaluate the following information, if available, for usage modeling: Number of users at each location. Call data records (CDRs) for PSTN traffic usage. Usage statistics, such as the maximum number of concurrent calls during the busy hour. The collected information helps you validate the models that you ll use for estimating two of the three major call flows concurrent PSTN calls and peer-to-peer calls.

Data Collection to Validate Models for Estimating Call Flows Additionally, if an existing dial-in conferencing provider provides audio-conferencing services, you can probably access detailed usage reports used as part of the billing process. This usage data is valuable as a tool to help you adjust personas and usage models for actual historical usage statistics regarding general conferencing behavior. Collect the following information: Current location of the conference bridge in use. Although this is not directly relevant for the usage modeling, you ll need to know whether the conferencing media flow patterns will be changing on the network. Because conference traffic volumes are significant, changing the location of the conference bridge can affect network planning and design. Maximum number of conferencing ports used. Peak conferencing usage in the last 12 months. Average maximum number of concurrent conferences, including the number of participants when that maximum occurs. Average meeting size. Average meeting duration. Total minutes of conferencing used per day and per month. If available, how many internal users versus external users joined the conference bridge. You ll need similar information for any video conferencing systems in the infrastructure. Pay specific attention to the desktop video endpoints and codecs in use, and be sure to ask these questions: What is the maximum video resolution for executive video conferences: HD or VGA? What is the base video quality to be used: VGA or CIF? Do you plan to integrate with Lync/Skype for Business? When defining personas, the fewer assumptions that you make about the potential usage of the new system, the more accurate your bandwidth and capacity calculations will be. The default persona definition should assume that users will use all Lync/Skype for Business modalities with a usage model. Using this approach helps to ensure that you can turn off modalities in your modeling to reduce traffic volumes, rather than being surprised by an omission later in the process.

We previously described a persona as a logical group of users who behave in a similar manner when using a specific functionality. The Calculating Lync/Skype for Business bandwidth should include usage models for each of the following usage scenarios: Maximum concurrency of x% of the user base using instant messaging and presence Maximum concurrency of x% of the user base using peer-to-peer audio Maximum concurrency of x% of the user base using peer-to-peer video Maximum concurrency of x% of the user base using audio conferencing Maximum concurrency of x% of the user base using video conferencing Maximum concurrency of x% of the user base using desktop sharing Maximum concurrency of x% of the user base using PSTN audio Maximum concurrency of x% of the user base working remotely This usage model can then be adjusted, based on how you anticipate your users behaving, and on historical usage statistics from existing systems. Some sample personas are listed below using the usage models defined here: Modality None Low High IM/Presence 0% 65.00% 80.00% 90.00% Inter-site user-to-user 0% 0.50% 1.50% 2.50% audio Inter-site user-to-user 0% 0.10% 0.30% 0.50% video Conference audio 0% 1.00% 3.00% 5.00% Conference video 0% 0.10% 0.50% 1.00% Desktop share 0% 0.50% 1.00% 1.50% PSTN audio 0% 5.00% 10.00% 15.00% Profile 1: Desktop Information Worker Client Lync/Skype for Business 2013 IM/Presence Inter-site user-to-user audio Inter-site user-to-user video Conference audio Conference video Desktop share PSTN audio Remote users 10%

Profile 2: Remote Information Worker Client Lync/Skype for Business 2013 IM/Presence Inter-site user-to-user audio Inter-site user-to-user video Conference audio Conference video Desktop share PSTN audio Remote users 90% Profile 3: Shop / Retail Floor Worker Client Lync/Skype for Business Phone Edition IM/Presence None Inter-site user-to-user audio Low Inter-site user-to-user video None Conference audio Low Conference video None Desktop share None PSTN audio Remote users 0% You can use overall usage modeling and user personas for future capacity planning in Lync/Skype for Business and other infrastructures. After you re in production, the data on system usage becomes available through the Lync/Skype for Business Server Monitoring and Reporting feature. You can then use this data to validate the accuracy of your original personas and bandwidth estimations, and to predict future requirements.

Bandwidth Estimation What is the potential impact of Lync/Skype for Business on your network? Bandwidth estimation is the key consideration when deploying. Actually, network estimation would be a more apt term, because the communication streams within Lync/Skype for Business rely more on latency and packet loss than they do on raw available network bandwidth. To understand the role of network estimation, you must also recognize the various communication flows within Lync/Skype for Business. Call Flows Within any IP-based unified communications (UC) solution, there are certain characteristic callflow scenarios that affect traffic modeling results and traffic simulation. Scenarios include peerto-peer calls, conference calls, and PSTN/PBX calls. Each scenario has different media paths, and must be modeled and or simulated to determine future load requirements. There are other call-flow scenarios within the UC solution specifically, those of remote users or federated communications. The following scenarios focus on planning for enterprise environments and managed networks. Peer-to-Peer Session A peer-to-peer call is any communication session between two UC endpoints, using any modality. These calls originate and terminate on UC endpoints within the corporate network. A peer-to-peer session is characterized by call control signaling that is relayed centrally through the UC infrastructure, and the real-time media is exchanged directly between the two endpoints. Conference Session A conference call is a communication session that originates on a UC endpoint, and terminates on the Lync/Skype for Business Server Pool (by default) that hosts the audio/video (A/V) conferencing service. During a conference, multiple sessions will terminate on the A/V conferencing service. The characteristic of a conference call consists of the media being exchanged between the UC endpoint and the A/V conferencing service. PSTN/Mediation Server Session Within the context of a Microsoft UC system, a PSTN call is any communication session that originates on a UC endpoint and terminates on a Lync/Skype for Business server role called a Mediation Server for onward relay to a PSTN gateway.

Content Sharing During Lync/Skype for Business peer-to-peer and conference sessions, it is possible to share the entire desktop, or, more efficiently, the individual application being referenced. When desktop or application sharing is initiated, Lync/Skype for Business will use the Remote Desktop Protocol (RDP) protocol built into the host operating system. This is a TCP connection-based protocol that resends packets that are lost. It is very difficult to predict the effect of RDP on the network because, by nature, it is a protocol characterized by frequent bursts, and it depends heavily on how often the shared desktop or application image is updated. See the following table to estimate the range of figures for expected bandwidths. RDP Bandwidth Estimations Screen Size Acceptable Optimal 1280x800 384 Kbps 1.5 Mbps 1440x900 512 Kbps 2 Mbps 1680x1050 768 Kbps 2.75 Mbps 1920x1200 1 Mbps 3.5 Mbps Note To improve the experience of Sharing in the Microsoft PowerPoint presentation graphics program on Lync/Skype for Business Server 2013, an Office Web Application Server handles PowerPoint presentations by using dynamic HTML and JavaScript.

Bandwidth Tables The following tables describe the bandwidth used by the Lync/Skype for Business Server 2013 media stack. At the most general level, the numbers are as follows: Network Bandwidth Requirements for Lync/Skype for Business 2013 Modality Description Maximum bandwidth Typical bandwidth IM, presence, and signaling Nonmedia elements 2 Kbps 1.6 Kbps Voice Default = RTAudio Wideband 62 Kbps 39 Kbps Conference voice Default = G.722 100.6 Kbps 46.1 Kbps Video - small Video - medium Video - high Uses H.264 at 320x180 Uses H.264 at 640x480 Uses H.264 at 1280x1080 250 Kbps 200 Kbps 800 Kbps 640 Kbps 4 Mbps 3.2 Mbps Audio Codec Bandwidth Audio codec Scenarios Maximum bandwidth (Kbps) Typical bandwidth (Kbps) RTAudio Wideband RTAudio Narrowband Peer-to-peer, default codec 62 39.8 Peer-to-peer, PSTN 44.8 30.9 G.722 Default conferencing codec 100.6 46.1 G.722 Stereo Peer-to-peer, Conferencing 159 73.1 G.711 PSTN 97 64.8 Siren Conferencing 52.6 25.5 Bandwidth includes IP header, UDP header, RTP header, and SRTP headers. The stereo version of the G.722 codec is used by systems that are based on the Lync/Skype for Business Server

2013 Meeting Room Edition, which enables stereo microphone capture so that listeners to can more easily distinguish between multiple talkers in the meeting room. Video Resolution Bandwidth The following table shows video resolution bandwidth values. Video Resolution Bandwidth Video codec Resolution and aspect ratio Maximum video payload bit rate (Kbps) Minimum video payload bit rate (Kbps) Typical bit rate (Kbps) H.264 320x180 (16:9) 212x160 (4:3) H.264/RTVideo 424x240 (16:9)) 320x240 (4:3 H.264 480x270 (16:9) 424x320 (4:3) H.264/RTVideo 640x360 (16:9) 640x480 (4:3) 250 15 200 350 100 280 450 200 350 800 300 640 H.264 848x480 (16:9) 1500 400 1200 H.264 960x540 (16:9) 2000 500 1600 H.264/RTVideo 1280x720 (16:9) 2500 700 2000 H.264 1920x1080 (16:9) 4000 500 3200 H.264/RTVideo 960x144 (20:3) 500 15 400 H.264 1280x192 (20:3) 1000 250 H.264 1920x288 (20:3) 2000 500 Note: Endpoints do not stream audio or video packets continuously. Depending on the scenario, there are different levels of stream activity that indicate how often packets are sent for a stream. The activity level of a stream depends on the media and the scenario, and does not depend on the codec that is used. In a peer-to-peer scenario: Endpoints send audio streams only when the users speak. Both participants receive audio streams.

If video is used, both endpoints send and receive video streams during the entire call. For video scenes with little or no movement, the actual bit rate may temporarily be very low, because the video codec skips encoding regions of the video with no changes. Impact of Multiple Video Streams in Lync/Skype for Business Server 2013 A feature in Lync/Skype for Business 2013 conferences displays up to five simultaneous video streams, and potentially a sixth, if the Panoramic video option is used. By default, the video streams show the current and past four active speakers, but this can be changed by the user to select any five feeds from within the gallery view, as shown in the following figure. Lync/Skype for Business Server 2013 Conference Gallery View with Five Simultaneous Video Streams The five larger windows show the live video feeds. The medium window is a video preview of the user, and the pictures underneath are static images of other meeting attendees that can be selected to be one of the five video feeds. The typical stream bandwidth for panoramic video is based on currently available devices that stream only up to 960x144 panoramic video. After devices with 1920.x.288 panoramic video become available, the typical stream bandwidth is expected to increase.

Audio Capacity Planning for PSTN The following table shows the network bandwidth numbers that indicate audio capacity planning for a public switched telephone network (PSTN). Bandwidth Values for Audio Capacity Planning for PSTN Media codec Typical stream bandwidth (Kbps) Maximum stream bandwidth G.711 64.8 97 RTAudio Narrowband 30.9 44.8 The network bandwidth numbers in all preceding tables represent one-way traffic only, and include 5 Kbps for RTCP traffic overhead for each stream. For all bandwidth tables, sites with fewer than 100 users should always use the maximum figures in network planning because, statistically, the network peaks for Lync/Skype for Business occur more frequently. Lync/Skype for Business depends entirely on the underlying network for the user-perceived quality of its communications, particularly voice. General Bandwidth Guidelines Because bandwidth plays the biggest factor in a successful and quality user experience, you can never have too much. Given all the varying codecs and bandwidths described above, determining exact needs is very difficult to do as well. CallTower recommends 500kbps per concurrent Lync/Skype for Business session as a base starting point for determining bandwidth needs. Concurrency in the Lync/Skype for Business world is different from the traditional 8 to 1 trunking ratio that is regularly applied to PSTN calling. As Lync/Skype for Business uses the same network and bandwidth for internal, as well as PSTN, calls, video, conferencing and IM/Presence, utilizing the usage and persona models above will better provide you with information needed to determine bandwidth needs. If CallTower is providing your bandwidth, we will do these calculations for you prior to ordering your connectivity. A more precise bandwidth calculation can be made by utilizing the Microsoft Provided Bandwidth Calculator available through this hyperlink, which utilizes personas, usage, sites and user counts to determine needs. At a minimum, regardless of user count, CallTower recommends a minimum of 5Mbps up and down at each site. Additionally, be sure to run some ping tests back to the CallTower Gateways (IPs 69.4.190.11 and 69.4.190.14) to test latency. RTT should be below 150ms to prevent jitter and packet loss.

Deploying Lync/Skype for Business and Network Adjustments Now that general network, bandwidth and usage is determined, we need to get your network ready for using Lync/Skype for Business in production. This means that changes will likely need to be made to the network to accommodate the traffic that will be flowing in and out of your network through Lync/Skype for Business. Internet/ISP connectivity After determining the amount of bandwidth needed to support the full featured functionality of the product in your organization, it is important to use the right type of bandwidth for the product. CallTower has found that, while standard broadband connections can work in smaller deployments, most organizations will need more than just a cable modem or DSL connection to meet their needs. Typical broadband does not guarantee bandwidth, but provides you with a max rate at which you might be able to use the bandwidth. A Cable modem, for instance, might have a 50 download, 10 upload connection, but that is shared bandwidth that bursts to those higher speeds when no one else is utilizing the same pipe. They provide an up to measurement for your service. When dealing with Real Time communication that relies on your bandwidth, you need to be able to rely on the bandwidth being there. CallTower recommends using a guaranteed bandwidth, true internet connection that utilizes symmetric architecture. This means that both your download and your upload speeds are the same (such as 50/50 or 100/100). This type of internet connection will also provide you an MRTG view of the bandwidth utilization so you can monitor how much you use and how often you saturate that bandwidth. This allows you to make adjustments to your network based on factual usage data to provide the best overall experience to your users. While CallTower can provide dedicated circuits for our Lync/Skype for Business product, if you have a solid, true internet connection with enough bandwidth as determined by exercises above, you can have wonderful user experience utilizing your existing connection. Remember, true symmetrical internet is good for Lync/Skype for Business. Commercial broadband, however, is not. Router SIP Inspection If your router is not configured for the new traffic protocols that Lync/Skype for Business will introduce to your network, you could experience packet loss, dropped calls and jitter.you must make sure that SIP inspection or SIP ALG (Application level gateway) are disabled on your routers and firewalls to prevent this from happening. You may need to contact your ISP to have this done, but make sure this is completed prior to deployment. These features in routers are intended to block SIP traffic and will interfere with Lync/Skype for Business communications.

Firewall Configuration Because CallTower s product is not housed in your internal network and IP setup, you will need to make sure that traffic traversing the firewall to CallTower s Lync/Skype for Business Servers does not get blocked. You will need to add exceptions to the firewall for all Lync/Skype for Business Server IP addresses and allow for IPs and ports listed below: IP Description Ports 69.4.190.11, 69.4.190.14, 69.4.190.45, 69.4.190.48 SIP TCP: 443, 5061, 5269 69.4.190.12, 69.4.190.15, UDP: 3478, 50000-59999 Audio/Video 69.4.190.46, 69.4.190.49 TCP: 443, 50000-59999 69.4.190.13, 69.4.190.16, 69.4.190.47, 69.4.190.50 Conferencing TCP: 443 69.4.190.23 Web Services TCP: 80, 443 69.4.190.25 Web Services TCP: 80, 443 69.4.190.19 Web Services TCP: 443 In addition to the firewall adjustments above, if you are using a PC level firewall other than the built-in Windows firewall, you will need to add exceptions to the PC antivirus/antimalware itself to disable security for the Lync/Skype for Business client. While these changes are always required for firewalls, you may need to add exceptions to other security devices that sit between computers and the internet if you have other devices in your network that provide security or the ability to block certain network traffic. Preferred Traffic Configuration With the proper bandwidth and internet connection, there is still the probability that an employee internally could be streaming other types of media traffic across your environment that could impact the service quality. To prevent this, CallTower recommends that you prefer the Lync/Skype for Business outbound traffic over other traffic from your network. As this is a setting that would need to be applied to the firewall on the ISP side, it may not always be possible to configure this setting. However, when possible, CallTower recommends that you enable outbound QoS policies on your firewall to prefer traffic destined to the CallTower Lync/Skype for Business server IPs over traffic destined for other IPs. By default, Lync/Skype for Business Voice takes higher priority over other modalities of the product, so by enabling half of your outbound internet bandwidth to prefer the Lync/Skype for Business IPs over other traffic, this will allow Lync/Skype for Business Voice to take the highest priority over other forms of media and outbound traffic on your network.

To implement this prioritization of traffic destined for CallTower s Lync/Skype for Business platform, configure your router to give priority access to outbound traffic destined for the 69.4.190.x IP addresses listed above. The configuration on your router will vary depending on the device. Note: Even with this applied, long sessions may not maintain priority. QoS/DSCP CallTower does support QoS and DSCP for our Lync/Skype for Business product, however, this only affects traffic on your internal network. If you have multiple sites in your organization that are interconnected, this would be a beneficial policy to apply to make sure that Lync/Skype for Business traffic across your network gets the priority it needs. While this doesn t carry over the internet to the CallTower servers, by applying this internally and applying the preferred traffic policy above to the outbound traffic, you are providing the best chance for your network to successfully handle Lync/Skype for Business traffic and other real time protocols. Lync/Skype for Business edition phones (like the Polycom devices CallTower offers) will automatically tag the outbound traffic with DSCP marking 46, giving the Lync/Skype for Business Voice the highest tag available and highest priority in the network. To get the same policies applied to the PC clients, you will need to push out an Active Directory Group Policy to apply DSCP tags to the voice and other modalities provided within Lync/Skype for Business. For more information on applying these policies for your local PCs, you may reference http://technet.microsoft.com/en-us/library/jj205371.aspx for Microsoft provided information. For the CallTower Lync/Skype for Business infrastructure we have specified the following port ranges for these services: Audio: 50020:50039 - DSCP value: 46 Video: 58000:58039 - DSCP value: 34 Application Sharing: 42000:42039 - DSCP value: 24 File Transfer: 42040:42039 - DSCP value: 14 After applying the policy to the PCs, you will need to enable the DSCP Trust on the internal switches so the tags pass through from site to site. The process for enabling the DSCP Trust application is dependent on the switch model you own. While CallTower can help with certain switch models, you may have to engage your switch provider or search online for settings to enable this on the switches themselves. Wi-Fi Corporate Wi-Fi is regularly deployed, and while useful for many enterprise applications, is not the best connectivity for real time VOIP traffic. If you are planning on including an element of Wi-Fi in your Lync/Skype for Business deployment, please check through URL below for a list

of Microsoft approved WI-Fi devices and vendors. If designed specifically for Real Time VOIP protocols, Wi-Fi could provide a good user experience as well, allowing for mobility within the office for your workers. Wi-Fi devices and vendors: http://technet.microsoft.com/en-us/office/dn788945.aspx WAN There are a few vendors that have been certified for Microsoft Lync/Skype for Business for their Network infrastructure. Referencing the information we gathered earlier on network architecture and infrastructure, if you are already utilizing one of the network vendors from the URL below, they will have configuration guidelines and network readiness instruction pertaining directly to Microsoft Lync/Skype for Business. If you are looking to upgrade your network in preparation for the pending deployment of CallTower Complete for Lync/Skype for Business, we would encourage you to look at these certified vendors for your new network infrastructure. You can access the most current list of vendors at the following URL: Wired Network and vendors: http://technet.microsoft.com/en-us/office/dn788945.aspx Using a VPN One consideration to keep in mind with your Lync/Skype for Business deployment is how you currently do business today. VPN is an increasingly common way of allowing remote sites or large corporations to maintain security over their network and data while allowing their workers to access the tools they need to get their jobs done. This, however, is not a recommended method for connecting to a Lync/Skype for Business client. Lync/Skype for Business media stream and signaling are encrypted between client and server. Because a VPN also runs encryption, this would force encrypted Lync/Skype for Business traffic to be re-encrypted through the VPN, then decrypted more than once. This can cause latency and jitter. Additionally, errors in VPN set-up can further complicate the matter for real time traffic protocols from Lync/Skype for Business. As such, VPN is not a recommended environment for Lync/Skype for Business. Network Readiness Assessment While many organizations have in house knowledge bases that they can tap to prepare their network for Lync/Skype for Business deployment, not everyone has the time to do it. CallTower has a Microsoft certified Network Readiness partner that we can engage to do the work described above for you and make sure your network is ready for CallTower to deploy to your organization. Please speak with your Project Manager or Sales Representative if you would like to learn more about the cost and timelines for this service.