On July 27, we ran an Enterprise Connect webinar on the topic, "Microsoft Lync: Ready for Prime-Time for Large Enterprise Deployments," offering a detailed look at a topic that many enterprises are confronting (if you missed the event, you can see it by registering here). We had a chock-full agenda of speaker presentations and didn't have time to address the 100+ questions that came in from the audience. So we asked our speakers to address those questions off line, and promised we'd post some highlights here on No Jitter.
The speakers who helped us on the webinar and pitched in on answering questions as a follow-up, are:
* Jamie Stark, Senior Technical Product Manager, Microsoft (JS)
* Sonu Aggarwal, CEO, Unify Square, a Microsoft partner (SA)
* Peter Pawlak, UC Architect, Unify Square (PP), who presented a customer case study, referred to in some of the questions * Talbot Harty, VP and Chief Development Officer, NET, which manufactures Lync-compliant gateways (TH)
Q: What is positioning and roadmap of Lync vs. Skype?
SA: Microsoft will be developing the positioning/roadmap and communicating this after the acquisition process formally closes, which is likely to happen in the coming months pending regulatory approval.
Q: Does [Lync] work with my current Nortel IP phones (1140 and 1150) if I load a different firmware?
JS: Most likely not. Lync has a high standard for endpoint devices with regard to identity, authentication and security. SNOM, Aastra and Polycom currently have phones that register directly with Lync.
Q: Can I use my existing PBX phones or do I have to buy new phones?
PP: In the majority of situations you will need new phones (assuming that the PC client with a USB headset alone is not adequate for the user's needs). However, if you have certain types of IP-based PBX phones, NET offers a software product called SmartSIP that allows you to integrate your legacy phones with Lync. However, the user won't get the same experience as with a true Lync Phone Edition phone.
Q: How do you address E911 across the enterprise if Lync is premise-based or if cloud-based?
JS: E911 is currently not available in Lync Online/Office 365, but we do support it in Lync on-premise. We have a NENA I2 based architecture, where the location of the endpoint dialing emergency services is delivered to the PSAP using a SIP Trunk connection through a service provider.
Q: Will Lync ever change the codec scheme from G711 to G729? How do you size voice trunk engineering?
JS: We don't have anything to announce at this time regarding codecs in future releases, but today G729 is not a supported codec. Customers that need 729 trunking typically use an SBC or Gateway, like those available from NET.
Q: Does Lync handle Contact Center calls i.e Queuing, Skills Routing, Quality Recording, Agent Scoring, WFM, etc?
JS: Lync does call treatment, queuing and routing natively using a feature called Response Groups. It's not meant for large contact centers though--for those cases, we work with partners.
Q: Is Lync fully supported on the Mac? For instance could a Windows Lync user share a Mac Lync user's desktop?
JS: There's a "Communicator for Mac" client availale today, the "Lync for Mac" client is due to be released this year.
Q: How many global office locations and how many users can Lync now support? How robust is its resiliency and failover options?
JS: There's no hard limit--our largest deployments are north of 400k. The resiliency options operate at the process, server, pool (collection of servers) and data center level.
Q: What would be the documented availability of the solution for core redundancy and remote site redundancy? 99.999% or better?
PP: There is no "documented availability" for any such distributed system, and it is way too early to measure historical availability levels. However, I can say that the system was designed to provide better than 99.5% service availability (both planned and unplanned on a 7/24 basis, but not counting outages caused by human error or other dependent systems, such as core network, AD, etc.).
Q: What Telephony & Data, Video network use (i.e. PTN, SP, etc.) when consolidating these disparate systems?
SA: I assume you are asking "what networks--e.g. PSTN, SIP, etc.--are typically used when consolidating these disparate systems ?". Enterprises use whatever form of consolidation is most accessible to them, and hence tend to want to use SIP trunking if they have ready access to SIP trunking in the geographies of interest to them, but in the common case (given that SIP trunking is still several years away in some geographies across the world, given carrier plans today), enterprises usually resort to a standard gateway+PSTN (PRI) combination until they are able to leverage SIP trunking at a certain site.
Q: How does SIP trunking affect the deployment of MS UC?
PP: Well, with the sole exception of providing E911 services (which requires a SIP Trunk to the Emergency Routing Service provider), the issue of PRIs vs. SIP Trunking services is basically orthogonal to the Lync/UC deployment. You can do it with either one. We've done large installations both ways. However, when a customer undertakes a UC project, it is usually a good time to re-architect the PSTN connectivity and take advantage of SIP Trunking at that time.
Q: What are some common challenges of a Lync deployment?
PP: For me, the customer made extensive use of internal firewalls, and getting all the right ports/protocols opened up was one of the big challenges, as Microsoft officially doesn't support this so it doesn't document all of the inter-server traffic and requirements. Always a challenge is bringing the telephony, network, security, Windows infrastructure, and DBA teams together--you need to collaborate with all of them.
Q: To Peter--with most Microsoft system deployments, there is generally fine tuning required to resolve issues like intermittent required server restarts and the like. What issues did you encounter when deploying the Lync system to your client?
PP: The critical components of the deployed system were fully redundant and could handle peak workloads on an n-1 basis. This allowed the customer to do routine server maintenance and gateway firmware updates without bringing down the whole UC system. However, you can't simply bring down a Lync server, media gateway, or load balancer whenever you want; you first need to "drain" the existing A/V sessions off before taking it offline for maintenance. Sometimes this draining process could take several hours, because people would be holding long conferences or would be dialed into external conferencing bridges for hours. We also needed to tweak the UX gateway ISN->SIP Cause Code mappings so that various normal conditions didn’t send back 504 codes, which would cause Lync to mark a gateway as unavailable even though it was fine. As you might expect, we also had to implement SCOM overrides on some false positive errors. However, this task wasn't too extensive (compared with SCOM monitoring of OCS 2007 systems).
Q: My company is beginning to use desktop and mobile video quite extensively. I'm not seeing in the discussion so far how that is being addressed with Lync. Can you explain?
JS: It's built into the base offering of Lync--we support up to HD quality video, over wired networks or wireless. Having video built into Lync--along with the greater number of laptops with built-in video--has seen a large increase in video being a natural part of collaboration for Information Workers.
Q: How do you blend this with video conference collaboration & Lync?
PP: Because Lync has built in P2P Video and Videoconferencing, I am assuming your question is about integrating with Videoconferencing/Telepresence systems from Cisco/Tandberg, Polycom, Radvision, etc. My customer has a substantial investment in Tandberg equipment, and will be integrating it with Lync later this year. Because Lync was so new, the necessary gateway wasn't ready until recently. However, the integration of these systems with Lync or OCS is definitely doable.
Q: Why did the customer in the case study choose to use actual IP Phones (CX600) versus going with just headsets with the PC Lync client?
PP: During pilot, we tested all basic device types with actual users. The overwhelming preference was for the CX600 phones, particularly because the incremental cost of a CX600 over a CX300 was fairly small. Very few users were content with headset only. Most of the workforce were senior-level types and were used to having a handset.
Q: Some of our manufacturing locations have >5,000 analog lines. How would you provision this scale of analog dialtone?
PP: The highest port density that NET offers is 24FXS ports/gateway. There are vendors out there that offer 96-port AnalogSIP gateway models. Part of the decision will be based on analog line length and the phone density of your installation. Also, you may find that replacing some of these with Lync Phone Edition Common Area Phones (such as the Polycom CS500) would be a better solution. The more you can get away from analog phones, the lower the management overhead.
Q: Can a DID be shared between Lync and a PBX Phone?
PP: If you implement the [NET] UX2000's dual-forking capability, the answer to this is yes. The call will be forked to the Lync clients and to the PBX phone. However, there are some important limitations to consider.
Q: What type of network analysis is performed prior to adding Lync? How do you simulate traffic?
JS: Great question--of course Lync isn't the only agent on the wire generating traffic. In addition to the capacity planning documentation we offer, there's also a set of tools available that you can use to "hammer" a Lync deployment with real media traffic--check out the Lync Stress and Performance tool.
Q: Can a DID be shared between Lync and a PBX Phone?
PP: If you implement the [NET] UX2000's dual-forking capability, the answer to this is yes. The call will be forked to the Lync clients and to the PBX phone. However, there are some important limitations to consider.
Q: What type of network analysis is performed prior to adding Lync? How do you simulate traffic?
JS: Great question--of course Lync isn't the only agent on the wire generating traffic. In addition to the capacity planning documentation we offer, there's also a set of tools available that you can use to "hammer" a Lync deployment with real media traffic--check out the Lync Stress and Performance tool.
Q: Is it realistic to have people working from home without QoS on the network? In an Enterprise it is unacceptable to have a bad quality call.
PP: The answer to this is complicated. Yes, it is unacceptable (as you state) to have poor quality on internal calls, but all of us make calls every day to cell phone users that often have poor audio quality or dropped connections, but we accept that as the tradeoff for mobility. At the customer I worked with, we did not implement QoS, yet had exceptional internal call quality. However, with remote and federated users it was a mixed bag. In 90% of the remote call cases, audio quality was great. Much of this is because the RTAudio codec was designed to be very tolerant of low bandwidth, packet loss, and jitter. However, there are those 10% of calls that have issues because of a variety of factors mostly outside the user's control, such as over-subscribed hotel networks or public Wi-Fi networks. In most cases it's still useable, but not ideal. In about 1-2% of calls over the Internet the quality is bad enough to be unusable. When that happens, what users normally do is call from a cell phone or landline, but continue to do IM, data sharing, web conferencing, etc. from the PC. Users feel the benefits outweigh the drawbacks, similar to VoIP-like Vonage or Skype.
Q: Can you virtualize the Lync server infrastructure with either MS or VMware?
PP: The answer is yes. See http://technet.microsoft.com/en-us/library/gg399035.aspx. Unify Square runs its full Lync system on VMs .However, in the case study I presented, we only virtualized a few non-critical Lync server roles (the Monitoring Server and an Application server that ran synthetic transactions and other utilities).
Q: In a Lync environment, it appears that there will be a large number of vendors involved to provide telephony. How do you manage all of the different components to ensure SLAs can be met?
SA: As you observe, it is common for different aspects impacting a voice deployment to be managed by different vendors/outsourced contractors, e.g. company X for server infrastructure, company Y for voice, company Z for network, etc. What some enterprise customers often do in such situations is have "stacked SLAs", starting with the base layer impacting a Voice deployment. For instance, the base SLA might be with network (with company Z), then the next SLA "above" the base might be server infrastructure (company X), then the top-most layer might be the voice components themselves (company Y). This enforces logical dependencies across the SLAs and makes it possible for "upper" parties to issue SLAs contingent upon "lower" SLAs being met.
Q: Where do we have the cost savings? In CAPEX or OPEX?
SA: In both CAPEX and OPEX. Examples of CAPEX savings include handset devices, server footprint, and possibly software licensing (if already included); examples of OPEX savings include PRI consolidation, lower helpdesk costs, and lower support contract costs.
